Understanding InnoDB Undo Segment States and MySQL XA Transaction Crash Recovery (MySQL 8.0.30)

Background: InnoDB uses undo logs stored in undo segments to ensure crash‑safe recovery; during transaction prepare the TRX_UNDO_STATE field is set to TRX_UNDO_PREPARED , guaranteeing persistence once all redo logs are flushed.

During crash recovery the undo segment state determines whether a transaction is rolled back ( TRX_UNDO_ACTIVE ) or examined further ( TRX_UNDO_PREPARED ).

MySQL XA transactions involve an application (AP), resource manager (RM), and transaction manager (TM). XA follows a two‑phase commit: PREPARE and COMMIT/ROLLBACK, with MySQL acting as RM and the client as TM.

Prior to MySQL 8.0.30, external XA transactions were not crash‑safe because the XA PREPARE log could be written to the binlog before the InnoDB undo state was persisted, leading to inconsistencies.

MySQL 8.0.30 introduced a new undo state TRX_UNDO_PREPARED_IN_TC and changed the XA PREPARE order to write the binlog first, then set the InnoDB undo state, making external XA transactions crash‑safe.

The crash‑recovery algorithm scans the last binlog for XA_PREPARE events, records the XID and state, passes this information to InnoDB, and then updates transaction states according to the enum enum_ha_recover_xa_state . Various edge cases (e.g., crash after binlog write, before undo state change) are handled explicitly.

Code snippets illustrate the undo‑state constants, the prepare order, and the recovery functions Xa_state_list::add and xa::recovery::recover_one_ht .