Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
10.2.7-1
Description
InnoDB I/O and buffer pool interfaces and the redo log format have been changed between MariaDB 10.1 and 10.2, and the backup code has to be adjusted accordingly.
The Mariabackup code will been simplified, and many memory leaks will be fixed. Instead of the file name xtrabackup_logfile, the file name ib_logfile0 will be used for the copy of the redo log. Unnecessary InnoDB startup and shutdown and some unnecessary threads will be removed.
Parameters will be cleaned up and aligned with those of MariaDB 10.2.
By default, innodb_doublewrite=OFF, so that --prepare works faster. If more crash-safety for --prepare is needed, doublewrite can be enabled.
The parameter innodb_log_checksums=OFF can be used to ignore redo log checksums in --backup.
Some messages will be cleaned up. Unless --export is specified, Mariabackup will not deal with undo log. The InnoDB mini-transaction redo log is not only about user-level transactions; it is actually about mini-transactions. To avoid confusion, we will call it the redo log, not transaction log.
We disable any undo log processing in --prepare without --export. 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, --prepare by itself will only apply the redo log.
In addition to disabling any undo log processing, we will disable any further changes to data pages during --prepare, including the change buffer merge. This means that restoring incremental backups should reliably work even when change buffering is being used on the server. Because of this, preparing a backup will not generate any further redo log, and the redo log file can be safely deleted.
This means that the following options are redundant and have been removed:
xtrabackup --apply-log-only
innobackupex --redo-only
In the initial implementation, the --export option will be disabled. If it is enabled in the future, it must generate redo log when processing undo logs and buffered changes. It will also involve a full server restart.
For proper restore and handling of partial backups, we should consider fixing MDEV-11898 in the server. Because --prepare will not deal with anything else than the redo log, it would not drop any excluded tables either. Maybe we should do that in the server proper.
Attachments
Issue Links
- causes
-
MDEV-14499 Mariabackup 10.2 fails to back up a multi-file InnoDB system tablespace
- Closed
- is blocked by
-
MDEV-12272 port WL#7488: InnoDB startup refactoring
- Closed
- relates to
-
MDEV-11898 tablespace does not exist or is just being dropped
- Closed
-
MDEV-13466 Implement --export option for MariaDB Backup
- Closed
-
MDEV-13574 Memory leak in mariabackup.incremental_backup
- Closed
-
MDEV-9566 Add xtrabackup tool to MariaDB 10.1
- Closed
-
MDEV-12367 Upgrade from previous versions to 10.2 with innodb-read-only does not work
- Closed
-
MDEV-12773 xtrabackup --prepare may hang with 'Waiting for 1 active transactions to finish'
- Closed
-
MDEV-15522 Change galera suite MTR tests to use mariabackup instead of xtrabackup
- Closed