Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL)
-
None
Description
If a slave crashes (unrelated) while processing an XA PREPARE such that the event fully commits in the binlog and innodb; however, crashes before updating gtid_slave_pos, attempts to restart the slave SQL thread will crash with errors such as out-of-order GTID attempt (if gtid strict mode is enabled) or XID already exists (otherwise). The following comment in Xid_apply_log_event::do_apply_event() documents this behavior.
/* |
...
|
|
XA_PREPARE_LOG_EVENT also updates the gtid table *but* the update gets
|
committed as separate "autocommit" transaction.
|
*/ |
I think logic should be added to detect the possibility of a crash happening before the separate transaction completes, and if so, automatically update gtid slave state on restart, because gtid_binlog_pos will already be updated.
Attachments
Issue Links
- causes
-
MDEV-34526 Mariadb crashed and replication got broken after MariaDB services came up
- Closed
- relates to
-
MDEV-742 LP:803649 - Xa recovery failed on client disconnection
- Closed
-
MDEV-31038 Parallel Replication Breaks if XA PREPARE Fails Updating Slave GTID State
- Closed
-
MDEV-21469 Implement crash-safe logging of the user XA
- Stalled
-
MDEV-30165 X-lock on supremum for prepared transaction for RR
- Closed