maria-developers team mailing list archive
Mailing list archive
Re: Obsolete GTID domain delete on master (MDEV-12012, MDEV-11969)
>> 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
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!