maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

andrei.elkin@xxxxxxxxxx writes:

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

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

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

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.

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.

 - Kristian.