DRAFT: MDEV-36025: Server start fails on mariabackup with prepared tr… - #5607
Draft
knielsen wants to merge 1 commit into
Draft
DRAFT: MDEV-36025: Server start fails on mariabackup with prepared tr…#5607knielsen wants to merge 1 commit into
knielsen wants to merge 1 commit into
Conversation
…ansactions mariabackup --no-lock can leave InnoDB prepared transactions in the restored server; this can also happen even without --no-lock when the server is running parallel replication. But mariabackup does not back up the TC_LOG state (typically binlog, or TC_LOG_MMAP if binlog is disabled). This caused the server to complain during startup that the TC_LOG state has been lost, and requires to temporarily configure the server with --tc-heuristic-recover=rollback to roll back the offending transactions. This patch implements a new value --tc-heuristic-recover=auto which makes the server automatically handle rolling back prepared transactions as needed when the TC_LOG state is missing, without the user to change any configurations. This draft patch makes the new value AUTO the default. It is to be determined whether to do this in existing GA releases (eg. 10.11), or whether to make AUTO the default only in some new 13.x release and have the user explicitly configure --tc-heuristic-recover=auto in existing GA releases if they need it. The old behaviour of --tc-heuristic-recover does not seem very useful. If the TC_LOG state is intentionally removed by the user, the correct behaviour seems obviously to be to roll back any prepared transactions. The purpose of having those internal prepared transactions in the first place is to ensure consistency between the engine and the binlog, this has no meaning if the binlog is gone. Or to ensure consistency between engines in multi-engine transactions, and rolling back will ensure this consistency (while commit may not). Note that the prepare step for these transactions is completely internal to the server, and there is no visible semantic different for the user between the backup snapshot occurring just before or just after a transaction ends up as "prepared". Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…ansactions
mariabackup --no-lock can leave InnoDB prepared transactions in the restored server; this can also happen even without --no-lock when the server is running parallel replication. But mariabackup does not back up the TC_LOG state (typically binlog, or TC_LOG_MMAP if binlog is disabled). This caused the server to complain during startup that the TC_LOG state has been lost, and requires to temporarily configure the server with --tc-heuristic-recover=rollback to roll back the offending transactions.
This patch implements a new value --tc-heuristic-recover=auto which makes the server automatically handle rolling back prepared transactions as needed when the TC_LOG state is missing, without the user to change any configurations.
This draft patch makes the new value AUTO the default. It is to be determined whether to do this in existing GA releases (eg. 10.11), or whether to make AUTO the default only in some new 13.x release and have the user explicitly configure --tc-heuristic-recover=auto in existing GA releases if they need it.
The old behaviour of --tc-heuristic-recover does not seem very useful. If the TC_LOG state is intentionally removed by the user, the correct behaviour seems obviously to be to roll back any prepared transactions. The purpose of having those internal prepared transactions in the first place is to ensure consistency between the engine and the binlog, this has no meaning if the binlog is gone. Or to ensure consistency between engines in multi-engine transactions, and rolling back will ensure this consistency (while commit may not).
Note that the prepare step for these transactions is completely internal to the server, and there is no visible semantic different for the user between the backup snapshot occurring just before or just after a transaction ends up as "prepared".