maria-developers team mailing list archive

[Pavel Ivanov <pivanof@xxxxxxxxxx>]

On Fri, May 3, 2013 at 12:01 PM, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx> 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