Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: 10.0.14
-
Fix Version/s: 10.0.16
-
Component/s: Replication
-
Labels:None
Description
In the situation of master crash discussed in https://mariadb.atlassian.net/browse/MDEV-6462 slave can recover now in terms that the partial transaction is rolled back and SQL thread execution position points to the same place in master's binlog as IO thread current position. But gtid_slave_pos is increased and contains GTID of the transaction that was never committed. Besides the confusion of what gtid_current_pos points to in such situation it can also lead to slaves skipping one transaction from master's binlog when writes continue to restarted master.
I'm attaching the one-line patch that fixes the problem along with extension to tests added in MDEV-6462 to check correctness of gtid_slave_pos. The patch also has one more test case that was showing transaction loss without the code fix. The patch is on top of latest 10.0 branch.
Note that the problem feels like https://mariadb.atlassian.net/browse/MDEV-4906 wasn't fixed fully. And the patch makes me wonder: should gtid_sub_id be actually reset to 0 inside cleanup_context()? Maybe without that there could be some other situations when gtid_slave_pos is wrong and has GTID of a rolled back transaction?
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
The patch I've attached before had test that was flaky and didn't reproduce the transaction loss on the slave consistently. Attaching the new one with the corrected test.
Pushed to 10.0.16, thanks Pavel for tracking it down and for the test case!
Thanks for tracking this down!
I share your concern wrt. possible other similar situations. I will check this in the code before applying the fix.