Elena Stepanova <elenst@montyprogram.com> 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.