andrei.elkin@pp.inet.fi writes:
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?
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. 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. 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. Hope this helps, - Kristian.