maria-developers team mailing list archive

[Jonas Oreland <jonaso@xxxxxxxxxx>]

hmm...i'm not sure I get it...

is it a bug or a feature that the "rouge" transactions is skipped by Slave2
in statement based replication, skipping 0-2-3 and 0-2-4 can cause
arbitrary data drift, right ?

thx in advance for help/patience

/Jonas


On Wed, Mar 4, 2015 at 2:37 PM, Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>
wrote:

> Jonas Oreland <jonaso@xxxxxxxxxx> writes:
>
> > I wrote attached patch (so that i would understand what code actually
> does)
> > and found myself while refactoring also doing a change, namely that
> > i removed the check for server_id in a couple of places.
> >
> > it still passes all tests...
> > could you comment on this, or write(outline) a testcase that fails with
> my
> > patch.
>
> I think the check for server_id is needed in case of out-of-order binlogs.
>
> The easiest / most common way to do this is to do rouge transactions on the
> slave:
>
> Master:
>
>   CREATE TABLE t1       # GTID 0-1-1
>   INSERT INTO t1        # GTID 0-1-2
>
> Slave1:
>
>   CREATE TABLE t_local  # GTID 0-2-3
>   INSERT INTO t_local   # GTID 0-2-4
>
> Master:
>
>   INSERT INTO t1        # GTID 0-1-3
>   UPDATE t1             # GTID 0-1-4
>   DELETE FROM t1        # GTID 0-1-5
>
> Now the binlog on Slave1 contains:
>
>   GTID 0-1-1
>   GTID 0-1-2
>   GTID 0-2-3
>   GTID 0-2-4
>   GTID 0-1-3
>   GTID 0-1-4
>   GTID 0-1-5
>
> Suppose now that Slave2 asks to connect to Slave1 at GTID position 0-1-3.
> I think with your changes, the Slave2 will actually start from the earlier
> position 0-2-3. So you will get duplicate events 0-2-4 and 0-1-3 on Slave2.
>
> > i think functionality that i might have removed would be if you write
> have
> > 2 mysqld M1 & M2
> > and your replicate both way...and you *don't* use domain_id...and you
> write
> > concurrently on both
> > mysqld (but maybe disjoint data ??).
>
> That would probably trigger it as well I think.
> However, just a rouge slave transaction should trigger it, and this seem
> to be
> quite common practice by many users...
>
> In gtid_strict_mode, of course, all of this complexity goes away. But we
> cannot in general know if gtid_strict_mode was enabled when a given piece
> of
> binlog was written.
>
>  - Kristian.
>