[Maria-developers] a mysterious (to me) block of code in the middle of ha_recover
Hello, The ha_recover function in MySQL 5.5.28 has a block of code in the middle of it labelled with WILL_BE_DELETED_LATER that gets compiled into mysqld. The ha_recover function in Mariadb 5.5.28a does not have this code in it. It appears that the code forces prepared transactions to be rolled back in MySQL even when mysqld is past the recover phase. Does anyone know what this code does? Does anyone know why this code exists in MySQL but not in Mariadb? Thanks
Hi, Rich! On Dec 13, Rich Prohaska wrote:
Hello,
The ha_recover function in MySQL 5.5.28 has a block of code in the middle of it labelled with WILL_BE_DELETED_LATER that gets compiled into mysqld. The ha_recover function in Mariadb 5.5.28a does not have this code in it. It appears that the code forces prepared transactions to be rolled back in MySQL even when mysqld is past the recover phase.
Does anyone know what this code does? Does anyone know why this code exists in MySQL but not in Mariadb?
Sure :) This code forces all prepared transactions to be rolled back on manual recovery. There are two ways to recover after a crash - an automatic one, that uses the log of committed transactions (binlog or TC_LOG_MMAP), or a manual one - which is used when automatic recovery fails, basically, if the transaction log is lost. A manual recovery is activated by the --tc-heuristic-recover switch. If the automatic recovery fails, the data will probably end up being inconsistent. It is possible that a certain transaction was prepared in one engine and already committed or rolled back in another. As the log is unavailable, there is no automatic way to know what to do with the prepared transaction. Now, if there can be only one XA-capable storage engine - which is the case in MySQL - then it's safe to rollback all prepared transactions in case of the manual recovery. There can be no inconsistency. In fact, there is no need to use the --tc-heuristic-recover switch, the server can force it internally and rollback all prepared transactions if the automatic recovery fails. This is also the backward (pre-XA) compatible behavior, when InnoDB was rolling back all uncommitted transactions on recovery. This is exactly what I did in that piece of code. First, it asserts that InnoDB is the only XA-capable storage engine. Then it forces the rollback of all prepared transactions in case the info.commit_list (the list of committed transactions from binlog) is empty. MariaDB supports more than one XA-capable engine, so this piece of code was removed. Regards, Sergei
participants (2)
-
Rich Prohaska -
Sergei Golubchik