Details
-
Bug
-
Status: In Progress (View Workflow)
-
Critical
-
Resolution: Unresolved
-
10.4, 10.5, 10.6, 10.11, 11.1, 11.2, 11.3
-
None
Description
This ticket covers XA binlog-based crash-recovery to base on and complement MDEV-32830/MDEV-31949 patch. MDEV-32830 refines XA prepare binlogging in that
the XA engine branches get prepared first.
The recovery decision is largely follows the normal transaction case flow:
- when at the server recovery a xid exists in both Engines and binlog has recorded an XA completion operation, the xa transaction gets completed;
- when both contain xid in the prepared state, nothing is done;
- when a xid exists only in Engine(s)'s persistent memory, the xa transaction is rolled back.
To resolve a dilemma of whether such "orphan" (engine-only) XID did indeed missed binlogging on the eve of crash, or it was prepared some time ago (maybe in a previous server incarnation) a Xid_log_list_event is introduced to contain xid:s of prepared user xa:s at time of binlog rotation (including one that is caused by RESET MASTER).
When detected any such "veteran" still uncommitted XID must remain in the prepared state, despite not being present as XA event in binlogs at recovery.
This algorithm must comply with MDEV-21117 semisync slave recovery option.
Attachments
Issue Links
- relates to
-
MDEV-31949 slow parallel replication of user xa
-
- In Review
-