maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Elena Stepanova <elenst@xxxxxxxxxxxxxxxx> writes:

> Reading recent Pavel Ivanov's reports (the last one is MDEV-4820, but
> I think there were some others which you've already closed as fixed),
> I started wondering if I conceptually misunderstood something
> before. From our previous discussions I made a conclusion that
> removing *all* binary logs before trying to replicate from the server
> is very wrong and against the whole idea of GTID. Is it not so? If
> not, it's definitely an area which didn't undergo any testing from me,
> except for my very first clumsy attempts to get familiar with GTID, so
> I need to fill the gap.

Well, we _do_ want to support running a slave with --log-slave-updates=0, and
then making that slave into a master. Indeed, you tested that early and it was
horribly broken. However, my intention is that this should now be supported
(and thus can be tested). There are MTR testcases for this.

The reason I mention this is that the case of --log-slave-updates=0 is
actually quite similar (from the server's point of view) to manually deleting
the logs. So I do also intend to support removing binlogs as Pavel wants to
do.

The main problem with doing this (deleting binlogs or using
--log-slave-updates=0) is that it makes it harder to detect certain user
errors, because the information to know that it is an error is missing.

I suppose the limitations should be pretty obvious: If user deletes binlogs on
a server, then that server, acting as a master, can not replicate to slaves
starting from an event that was deleted. So as long as the user does not try
to do that, things should be fine. I think the main problems come if the user
makes a mistake in this respect, and the server fails to detect the error.

For example, suppose that server A is a slave, replicates up to position
0-2-10. Then it becomes a master, generates events up to 0-1-20. Then user
deletes the binlogs on A, and tries to have server B replicate from A starting
at position 0-2-10.

In this case, server A will allow B to connect, effectively loosing the
deleted events 0-1-11 .. 0-1-20. I do not see any way to avoid this. Server A
has no way to know that those events ever existed, as the user deliberately
deleted all information about them. (In fact the user might be doing this
deliberately, in case the events were wrongly created and should be removed
from the history).

A workaround in this example is that the user sets @@gtid_slave_pos explicitly
to 0-1-20 after deleting the logs, thus preserving the needed information.

So in summary: Yes, we try to support deleting binlogs, however there is some
responsibility on the part of the user to not delete information that they
actually need. I think that is rather reasonable. It is how DELETE and SELECT
work, as well :-)

 - Kristian.