On Fri, May 3, 2013 at 12:01 PM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
slave fully synced with master, the last GTID in binlogs (and I guess the value of @@global.gtid_pos) is 0-1-100. Now let's say there's a bug that didn't configure slave read-only, or for whatever other unwanted reason slave got disconnected from master and someone connected to slave and executed a binlogged transaction there. I guess it will be assigned GTID 0-2-101 (or it will be 1-2-1?). If someone
Yes, 0-2-101.
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?
checks value of @@global.gtid_pos at this point he will be able to notice the discrepancy between master and slave. But it seems what you are saying is if after that slave connects back to master he will be able to successfully replicate and will execute transactions 0-1-101,
Actually, in this particular situation, you will get an error when the slave tries to reconnect. Because the last GTID executed on the slave is 0-2-101, and this is what the slave is asking the master to start from. But the master's binlog does not contain this GTID, so the master returns error to the slave.
On the other hand, if the slave was not stopped when the extra transaction was executed on the slave, replication will continue, and the slave will get in its binlog: ... 0-1-100, 0-2-101, 0-1-101, 0-1-102, ...
0-1-102 etc. Slave will still carry information in the binlog about existence of transaction 0-2-101
Yes, in the sense that slave has the ability to locate this transaction in its binlog.
but no one will be able to detect that from outside of mysql.
Well, SHOW BINLOG EVENTS will display it.
SHOW BINLOG EVENTS on all servers and then comparing them to make sure that they represent the same set of transactions... You don't seriously think that it's a good way of monitoring, do you?
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.
But if the binlog file with this transaction will be already purged by the time the slave becomes master then replication will be broken and no one will be able to connect to it as slave.
No. Why would there be problems to connect?
I am not sure I understand your concern here. At a guess, it sounds like your worry is that the presence of 0-2-101 in the binlog Gtid_list event will require all connecting slaves to know of this event, or they will fail to connect? That is not how it works. It is the other way around, presence of a GTID in the state of the connection slave requires that the master binlog knows of this event.
The GTIDs in the Gtid_list event are only used when searching for the right binlog to start from when a slave connects with the same domain_id and server_id. Otherwise they are ignored.
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... Pavel