Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5
-
None
Description
When using Mariabackup to create a slave, the slave had XA transactions active which stopped the slave from working.
The easiest way to fix this is that when mariabackup runs recover on the backup, set up --tc-heuristic-recover=ROLLBACK.
This will ensure that any XA prepared transaction are rolled back on the slave.
This is the correct thing to do as the gtid position that is copied as part of mariabackup doesn't have any part of the XA transactions and when starting the slave against the master, the XA transaction will be copied to the slave.
Attachments
Issue Links
- is blocked by
-
MDEV-742 LP:803649 - Xa recovery failed on client disconnection
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Open
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- split to
-
-
- Closed
-
Activity
julien.fritsch, vlad.lesin: First, it's correct MDEV-742 fixes the issue, a prepared XA can be involved into backup image safely with it. Yet its porting to earlier versions could
be rather problematic (not least 'cos of a new replication event type in there).
I believe that we cannot claim this to work correctly without the fix of MDEV-22398. The server would start up with a too small LSN that it reads from the system tablespace. mariabackup --prepare or mariabackup --copy-back would force the subsequent server startup to read the LSN from there, because there would be no redo log file to start with.
Starting InnoDB with wrong LSN can potentially cause serious corruption of all InnoDB data files.
Before MDEV-22398 is fixed, it is not safe to use the option that was introduced in 10.2, 10.3, 10.4 (not 10.5) by this change:
mariabackup --prepare --rollback-xa …
|
Just for the note, --apply-log-only was removed in this commit:
commit 8c71c6aa8b9f4c78cfa164fad1d324ba0cf9b888
|
Author: Marko Mäkelä <marko.makela@mariadb.com>
|
Date: Fri Jun 30 10:49:37 2017 +0300
|
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2
|
....
|
Because MariaDB 10.2 supports indexed virtual columns, the
|
undo log processing would need to be able to evaluate virtual column
|
expressions. To reduce the amount of code dependencies, we will not
|
process any undo log in prepare.
|
This means that the --export option must be disabled for now.
|
This also means that the following options are redundant
|
and have been removed:
|
xtrabackup --apply-log-only
|
innobackupex --redo-only
|
...
|
MDEV-742 did fix the slave side issue that this ticket has in the summary. However --rollback-xa may be needed when
the backup image is planned to be restored on a general non-slave server. That server would not be going to communicate with
the backup donor so can not find out automatically commit-or-rollback decisions for prepared user xa:s.
See MDEV-30794.
For what it is worth, I would like to make the mariabackup --prepare step optional, and allow the server to start directly on the backup directory. With the redo log format changes in
MDEV-12353andMDEV-14425, it should be possible to inject the --incremental log to the backed-up log file, instead of writing separate .delta files. I do not think that all this can be implemented before the 10.5 GA release.