maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Andrei Elkin <andrei.elkin@xxxxxxxxxx> writes:

> And really why not
>
>   3. SET @@GLOBAL.gtid_binlog_state=list-without-d;

The main issue I see with this if the master is actively adding new
transactions (in other domains than d). It will be hard for the user to know
the right value to set without doing something like FLUSH TABLES WITH READ
LOCK during the operation to stop transactions between selecting
@@global.gtid_binlog_state and SETting the new value.

Whereas FLUSH BINARY LOGS DELETE DOMAIN d only needs a shorter-lived lock on
the binlog while doing the rotation and check.

Other than that, I agree SET gtid_binlog_state could be a good fit.

>   the new state value must cover (include as a math set) all gtids in
>   the current list of binlog files. (Naturally I consider [presume] Gtid_list
>   header of a binlog file assumes there are no gaps or out-of-order
>   in the preceding files. That is it provides the right-hand-side of
>   gtid seqno range for each domain-server pair).

Yes. (There is no strict requirement of no gaps in MariaDB GTID, but it
should not matter here).

> So we conduct the 1-3 procedure. Pseudo-sql would go like
>
>   mysql> /* 1. */ SELECT @@global.gtid_binlog_state into @pre_purge_state;
>   mysql> /* 2. */ PURGE LOGS to 'b.2'
>   mysql> /* 3. */ SET @@global.gtid_binlog_state="REPLACE"(@pre_purge_state, '0-1-1', '');

So this requires that there are no new transactions written to binlog
between (1) and (3).

> The check technically is a comparison between Gtid_list.d term in
> the oldest file and @pre_purge_state.d one.
> If they are equal the current binlog files are proven not to contain
> events from 'd'.

Agree.

 - Kristian.