maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Pavel Ivanov <pivanof@xxxxxxxxxx> 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.