>> 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 _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp