The Ultimate Guide to High Availability with MariaDB

Files Created by Mariabackup

You are viewing an old version of this article. View the current version here.

Mariabackup creates the following files:

backup-my.cnf

During the backup, any server options relevant to Mariabackup are written to this file, so that they can be re-read later during the --prepare stage.

ib_logfile0

In the non-prepared backup, ib_logfile0 contains all of the InnoDB redo log copied during the backup. During the --prepare stage, ib_logfile0 is initialized as an empty InnoDB redo log file.

See Mariabackup Overview: Redo Log Files for more information.

xtrabackup_binlog_info

This file stores the binary log coordinates and the gtid_current_pos value that correspond to the backup. The positions in this file are only guaranteed to be consistent if the --no-lock option is not provided.

xtrabackup_binlog_pos_innodb

Mariabackup inherited this file from Percona XtraBackup 2.3. However, this file is only safe to use with Percona Server versions that have a special lockless binary log feature.

This feature is described by the Percona Server documentation:

Starting with Percona Server for MySQL 5.6.26-74.0 LOCK TABLES FOR BACKUP flushes the current binary log coordinates to InnoDB. Thus, under active LOCK TABLES FOR BACKUP, the binary log coordinates in InnoDB are consistent with its redo log and any non-transactional updates (as the latter are blocked by LOCK TABLES FOR BACKUP). It is planned that this change will enable Percona XtraBackup to avoid issuing the more invasive LOCK BINLOG FOR BACKUP command under some circumstances.

And the way it's used by Percona XtraBackup 2.3 is described by the Percona XtraBackup 2.3 documentation:

Percona XtraBackup implemented support for lock-less binary log information in 2.3.2. When the Lockless binary log information feature is available [1] on the server, Percona XtraBackup can trust binary log information stored in the InnoDB system header and avoid executing LOCK BINLOG FOR BACKUP (and thus, blocking commits for the duration of finalizing the REDO log copy) under a number of circumstances:

  • when the server is not a GTID-enabled Galera cluster node
  • when the replication I/O thread information should not be stored as a part of the backup (i.e. when the xtrabackup --slave-info option is not specified)

See MDEV-18917 for more information.

xtrabackup_checkpoints

This file contains information about the type of the backup and the status of the backup.

backup_type

If the backup is a non-prepared full backup, then the file contains backup_type =full-backuped.

If the backup has already been prepared, then the file contains backup_type = log-applied.

xtrabackup_info

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.