maria-developers team mailing list archive
Mailing list archive
Re: Obsolete GTID domain delete on master (MDEV-12012, MDEV-11969)
>> If my concern is practical we may consider *optionally* strict
>> delete domain FLUSH LOGs. The errored out version would maintain a
> In that case, I would compare to SET GLOBAL gtid_binlog_state.
> Currently, this is even more restricted, it is only allowed when the binlog
> is completely empty.
> If the philosophy is "the user knows what she is doing", then an unsafe SET
> GLOBAL gtid_binlog_state allows to do everything an unsafe DELETE DOMAIN
> would, and more. (Then SET GLOBAL gtid_binlog_state should be changed to not
> do implicit RESET MASTER, only implicit FLUSH BINARY LOGS). Then there is no
> need to introduce new syntax.
For the unsafe method yes. But I've never given up the strict one! :-)
>>> 4. FLUSH BINARY LOG DELETE DOMAIN domain
>> might be equivalent to RESET MASTER as the 'erroneous' log file is last.
>> That's why I was content without p.3 and with p.4 that does not
>> necessary error out.
> I do not think it is equivant.
Sorry, I put that rather harsh. I only needed to point to the total
purge of binlog as inferred by RESET MASTER.
> RESET MASTER requires to stop _all_ servers
> and reset the gtid position on all slaves. That is very disruptive. In
> contrast, the safe version of DELETE DOMAIN only requires a FLUSH BINARY LOG
> and waiting until slaves are up-to-date.
Right, and then the binlog can be totally and painless purged.
>> To dramatize mdev-12012 case with a complication, what if p.2 can't be
>> not ensured, say, due to another temporarily stopped slave who (for
>> simplicity) does not care for the being deleted domain?
> I do not think this is a concern. I think it is reasonable in this case to
> require that all slaves be up to date with a FLUSH LOGS before switching the
> system to GTID.
I don't have any strong objection.
After all, we are all ears for demands from practical field and could
relax the feature's strictness.
> One criteria I use for choosing between a strict and a relaxed behaviour is
> to consider if the relaxed behaviour can be reasonably documented. In fact,
> it is a good idea to sketch a full documentation for a new feature early
> during design.
> If the behaviour in the relaxed case cannot be fully
> described in documentation, then it will be hard for the user to "know what
> she is doing". And easy to accidentally end up with an incorrect result.
To open more about my way of thinking, and why I liked the unsafe method
is that we already have the strict and non-strict modes. Your safe purge
method perfectly fits to the former. The relaxed method I was going to
merge to the non-strict mode whose guarantees I am yet to learn..
Having said this, I am aware of a non-strict master must be much more
dangerous than a similar slave .. to further dump the idea.
> In this case, I find it hard to see how to fully document what happens with
> any left-over GTIDs in domains that were deleted. Or even fully understand
> myself how they will behave (or misbehave). Hence my recommendation to make
> it an error.
Which is taken.
Thanks for your time, pieces of creativity and patience!
> - Kristian.