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:
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version: OS:Any
Assigned to: CPU Architecture:Any

[4 Feb 2014 3:59] Ben Krug
  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/*!*/;

  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
[30 Mar 2014 9:10] Santosh Praneeth Banda
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.
[25 Feb 2015 4:54] Umesh Shastry
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)".