Rollback Prepared Transactions Asynchronously During Binlog Crash Recovery

Design review

#711

Implementation

#711

Problem / use case

MySQL crash recovery can spend a very long time rolling back a large prepared transaction in the server main startup thread. During that time, mysqld has started as a process but the server is still unavailable to users.

One common production trigger is a large transaction that fills the disk while writing its binary log. With the default binlog_error_action=ABORT_SERVER, a fatal binlog write error aborts the server. After restart, binlog crash recovery finds that the transaction was prepared in InnoDB but its XID was not durably recorded as committed in the binary log, so the transaction must be rolled back. If the transaction is very large, synchronous rollback can block startup for hours.

This proposal makes rollback of such binlog-recovered prepared DML transactions asynchronous:

1. During binlog recovery, the main thread only changes the recovered prepared transaction into a recovered active transaction and persists that state transition.
2. The existing InnoDB recovery rollback background thread performs the expensive row-by-row undo work.

The transaction outcome remains unchanged. Transactions that binlog recovery decides to roll back are still rolled back. The optimization moves the expensive rollback work out of the startup-critical path after the recovery decision has been made crash-safe.

User / Developer Stories

• As a DBA, I want the server could provide services as soon as possible at startup.

References

https://mariadb.com/resources/blog/rollback-prepared-transactions-asynchronously-during-binlog-crash-recovery/

Background / Context

No response

Intended outcome

• Add an optional storage-engine callback for recovery-time asynchronous rollback of a prepared XID.
• Use the callback during binlog / XA recovery only after the transaction coordinator decision says the internal prepared transaction must be rolled back.
• Implement the callback in InnoDB by converting eligible prepared DML transactions into recovered active transactions
• Keep prepared DDL rollback synchronous, because DDL log recovery and dictionary recovery require the DDL side effects to be settled before startup continues.
• Keep the existing synchronous rollback_by_xid path as a fallback for engines without the callback.
• Add crash tests for first restart, repeated crash, DDL/DML mixed recovery.

High level scope and dependencies

Affected components: replication, innodb

Acceptance criteria

The time binlog recovery spends rolling back a recovered prepared DML transaction SHOULD be independent of the transaction's size. Binlog recovery MUST NOT wait for row-by-row undo of a recovered prepared DML transaction. The server MUST be able to complete startup while the transaction remains observable as ROLLING BACK.