maria-developers team mailing list archive

[Andrei Elkin <andrei.elkin@xxxxxxxxxx>]

Hello, everybody, Kristian.

>>> 1. Take note of @@global.gtid_binlog_state
>>> 2. Ensure that all slaves are past the last event of being deleted domain 'd'

>>> 3. PURGE BINARY LOGS DELETE DELETE 'd'

While I was selecting between two candidates where to settle the new
option to discard the obsolete domain from Gtid_list of the most recent
binlog file, another candidate popped out.

And really why not

  3. SET @@GLOBAL.gtid_binlog_state=list-without-d;

where `list-without-d' sublists the p.1 SELECT @@global.gtid_binlog_state
with the obsolete domain discarded?

The docs currently say

  The main usage of @@gtid_binlog_state is to restore the state of the
  binlog after RESET MASTER (or equivalently if the binlog files are
  lost).

Now when we've defined what the domain-id purge should be, I find
RESET-MASTER requirement can be refined/relaxed to the following
one:

  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).

Specifically to the obsolete domain case, `list-without-d' new value
would reflect gtids from files remained after a user PURGE files containing 'd'.
Naturally we would leave the backward compatible behavior in case of
the list of binlog files is empty (as after RESET MASTER).

As an example:

Let binlog consists of two files

  b.1  /* contains one event from domain 0 */
  b.2  /* does not contain domain 0 */

with their header Gtid_lists as

  b.1.Gtid_list=\empty
  b.2.Gtid_list={0-1-1}

and we would like to forget the domain 0 ('d').
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', '');

At the 3rd step the SET handler would 
implicitly execute FLUSH LOGS to rotate binlog to b.3
where the new value gets adopted only when the refined check succeeds.
Otherwise the SET errors out.

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'.

I find the SET method as fitting to the matter. Backward compatibility is
in place. No new options is required.
The burden of PURGE may not necessarily be left to the user though.
The proposed new 'delete domain_id' option can be implemented (now,
later?).

Your feedback is welcome!

Cheers,

Andrei