Pavel Ivanov <pivanof@google.com> writes:
This is exactly my concern currently (wasn't initially). So let's say as you said above extra transaction was executed when slave was connected, or (more probable case if possible) when IO thread was already disconnected but SQL thread didn't catch up yet. In both cases extra transaction somehow got there in the middle of the stream, and so the last GTID is the valid one, existing on the master. So slave is able to connect to master again and everything works fine. A couple of days passed without change of the master, slave already deleted the binlog file with transaction 0-2-101. Somewhere on the transaction 0-1-10000 the server 2 becomes master...
Hm... Looking at the code it seems that at this point all slaves should be able to continue to replicate from server 2 just fine, although result of transaction 0-2-101 will still exist only on server 2 and nowhere else. Which means that your answer above is incorrect (as long as slaves connecting to server 2 are at state 0-1-101 or higher). If this is true then I'm relieved and have no more concerns...
Aha, now I see. Yes, you are right. 0-2-101 will exist only on server 2. It will not be replicated to other slaves if server 2 later becomes master.
And if later this slave becomes a master then it will push this extra transaction to all other servers.
Yes.
Probably this answer is incorrect, read below.
Correct. I was thinking of the case where the slave was already itself a master when the extra transaction was executed.
Not related to the rest of email: are multiple replication domains generated only by setting gtid_domain_id variable? Are there situations when server can decide to put transaction into different domain by itself?
Correct, replication domains can only be generated by user explicitly setting gtid_domain_id. Servers will never invent domain ids on its own. - Kristian.