Xtrabackup backup principle:
physical backup, no table lock, how to ensure that the existing data (there are uncommitted or committed but unsynchronized transactions during the backup process) are consistent with the copied data?
We know that MySQL modification operations are first recorded in the ib_logfile log file, and then synchronized to the disk, and this file is reused. During replication, a thread is started to monitor the ib_logfile log file. If there is a modification, the new content will be copied to the Logfile file from the last recorded log sequence number (checkpoints). After the replication is completed, the logfile transaction log is rolled back, and the unfinished transactions are synchronized to ibdata1 and ibd to ensure data consistency. This is the same as restoring basic operations after Mysql crashes.
Preparation before testing:
1. Install mysql on CentOS6.8
[root@Paul ~]# yum install -y mysql-server mysql-client
2. Download percona-xtrabackup on the official website of percona, and install
[root@Paul ~]# rpm -ivh percona-xtrabackup-2.0.0-417.rhel6.x86_64.rpm
3. Install mysql with RPM package The default sql_log_bin is closed, we You need to open the binary log
4. Create databases and tables in mysql, and insert data and backup directories.
Test full backup and restore with xtrabackup
1、完全备份
[root@Paul backup]# innobackupex --user=root --password=123456 /root/backup
[root@Paul backup]# ls /root/backup/2018-04-23_13-45-50/
backup-my.cnf ibdata1 jiaowu mysql test xtrabackup_binary xtrabackup_binlog_info xtrabackup_checkpoints xtrabackup_logfile
Explanation of the generated file after backup:
backup-my.cnf -------------- Configuration option information used by the backup command
xtrabackup_binary ------ The executable file of xtrabackup used in the backup
xtrabackup_binlog_info ---- the binary log file currently being used by the mysql server and the location of the binary log event up to the moment of backup
xtrabackup_checkpoints ----- backup type (such as full or incremental), backup status (such as whether it has been prepared) and LSN (Log Sequence Number) range information
2. Prepare a full backup
In general, after the backup is completed, the data cannot be used for recovery operations, because the backup data may
contain uncommitted transactions or transactions that have been committed but have not yet been synchronized to the data file. . Therefore, the data files are still
in an inconsistent state at this point. The main function of "prepare" is to make the data file in a consistent state by rolling back uncommitted transactions and synchronizing committed
transactions to the data file.
[root@Paul ~]# innobackupex --apply-log /root/backup/2018-04-23_13-45-50/
3. Use a full backup to restore data
[root@Paul backup]# rm -rf /var/lib/mysql/* Delete all files in the database to simulate database downtime
[root@Paul backup]# innobackupex --copy-back /root /backup/2018-04-23_13-45-50/
[root@Paul backup]# chown -R mysql.mysql /var/lib/mysql
The test uses xtrabackup to do a full backup, a differential backup, and an incremental backup, and then the mysql service goes
down , and the transaction log is used to restore in time.
做完全备份
[root@Paul backup]# innobackupex --user=root --password=123456 /root/backup
[root@Paul backup]# innobackupex --apply-log /root/backup/2018-04-23_14-22-11/
Insert data into the tutors table for incremental:
mysql> update tutors set Tname='apple' where TID=1;
Do a differential backup, using /root/backup/2018-04-23_14-22-11/ as the base table
[root@Paul backup]# innobackupex --user=root --password=123456 --incremental /root/backup -- incremental-basedir=/root/backup/2018-04-23_14-22-11/
Insert data into the tutors table:
mysql> update tutors set Tname='banana' where TID=2;
做增量备份，以/root/backup/2018-04-23_14-41-15/
[root@Paul backup]# innobackupex --user=root --password=123456 --incremental /root/backup/ --incremental-basedir=/root/backup/2018-04-23_14-41-15/
Restoration of Incremental Backups Restoration of
Incremental Backups requires 3 steps
- Restoring a full backup
- Restore the incremental backup to the full backup (add the --redo-only parameter to the incremental backup that starts to restore, and remove the --redo-only parameter to the last incremental backup)
- The most complete backup for recovery, rollback of uncommitted data
#Prepare a full backup#
root@Paul backup]# innobackupex --apply-log --redo-only /root/backup/2018-04-23_14-22-11/
#Apply differential backup to full backup#
[root@Paul backup]# innobackupex --apply-log --redo-only /root/backup/2018-04-23_14-22-11/ --incremental-dir=/root /backup/2018-04-23_14-41-15/ #Apply
incremental backup to full backup#
[root@Paul backup]# innobackupex --apply-log --redo-only /root/backup/2018-04- 23_14-22-11 --incremental-dir=/root/backup/2018-04-23_14-48-22/ #Apply
all the combined full backups as a whole and roll back uncommitted data#
[root @Paul backup]# innobackupex --apply-log /root/backup/2018-04-23_14-22-11
#The last incremental update#
mysql> update tutors set Tname='orange' where TID=3;
Simulation test:
record the last incremental update binary log location
[root@Paul 2018-04-23_14-48-22]# more xtrabackup_binlog_info
mysql-bin.000001 517
Backup binary file
[root@Paul ~]# mysqlbinlog -j 517 / var/lib/mysql/mysql-bin.000001 > /root/backup/mysql-bin.sql
[root@Paul ~]# cp /root/backup/mysql-bin.sql /tmp/
#Delete all files in /var/lib/mysql/#
[root@Paul ~]# rm -rf /var/lib/mysql/*
全备恢复
[root@Paul ~]# innobackupex --copy-back /root/backup/2018-04-23_14-22-11
root@Paul ~]# chown -R mysql.mysql /var/lib/mysql
[root@Paul ~]# service mysqld stop
[root@Paul ~]# service mysqld start
Binary timely restore
mysql> set sql_log_bin=0;
mysql> SOURCE /tmp/mysql-bin.sql
mysql> set sql_log_bin=1