Sachin Setiya <sachin.setiya@mariadb.com> writes:

> This issue is regarding Mdev-9107 , where we have 3 master master with
> do_domain_ids of

> I have created a abstract test case for this probem.
>                                       (3)
>                                     ^     ^
>                                    /         \
>                                  (2)----->(1)
>
> 3 and 1 is configured with log slave updates.
> 3 has 2 replication channel m2_s3(do_domain_id=2 ), m1_s3(do_domain_id=1)
> 1 has one replication channel m2_s1(do_domain_id=2)

This seems to be just user error. All these --do-xxx / --ignore-xxx
replication filter options are always dangerous, and this usage seems
clearly wrong. I also did not see a clearly explained reason in the bug
report why this should work. On the contrary, Elena's suggestion to use
--gtid-ignore-duplicate (if one really wants to do something as complex as
this) seems appropriate.

Is there a reason this is considered a bug (other than that the reporter
somehow assumed a different behaviour for --do-domain-id)? What does the
documentation say?

> May be we should have one more option in master_use_gtid =
> binlog_state ? which will compare its binlog_state to

I think that sounds like a very bad idea. The current_pos/slave_pos is the
single biggest source of confusion regarding GTID. (In fact, I think it
would be best to deprecate/eventually remove current_pos). Better not add to
the confusion...

 - Kristian.