Skip to content

DRAFT: MDEV-36025: Server start fails on mariabackup with prepared tr… - #5607

Draft
knielsen wants to merge 1 commit into
10.11from
knielsen_mdev36025
Draft

DRAFT: MDEV-36025: Server start fails on mariabackup with prepared tr…#5607
knielsen wants to merge 1 commit into
10.11from
knielsen_mdev36025

Conversation

@knielsen

Copy link
Copy Markdown
Member

…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".

…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>
@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants