How innobackupex Works¶
innobackupex is a script written in Perl that wraps the xtrabackup and performs the tasks where the performance and efficiency of C program isn’t needed. In this way, it provides a convenient and integrated approach to backing up in many common scenarios.
The following describes the rationale behind innobackupex actions.
Making a Backup¶
If no mode is specified, innobackupex will assume the backup mode.
By default, it starts xtrabackup with the
--suspend-at-end option, and lets it copy the InnoDB data files. When xtrabackup finishes that, innobackupex sees it create the
xtrabackup_suspended_2 file and executes
FLUSH TABLES WITH READ LOCK. xtrabackup will use Backup locks where available as a lightweight alternative to
FLUSH TABLES WITH READ LOCK. This feature is available in Percona Server 5.6+. Percona XtraBackup uses this automatically to copy non-InnoDB data to avoid blocking DML queries that modify InnoDB tables. Then it begins copying the rest of the files.
innobackupex will then check MySQL variables to determine which features are supported by server. Special interest are backup locks, changed page bitmaps, GTID mode, etc. If everything goes well, the binary is started as a child process.
innobackupex will wait for slaves in a replication setup if the option
--safe-slave-backup is set and will flush all tables with READ LOCK, preventing all MyISAM tables from writing (unless option
--no-lock is specified).
Locking is done only for MyISAM and other non-InnoDB tables, and only after Percona XtraBackup is finished backing up all InnoDB/XtraDB data and logs. Percona XtraBackup will use Backup locks where available as a lightweight alternative to
FLUSH TABLES WITH READ LOCK. This feature is available in Percona Server 5.6+. Percona XtraBackup uses this automatically to copy non-InnoDB data to avoid blocking DML queries that modify InnoDB tables.
When all the files are backed up, it resumes ibbackup and wait until it finishes copying the transactions done while the backup was done. Then, the tables are unlocked, the slave is started (if the option
--safe-slave-backup was used) and the connection with the server is closed. Then, it removes the
xtrabackup_suspended_2 file and permits xtrabackup to exit.
It will also create the following files in the directory of the backup:
- containing the LSN and the type of backup;
- containing the position of the binary log at the moment of backing up;
- containing the position of the binary log at the moment of backing up relative to InnoDB transactions;
- containing the MySQL binlog position of the master server in a replication setup via
SHOW SLAVE STATUSif the
--slave-infooption is passed;
- containing only the
my.cnfoptions required for the backup. For example, innodb_data_file_path, innodb_log_files_in_group, innodb_log_file_size, innodb_fast_checksum, innodb_page_size, innodb_log_block_size;
- containing the binary used for the backup;
- containing the
STDERRof mysqld during the process and
- containing the
STDOUTof the server.
Finally, the binary log position will be printed to
STDERR and innobackupex will exit returning 0 if all went OK.
Note that the
STDERR of innobackupex is not written in any file. You will have to redirect it to a file, e.g.,
innobackupex OPTIONS 2> backupout.log.
Restoring a backup¶
To restore a backup with innobackupex the
--copy-back option must be used.
It will copy the MyISAM tables, indexes, etc. (.frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV,
par and .opt files) first, InnoDB tables and indexes next and the log files at last. It will preserve file’s attributes when copying them, you may have to change the files’ ownership to
mysql before starting the database server, as they will be owned by the user who created the backup.
--move-back option may be used to restore a
backup. This option is similar to
--copy-back with the only
difference that instead of copying files it moves them to their target
locations. As this option removes backup files, it must be used with
caution. It is useful in cases when there is not enough free disk space
to hold both data files and their backup copies.