maria-developers team mailing list archive

[Giuseppe Maxia <g.maxia@xxxxxxxxx>]

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@xxxxxxxxxxxxxxx>
wrote:

> 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.
>