Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.2.15
Description
Replication using GTID and MASTER_USE_GTID=current_pos easily breaks when a transaction is generated on the Slave and Replication is restarted.
It happens if the transaction generated on the Slave is the last before issuing START SLAVE,
so even after the replication was already stopped.
To recover you need to switch to slave_pos gtid mode.
Test attached.
I also noticed a non consistent numbering of GTID, but it's not related, the trx_num part of GTID for transactions generated on the Slave is increased by one in respect to trx_num of the latest GTID received from the Master.
So you can have:
1-100-1000
1-100-1001
1-100-1002
1-200-1003
1-200-1004
1-100-1003
1-100-1004
I don't know if it's on purpose, but it does not seem consistent to me, at first impression I'd make each server having its own trx numbering with no holes.
Attachments
Issue Links
- is duplicated by
-
MDEV-21687 When creating a table in the master database, and then executing stop slave, add index, start slave in the slave database; a replication error occurred from the slave ; but there was no exception in mysql
- Closed
- relates to
-
MDEV-10279 gtid_current_pos is not updated with slave transactions from old master
- Open
-
MDEV-17156 Local transactions on a Slave don't update GTID's gtid_current_pos after RESET MASTER on Slave (master_use_gtid value is not relevant)
- Closed
-
MDEV-20122 Deprecate MASTER_USE_GTID=Current_Pos to favor new MASTER_DEMOTE_TO_SLAVE option
- Closed