maria-developers team mailing list archive
Mailing list archive
Re: Interaction between rpl_slave_state and rpl_binlog_state
On Tue, Nov 28, 2017 at 3:03 PM, Sachin Setiya
> Hi Kristian, Andrei
> I have some question related to rpl_slave_state. Suppose A circular
> async replication between A < -- > B (gtid_ignore_duplicates on)
> Now, we set some temp server_id on server A , lets say `X`. Now the
> problem is each event group which
> originates from A is executed 2 times. For example we insert into
> table t1 and gtid is 0-X-2. The event goes to slave B
> B applies it, And send it back to A, Since its server_is different
> from A global server_id , this event is not filtered in queue_event().
> Now event goes to handle_sql thread , And check_duplicate_gtid
> function is called. Since rpl_slave_state::hash does not have a
> whose sequence_no is >= 2, So this event is applied again.
> Andrei suggested a solution of checking rpl_binlog_state in
> check_duplicate_gtid, This solution solves some problem but creates
> problem. (multi_source.gtid_ignore_duplicates fails in master_sync,
> test for mdev_10715 also fails ). Reason for this is sync_with_master
> calls master_gtid_wait , which internally calls
> gtid_waiting::wait_for_gtid , and this checks rpl_salve_state::hash.
> Although this method can
> also be patched for to look for rpl_gtid_global_binlog_state. But I am
> not sure whether this will solve all problem or create new problem.
Actually this wont work , because I can just look at maximum gtid
> Another solution might be somehow update rpl_slave_state::hash when we
> write gtid_event in log. But this does not make sense. rpl_slave_state
> should be used for slave replication usage.
> I think we need a more better solution for this.
Experimental code is on this branch
Software Engineer at MariaDB