Bug #70536 | can't use LOGICAL_CLOCK if gtid is enabled | ||
---|---|---|---|
Submitted: | 6 Oct 2013 14:05 | Modified: | 21 Oct 2013 16:15 |
Reporter: | zhai weixiang (OCA) | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
Version: | 5.7.2 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[6 Oct 2013 14:05]
zhai weixiang
[6 Oct 2013 14:07]
zhai weixiang
correct the Synopsis
[10 Oct 2013 19:46]
Sveta Smirnova
Thank you for the report. Verified as described.
[10 Oct 2013 19:49]
Sveta Smirnova
test case for MTR
Attachment: rpl_bug70536.test (application/octet-stream, text), 1.23 KiB.
[10 Oct 2013 19:50]
Sveta Smirnova
slave option file, master's should have same options
Attachment: rpl_bug70536-slave.opt (application/octet-stream, text), 74 bytes.
[21 Oct 2013 16:15]
Jon Stephens
Documented fix in the MySQL 5.7.3 changelog, as follows: When GTIDs were used with an intra-schema multi-threaded slave, transactions were assigned to the first worker thread only. Closed.
[4 Dec 2013 10:57]
Laurynas Biveinis
mysql-server$ bzr log -r 6741 ------------------------------------------------------------ revno: 6741 committer: Rohit Kalhans<rohit.kalhans@oracle.com> branch nick: mysql-trunk timestamp: Mon 2013-10-21 11:42:47 +0530 message: BUG#17590616:CAN'T USE LOGICAL_CLOCK IF GTID IS ENABLED Problem: When GTID is used with Intra-schema multi-threaded slave the transactions are only assigned to the first worker, thereby compromizing the multi-threaded nature of replication slave. Background: Master stores the commit parent in the first query of a transaction (i.e. BEGIN query) if GTID is disabled or in GTID event if GTID is enabled. But in the slave we called the scheduler method for both the GTID event and the begin event. But since in case of GTID the BEGIN event does not have the commit parent, the scheduler logic blocks the execution of the event until the previous transaction is applied completely. This causes the slave coordinator to always assign the event to the first worker only. Fix: We fix this problem by calling the scheduler method for the "BEGIN" only when the coordinator has not seen the GTID event already. This ensures that it is never called for the first event of the transaction when GTID is enabled.