maria-developers team mailing list archive

[andrei.elkin@xxxxxxxxxx]

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