Andrei Elkin <andrei.elkin@pp.inet.fi> 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.
Right.
Other than that, I agree SET gtid_binlog_state could be a good fit.
Then a function to discard a domain term would do: SET @@gtid_binlog_state=gtid_discard_domain(@@gtid_binlog_state,'d') While this time it would be new object introduced still it's of var setting semantics and might be generally useful too. How about it? Andrei
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 mysql> @pre_purge_state; mysql> /* 2. */ PURGE LOGS to 'b.2' mysql> /* 3. */ SET mysql> @@global.gtid_binlog_state="REPLACE"(@pre_purge_state, mysql> '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.