maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

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.