[MDEV-17304] Replace use of XtraBackup with MariaDB Backup Created: 2018-09-27  Updated: 2018-12-18  Resolved: 2018-12-18

Status: Closed
Project: MariaDB Server
Component/s: Galera SST
Fix Version/s: 10.4.1, 10.2.20, 10.3.12

Type: Task Priority: Critical
Reporter: Rasmus Johansson (Inactive) Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 1
Labels: None

Issue Links:
Relates
relates to MDEV-12289 Keep 128 persistent rollback segments... Closed
relates to MDEV-13564 TRUNCATE TABLE and undo tablespace tr... Closed
relates to MDEV-15522 Change galera suite MTR tests to use ... Closed
relates to MDEV-16913 Correct documentation of xtrabackup a... Closed
relates to MDEV-17835 Remove wsrep-sst-method=xtrabackup Closed

 Description   

XtraBackup doesn't work with MariaDB Server 10.1 and newer. You might not notice it, but you can end up with inconsistent backups.

  • For Galera there are scripts for SST that make use of XtraBackup. These should be updated to use MariaDB Backup instead.
  • Galera tests using XtraBackup should also be updated


 Comments   
Comment by Marko Mäkelä [ 2018-09-27 ]

I would expect XtraBackup to work with MariaDB Server 10.1, except when page_compressed or encrypted tables are present.

With MariaDB Server 10.2, I would expect some trouble due to MDEV-12289. MySQL 5.7 changed the transaction system format in such a way that an upgrade from earlier versions can be affected.

MariaDB 10.2 with MDEV-12289 fixed will allow upgrade from earlier MariaDB and MySQL versions. Xtrabackup contains some logic that will handle undo log records, and it is possible that this logic is compatible with the MySQL 5.7 format but not the earlier format. I am not aware of related failures, but I have also not tested it.

The crash-downgrade protection required by the undo log format change related to MDEV-13564 will prevent XtraBackup from working.

XtraBackup never worked with MariaDB Server 10.3, because the redo log format (and identifier) was changed.

Generated at Thu Feb 08 08:35:27 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.