maria-developers team mailing list archive

[andrei.elkin@xxxxxxxxxx]

>> 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