Giuseppe Maxia <g.maxia@gmail.com> 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.