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'
The effect of the last step would include purging all the binary log files plus a planned implicit FLUSH LOGS discarding 'd' from the new emerged binlog.
Which binary log files would be purged, exactly? All those containing the domain d?
Right. So when the master has at PURGE invocation time two binlog files: b.1 (contains a 'd' group), b.2 (does not contain any 'd' group, but contains 'd' in its GTID_List) PURGE delete 'd' would result in b.2, b.3 where b.3 does not even have 'd' in its GTID_List header. I gather remained presence 'd' in non-active b.2's GTID_List is harmless.
It's one command less and besides PURGE as the command name reflects better the action. Perhaps you shared that feeling when spoke 'PURGE' in your initial response to 12012.
I did mean FLUSH initially.
FLUSH seemed more natural to me. The MDEV-12012 is a very special use case. DELETE DOMAIN will commonly be used just to clean up old domains that are no longer used, not because they are a problem but just to clean out the GTID position. Regular automatic binlog file purge might already have purged all traces of the old domain. So in this case only a single binlog rotation is needed, rewriting the GTID_LIST event of the new binlog file. This is natural for FLUSH, which is just a forced binlog rotation.
Indeed, this would be a degenerative case for my new option PURGE.
As a user, I would personally prefer first manually specifying which binlog files to purge, and then after getting an error if I purged too little. To avoid accidentally purging too much.
But on the other hand, as you say, having the set of binlog files to purge determined automatically can also be seen as convenient. So I think either way could work.
Automatic check is as simple as iteratively search for the first positive gt-check between GTID sequence numbers from two GTID_List:s for a specified domain. The first compares @@global.gtid_binlog_state.d.seqno > the 1st binlog file's GTID_List.d.seqno The following ones compare GTID_List.d.seqno of the previous file vs the current one's. The procedure stops at first positive which indicates the file to end purging on inclusive.
It should be possible to delete an old domain without actually purging any binlog files, in the case where the domain is already absent from all remaining binlog files.
Yes, the degenerative use case as above.
Hope this helps,
- Kristian.
It certainly does. Have a nice weekend, Kristian! Andrei