Kristian, Thanks for the quick answer. What you are saying is that the transaction in node 101 is retained because it is part of the stream coming from node 100. Here I note a difference with the usage of domain_ids. * If the domain_id is the same, then the transaction from 101 is discarded and replaced by the latest events coming from 100. * If I set a different domain ID for each master, the transaction from 101 is retained even if I then insert hundreds of events from 100 while 101 stays idle. Moreover, even after purging binary logs in all nodes and inserting more events, the original transaction in 101 is still there. To give you a clearer view of what I am doing, I am experimenting with a star topology, where I have endpoints that are masters connected to a hub, which is the node with log-slave-updates enabled. The topology works perfectly: data produced in the endpoints or in the hub reach all the other endpoints. The only glitch is the endpoints (master nodes without log-slave-updates) have their own transactions in gtid_slave_pos long after purging the logs in all nodes. Cheers Giuseppe <http://datacharmer.blogspot.com> On Thu, Aug 13, 2015 at 9:08 AM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
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.