Xtrabackup is a free database hot backup software open sourced by percona. It can back up the database of InnoDB and XtraDB storage engine non-blockingly (the backup of MyISAM also needs to add table lock).
Compared with the mysqldump backup method, mysqldump is a logical backup, and the backup and recovery speed is slow, but the backup file occupies a small space. Xtrabackup is a physical backup, directly copying related files, the backup and restoration are fast, and the backup files take up a lot of space.
After Xtrabackup is installed, there are two more important backup tools are innobackupex and xtrabackup. Among them, innobackupex is the encapsulation and function extension of xtrabackup by perl script.
Installation of Xtrabackup
tar zxvf percona-xtrabackup-2.4.9-Linux-x86_64.tar.gz
Xtrabackup backup preparation
xtrabackup requires the operation authority to connect to the database and datadir. There are mainly two types of user authority involved in the use process: 1, system user (used to execute xtrabackup or innobackupex); 2, database user (user used in the database).
Create a backup user
mysql>CREATE USER 'bkuser'@'ip' identified by 'password';
mysql>grant reload,lock tables,replication client on *.* 'bkuser'@'ip' identified by 'password';
mysql>flush privileges;
start full
innobackupex --defaults-file=/etc/my.cnf --user=DBUSER --password=DBUSERPASS --slave-info --safe-slave-backup --parallel=4 --no-timestamp --backup --rsync /path/to/BACKUP-DIR
The scenario where the --slave-info parameter is applicable: Assuming that there is a master database A and a slave database B, I want to add another standby database C, and let the standby database C take the master database A as the master; because the master database A is the production Library, the pressure is generally relatively large, so we back up a database on the standby database B, then take the backup to the C server and import it into the C library, and then execute the change master command on the C server: where master_host is A's ip, and master_log_file and master_log_pos are the values in this xtrabackup_slave_info.
--rsync This parameter is generally used when the distributed database cluster
After the backup is created, the backup data at this time cannot be used for restoration. Need to roll back uncommitted things, redo committed things, and keep database files consistent.
innobackupex --apply-log --use-memory 4G /path/to/BACKUP-DIR
--use-memory: Specify the memory that can be used in the preparatory stage. The more memory, the faster the speed. The default is 10MB.
Data recovery
#Before restoring data, you need to ensure that the data directory is empty, and you need to shut down the service before restoring
[root@centos ~]# innobackupex --defaults-file=/etc/my.cnf --copy-back /path/to/BACKUP-DIR
#After restoring the past, the default is root permission, so you need to modify the group and owner
chown –R mysql.mysql /data/dbdata
/etc/rc.d/init.d/mysqld start
Xtrabackup Incremental Backup and Recovery
#It should be noted that a full backup is required before incremental backup, otherwise incremental backup is meaningless. And incremental backup can only be applied to InooDB or XtraDB tables, for MyISAM tables, incremental is the same as full backup
[root@Vcentos ~]# innobackupex --defaults-file=/etc/my.cnf --user=root --password= PWD --incremental /backup/ --incremental-basedir=/path/to/BACKUP-DIR
#--incremental /backup/ Specifies the directory where incremental backup files are backed up
#--incremental-basedir specifies the directory of the last full or incremental backup
Check the location of binlog and datadir to prevent misoperation of binlog during mv datadir, which will affect recovery (binlog and datadir must be placed separately)
show variables like '%log_bin%';
show variables like '%datadir%';
Preparing Incremental Backups
Preparing an incremental backup requires two steps
You need to prepare first, but only redo committed things, do not roll back uncommitted things. Then apply it to the full backup, and only redo the committed things, and do not roll back the uncommitted things.
rollback uncommitted transactions
On a full standby, use --redo-only to redo only committed transactions, not to roll back uncommitted transactions.
[root@Vcentos ~]# innobackupex --apply-log --redo-only /path/to/BACKUP-DIR
Apply incremental backup
[root@Vcentos ~]# innobackupex --apply-log /path/to/BACKUP-DIR --incremental-dir=/path/to/BACKUP-DIR
When applying incremental backups, they can only be applied in the order in which they were backed up. If the order is wrong, the backups are unavailable. The order can be determined using xtrabackup-checkpoints.
If the backup is not the last incremental backup, you need to add --redo-only,
Restoring an incremental backup
[root@centos ~]# innobackupex --defaults-file=/etc/my.cnf --copy-back /path/to/BACKUP-DIR
For detailed instructions, see https://max.book118.com/html/2017/0522/108428582.shtm
For full recovery of innobackupex backup + binlog log, see https://blog.csdn.net/zhang123456456/article/details/72954519
MySQL master-slave replication data consistency checksum repair method and automated implementation see https://blog.csdn.net/hangxing_2015/article/details/52585855
Binary log format Backup slave library