MySQL Bugs: #71575: Master logs two consecutive GTIDs causing slaves to miss the first GTID

Bug #71575	Master logs two consecutive GTIDs causing slaves to miss the first GTID
Submitted:	4 Feb 2014 3:59	Modified:	25 Feb 2015 4:54
Reporter:	Ben Krug	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S3 (Non-critical)
Version:		OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
  Somehow master logged consecutive GTIDs causing slaves to miss the first GTID

 Here is the binary log on master

 #131221 19:58:16 server id 144756271  end_log_pos 115040493     GTID [commit=yes]
 SET @@SESSION.GTID_NEXT= 'd8a1a6c4-2c91-11e3-a57d-0002c952b4a4:96979502'/*!*/;
 # at 115040493
 #131221 19:58:16 server id 144756271  end_log_pos 115040537     GTID [commit=yes]
 SET @@SESSION.GTID_NEXT= 'd8a1a6c4-2c91-11e3-a57d-0002c952b4a4:96979503'/*!*/;
 # at 115040537
 #131221 19:58:16 server id 144756271  end_log_pos 115040620     Query   thread_id=24226945      exec_time=0     error_code=0
 SET TIMESTAMP=1387684696/*!*/;
 BEGIN
 INSERT INTO …
 INSERT INTO …
 COMMIT

  Slave misses the GTID 'd8a1a6c4-2c91-11e3-a57d-0002c952b4a4:96979502'.

  This situation make "change master " with auto-position fail. Though there are no slave inconsistencies.

  Are there any statements that can generate an empty GTID like this?

  I don't think there is an error while logging into statement or transaction bin log caches of the thread, since it would generate an incident event.

How to repeat:
not sure how to repeat

Here is the repro case for this bug.

Enable GTID on both master and slave.

Generate a transaction on master whose size is exactly binlog_cache_size bytes (32768 bytes). See consecutive gtids are logged on master and slave misses data. It seems the fix in http://bazaar.launchpad.net/~mysql/mysql-server/5.6/revision/5721 solves this issue.

Thank you for confirming.
This issue has been fixed as part of internal Bug #17842137 and with change log entry as in 5.6.16 http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-16.html:

"When the binary log I/O cache grew to exactly 32768 bytes and the current transaction was preceded by a transaction whose size was greater than 32768 bytes, events could be corrupted when written into the binary log. (Bug #17842137)".