maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

andrei.elkin@xxxxxxxxxx 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.