>> 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 _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp