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.
Fair enough.
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.
Andrei