← Back to team overview

maria-developers team 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'
>>   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!


Follow ups