Pavel Ivanov <pivanof@google.com> writes:
Now that you mentioned this I'm worried. Tell me please what will happen with MariaDB in the following situation. Let's say we have
Ok, here is what the current code will do.
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.
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.
And if later this slave becomes a master then it will push this extra transaction to all other servers.
Yes.
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 another deliberate difference from MySQL 5.6 global transaction ID. In 5.6, if I have understood correctly, if an incorrect transaction sneaks into the slave as you describe, you will be stuck with it forever, and people do tricks like inject fake empty transactions on servers that lack them to make it possible to even connect as a slave again. In contrast, MariaDB GTID is self-healing, just like ordinary replication. If you inject a wrong transaction on a slave, then your slave and master may be out of sync, but as the binlog position progresses beyond the problem point (maybe with the help of slave_skip_counter or whatever), things work again, the sins of the past forgotten. Because the slave state is just a single GTID (per domain id). If I misunderstood your concern, please elaborate and I will try to give a better answer. - Kristian.