← Back to team overview

maria-developers team mailing list archive

Re: Updated Gtid_slave_pos of Untracked domain creates skipped events

 

On Sat, Jul 21, 2018, 11:51 Sachin Setiya <sachin.setiya@xxxxxxxxxxx> wrote:

> Hi Kristian!
> On Fri, Jul 20, 2018 at 8:38 PM Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>
> wrote:
>
>> Sachin Setiya <sachin.setiya@xxxxxxxxxxx> 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
>

Follow ups

References