![](https://secure.gravatar.com/avatar/bf3ce935cdc1cff7cb213acd71f21f73.jpg?s=120&d=mm&r=g)
On Sat, Jul 21, 2018, 11:51 Sachin Setiya
Hi Kristian! On Fri, Jul 20, 2018 at 8:38 PM Kristian Nielsen
wrote: Sachin Setiya
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.
I tried with --gtid-ignore-duplicates and it worked perfectly. I guess this is just user error.
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?
According to documentation it is correct behavior , it will not apply events but update gtid_slave_pos table.
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...
If we remove current pos then how will how will master turned slave will
work ?
May be in this case user have to manually update gtid_slave_pos ?
- Kristian.
Regards sachin