Files Created by Mariabackup
Mariabackup creates the following files:
backup-my.cnf
During the backup, any server options relevant to Mariabackup are written to the backup-my.cnf
option file, so that they can be re-read later during the --prepare
stage.
ib_logfile0
In MariaDB 10.2.10 and later, Mariabackup creates an empty InnoDB redo log file called ib_logfile0
as part of the --prepare
stage. This file has 3 roles:
- In the source server,
ib_logfile0
is the first (and possibly the only) InnoDB redo log file. - In the non-prepared backup,
ib_logfile0
contains all of the InnoDB redo log copied during the backup. Previous versions of Mariabackup would use a file calledxtrabackup_logfile
for this. - During the
--prepare
stage,ib_logfile0
would previously be deleted. Now during the--prepare
stage,ib_logfile0
is initialized as an empty InnoDB redo log file. That way, if the backup is manually restored, any pre-existing InnoDB redo log files would get overwritten by the empty one. This helps to prevent certain kinds of known issues. For example, see Mariabackup Overview: Manual Restore with Pre-existing InnoDB Redo Log files.
xtrabackup_logfile
In MariaDB 10.2.9 and before, Mariabackup creates xtrabackup_logfile
to store the InnoDB redo log, In later versions, ib_logfile0
is created instead.
xtrabackup_binlog_info
This file stores the binary log file name and position that corresponds to the backup.
This file also stores the value of the gtid_current_pos
system variable that correspond to the backup.
For example:
mariadb-bin.000096 568 0-1-2
The values in this file are only guaranteed to be consistent with the backup if the --no-lock
option was not provided when the backup was taken.
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)
Mariabackup no longer creates this file starting with MariaDB 10.1.39, MariaDB 10.2.23, MariaDB 10.3.14, and MariaDB 10.4.4.
See MDEV-18917 for more information.
xtrabackup_checkpoints
The xtrabackup_checkpoints
file contains metadata about the backup.
For example:
backup_type = full-backuped from_lsn = 0 to_lsn = 1635102 last_lsn = 1635102 recover_binlog_info = 0
See below for a description of the fields.
If the --extra-lsndir
option is provided, then an extra copy of this file will be saved in that directory.
backup_type
If the backup is a non-prepared full backup or a non-prepared partial backup, then backup_type
is set to full-backuped
.
If the backup is a non-prepared incremental backup, then backup_type
is set to incremental
.
If the backup has already been prepared, then backup_type
is set to log-applied
.
from_lsn
If backup_type
is full-backuped
, then from_lsn
has the value of 0
.
If backup_type
is incremental
, then from_lsn
has the value of the log sequence number (LSN) at which the backup started reading from the InnoDB redo log. This is internally used by Mariabackup when preparing incremental backups.
This value can be manually set during an incremental backup with the --incremental-lsn
option. However, it is generally better to let Mariabackup figure out the from_lsn
automatically by specifying a parent backup with the --incremental-basedir
option.
to_lsn
to_lsn
has the value of the log sequence number (LSN) of the last checkpoint in the InnoDB redo log. This is internally used by Mariabackup when preparing incremental backups.
last_lsn
last_lsn
has the value of the last log sequence number (LSN) read from the InnoDB redo log. This is internally used by Mariabackup when preparing incremental backups.
xtrabackup_info
The xtrabackup_info
file contains information about the backup. The fields in this file are listed below.
If the --extra-lsndir
option is provided, then an extra copy of this file will be saved in that directory.
uuid
If a UUID was provided by the --incremental-history-uuid
option, then it will be saved here. Otherwise, this will be the empty string.
name
If a name was provided by the --history
or the ---incremental-history-name
options, then it will be saved here. Otherwise, this will be the empty string.
tool_name
The name of the Mariabackup executable that performed the backup. This is generally mariabackup
.
tool_command
The arguments that were provided to Mariabackup when it performed the backup.
tool_version
The version of Mariabackup that performed the backup.
ibbackup_version
The version of Mariabackup that performed the backup.
server_version
The version of MariaDB Server that was backed up.
start_time
The time that the backup started.
end_time
The time that the backup ended.
lock_time
The amount of time that Mariabackup held its locks.
binlog_pos
This field stores the binary log file name and position that corresponds to the backup.
This field also stores the value of the gtid_current_pos
system variable that correspond to the backup.
The values in this field are only guaranteed to be consistent with the backup if the --no-lock
option was not provided when the backup was taken.
innodb_from_lsn
This is identical to from_lsn
in xtrabackup_checkpoints
.
If the backup is a full backup, then innodb_from_lsn
has the value of 0
.
If the backup is an incremental backup, then innodb_from_lsn
has the value of the log sequence number (LSN) at which the backup started reading from the InnoDB redo log.
innodb_to_lsn
This is identical to to_lsn
in xtrabackup_checkpoints
.
innodb_to_lsn
has the value of the log sequence number (LSN) of the last checkpoint in the InnoDB redo log.
partial
If the backup is a partial backup, then this value will be Y
.
Otherwise, this value will be N
.
incremental
If the backup is an incremental backup, then this value will be Y
.
Otherwise, this value will be N
.
format
This field's value is the format of the backup.
If the --stream
option was set to xbstream
, then this value will be xbstream
.
If the --stream
option was not provided, then this value will be file
.
compressed
If the --compress
option was provided, then this value will be compressed
.
Otherwise, this value will be N
.
xtrabackup_slave_info
If the --slave-info
option is provided, then this file contains the CHANGE MASTER
command that can be used to set up a new server as a slave of the original server's master after the backup has been restored.
Mariabackup does not check if GTIDs are being used in replication. It takes a shortcut and assumes that if the gtid_slave_pos
system variable is non-empty, then it writes the CHANGE MASTER
command with the MASTER_USE_GTID
option set to slave_pos
. Otherwise, it writes the CHANGE MASTER
command with the MASTER_LOG_FILE
and MASTER_LOG_POS
options using the master's binary log file and position. See MDEV-19264 for more information.
xtrabackup_galera_info
If the --galera-info
option is provided, then this file contains information about a Galera Cluster node's state.
The file contains the values of the wsrep_local_state_uuid
and wsrep_last_committed
status variables.
The values are written in the following format:
wsrep_local_state_uuid:wsrep_last_committed
For example:
d38587ce-246c-11e5-bcce-6bbd0831cc0f:1352215
<table>.delta
If the backup is an incremental backup, then this file contains changed pages for the table.
<table>.delta.meta
If the backup is an incremental backup, then this file contains metadata about <table>.delta
files. The fields in this file are listed below.
page_size
This field contains either the value of innodb_page_size
or the value of the KEY_BLOCK_SIZE
table option for the table if the ROW_FORMAT
table option for the table is set to COMPRESSED
.
zip_size
If the ROW_FORMAT
table option for this table is set to COMPRESSED
, then this field contains the value of the compressed page size.
space_id
This field contains the value of the table's space_id
.
© 2021 MariaDB
Licensed under the Creative Commons Attribution 3.0 Unported License and the GNU Free Documentation License.
https://mariadb.com/kb/en/files-created-by-mariabackup/