Sachin Setiya <sachin.set...@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. _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp