Rollback Prepared Transactions Asynchronously During Binlog Crash Recovery

[SongLibing]

Problem:

Binlog recovery can block server startup for a long time when it must roll back a large prepared internal XA transaction. The rollback runs synchronously before the server becomes available.

Solution:

Add an optional storage engine callback, recover_rollback_by_xid, for recovery-time rollback. During binlog recovery, InnoDB uses the callback to persistently convert a recovered prepared DML transaction back to ACTIVE state. The background recovery rollback thread then performs the expensive undo work asynchronously. DDL transactions still fall back to the normal synchronous rollback_by_xid path.

Add a binlog MTR test that covers prepared DML rollback, background rollback handoff, and repeated-crash safety before the rollback state change is flushed.

Copyright (c) 2026, Oracle and/or its affiliates.

What does this change do?

mysql/mysql-community#100

How was it tested?

• Added/updated MTR tests under mysql-test/
• scripts/ci/mtr.sh passes locally
• Ran the relevant full suite (name it): ______

Contributor checklist

• I have signed the OCA with the email on these commits
• Code is formatted (scripts/ci/format.sh)
• Commits are focused with descriptive messages

AI assistance

• I did not use AI assistance for this contribution
• I used AI assistance for this contribution

If AI assistance was used, describe the tool(s) and extent of use: codex, only merge code from AliSQL to trunk.

Areas touched

replication, innodb

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: SongLibing

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

[oracle-contributor-agreement]

Thank you for signing the OCA.

[henrikingo-oracle]

Thank you SongLibing for this.

We've uncovered that internally in Oracle this same issue and solution(s) have been discovered a couple years ago, discussed and documented, but not prioritized. We've made https://bugs.mysql.com/bug.php?id=114053 public so that it may benefit the review of this PR.

The review will take its time, we will probably want both a member from replication team as well as InnoDB team to look at this and this is obviously very critical part of the database, so they will take their time. Other than that everything seems to be in order now, oca signed and tests green.