Jonas Oreland <jonaso@google.com> 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.