Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5(EOL), 10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL)
Description
We should revert part of this InnoDB change in MySQL 5.0.3 (making innodb_force_recovery=1 and innodb_force_recovery=2 initiate rollback of a transaction that reached the XA PREPARE state before previous crash or shutdown) (March 2005).
It seems that the option tc_heuristic_recover=ROLLBACK in MySQL 5.0.3 (January 2005) was introduced for exactly this purpose; there was no need to convolute the logic of an already confusing InnoDB parameter.
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
Before this change, when preparing a backup, Mariabackup 10.1 would unconditionally roll back transactions that were recovered in XA PREPARE state. Starting with Mariabackup 10.1.27, such transactions will be left alone.
Mariabackup for MariaDB 10.2 (first released as version 10.2.7) does not process any undo log records or change any transaction state. (Even the --export option is not supported before MDEV-13466 implements it.)
As a result of this change, setting innodb_force_recovery=3 will no longer hide recovered XA PREPARE transactions from the server.
If the binlog is enabled and internally acts as a XA resource manager for cross-engine transactions, this means that also with innodb_force_recovery=3, decisions to XA COMMIT or XA ROLLBACK based on the binlog contents will continue to be made. This affects the way how MDEV-13437 can be reproduced.
Actually the questionable logic for rolling back XA PREPARE transactions was added already in a March 1, 2005 commit, that is, 12 days before the refactoring, which also added innodb_support_xa that was made a no-op in MySQL 5.7.10 and MariaDB 10.2.6 and removed in MariaDB 10.3.0.