maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Giuseppe Maxia <g.maxia@xxxxxxxxx> writes:

> Using MariaDB 10.0.20, when I set a multi-master environment in which one
> of the masters has log-slave-updated enabled, I get this strange behavior:

> select * from gtid_slave_pos;
> +-----------+--------+-----------+--------+
> | domain_id | sub_id | server_id | seq_no |
> +-----------+--------+-----------+--------+
> |         0 |      1 |       101 |      1 |
> +-----------+--------+-----------+--------+
>
> Why is this happening? Is there a reason for the server to log its own
> transactions?
> The transaction originated from this same server, but it is effectively
> filtered off when it comes back from the other node (otherwise we would
> have a conflict).

If I understand correctly, you have a ring setup here, eg. server 100 and
101 both replicating from each other. And --log-slave-updates on server
100. So that server 101 receives its own transaction (here GTID 0-1-101)
back from server 100.

In this case, it seems essential that server 101 updates gtid_slave_pos with
its own transaction. Otherwise, if it reconnects to server 100 using
master_use_gtid=slave_pos, it would have the wrong starting position (it
would be missing the replication domain of server 101, causing connection to
fail once server 100 starts to purge binlog files).

It works the same way with the old-style, non-GTID position: When events are
skipped by a slave, the position is still updated to point to the end of the
skipped event. There is special code in the server to handle this
(sql/slave.cc, eg. rli->ign_gtids and rli->ign_master_log_name_end).

Hope this helps,

 - Kristian.