Xtrabackup增量差量备份

上一篇文章中我们学习了xtrabackup的全备操作流程，这里看下他的差量与增量备份。

全量备份是差量与增量的基础，因为差量备份只能针对上一次的全量备份，增量备份则可以针对上一次任何一种备份，上一次备份可以使全备，差备或者增量备，但是不管怎么，都是要有一套全量备份作为基础的，不管是差量还是增量都是针对innodb来说的，对于MyISAM表，即使做了增量备份，其实际上也是全量备份。

 

在前面的全量备份中，我们知道在备份目录中有本次备份的详情文件：

[root@VM-75-68 2019-10-12_10-44-22]# pwd

/backup/2019-10-12_10-44-22

[root@VM-75-68 2019-10-12_10-44-22]# cat xtrabackup_checkpoints

backup_type = full-backuped

from_lsn = 0

to_lsn = 121600825

last_lsn = 121600825

compact = 0

recover_binlog_info = 0

从上面的文件中我们看到，本次备份的类型为全量备份，其中page的LSN范围为0到121600825。

 

好的，下面我们修改数据库中的数据：

mysql> select * from T;

+-----+----+------+------+

| id  | k  | name | test |

+-----+----+------+------+

|   1 |  2 | 3    | 4    |

|   2 |  3 | 4    | 5    |

|   9 |  8 | 7    | 6    |

|  11 |  8 | 7    | 6    |

|  21 |  8 | 7    | 6    |

|  23 | 45 | 6    | 789  |

| 100 |  1 | aa   | NULL |

| 200 |  2 | bb   | NULL |

| 300 |  3 | cc   | NULL |

| 400 |  4 | dd   | NULL |

+-----+----+------+------+

10 rows in set (0.00 sec)

mysql> delete from T where id in (100,200);

Query OK, 2 rows affected (0.00 sec)

mysql> insert into T values (800,55,'ZJ',121);

Query OK, 1 row affected (0.00 sec)

 

假设已经改过了一天，我们现在要执行增量备份，增量备份是针对上一次备份来说的，因此在进行增量备份时，需要指定哪一个备份作为上一次的备份，指令如下：

[root@VM-75-68 backup]# innobackupex --defaults-file=/etc/my.cnf --user=root --host=192.168.75.68 --password=51..dmz --incremental /backup --incremental-basedir=/backup/2019-10-12_10-44-22/

...

...

...

191012 14:33:25 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...

xtrabackup: The latest check point (for incremental): '121604745'

xtrabackup: Stopping log copying thread.

.191012 14:33:25 >> log scanned up to (121604745)

 

191012 14:33:25 Executing UNLOCK TABLES

191012 14:33:25 All tables unlocked

191012 14:33:25 Backup created in directory '/backup/2019-10-12_14-33-14/'

MySQL binlog position: filename 'mysql-bin.000001', position '545'

191012 14:33:25 [00] Writing backup-my.cnf

191012 14:33:25 [00]        ...done

191012 14:33:25 [00] Writing xtrabackup_info

191012 14:33:25 [00]        ...done

xtrabackup: Transaction log of lsn (121604745) to (121604745) was copied.

191012 14:33:26 completed OK!

 

从返回结果看，应该是备份成功了，看下指令的具体内容：

--incremental：表示创建一个增量备份

/backup：表示增量备份的存储位置

--incremental-basedir：指定一个含有full backup的全量备份为本次增量的基础，本次增量备份是针对于‘/backup/2019-10-12_10-44-22/’的增量。

其实从这里可以看到，用上面的指令就能够实现差量备份，想要实现差量备份，只要将上述命令中的--incremental-basedir选项的值每次都设定为全量备份的路径即可，当然，因为这是针对全量备份的首次增量，因此我们也能把它看作是一次差量备份！

 

[root@VM-75-68 backup]# ll

total 8

drwxr-x---. 9 root root 4096 Oct 12 10:44 2019-10-12_10-44-22

drwxr-x---. 9 root root 4096 Oct 12 14:33 2019-10-12_14-33-14

[root@VM-75-68 backup]# pwd

/backup

此时在/backup里就能看到新备份的目录了！

[root@VM-75-68 backup]# cd 2019-10-12_14-33-14

[root@VM-75-68 2019-10-12_14-33-14]# ll

total 452

-rw-r-----. 1 root root    419 Oct 12 14:33 backup-my.cnf

-rw-r-----. 1 root root 393216 Oct 12 14:33 ibdata1.delta

-rw-r-----. 1 root root     44 Oct 12 14:33 ibdata1.meta

drwxr-x---. 2 root root   4096 Oct 12 14:33 mysql

drwxr-x---. 2 root root   4096 Oct 12 14:33 ossec

drwxr-x---. 2 root root   4096 Oct 12 14:33 performance_schema

drwxr-x---. 2 root root   4096 Oct 12 14:33 relay

drwxr-x---. 2 root root   4096 Oct 12 14:33 RW

drwxr-x---. 2 root root   4096 Oct 12 14:33 test

-rw-r-----. 1 root root     21 Oct 12 14:33 xtrabackup_binlog_info

-rw-r-----. 1 root root    123 Oct 12 14:33 xtrabackup_checkpoints

-rw-r-----. 1 root root    587 Oct 12 14:33 xtrabackup_info

-rw-r-----. 1 root root   2560 Oct 12 14:33 xtrabackup_logfile

drwxr-x---. 2 root root  20480 Oct 12 14:33 zabbix

[root@VM-75-68 2019-10-12_14-33-14]#

[root@VM-75-68 2019-10-12_14-33-14]# cat xtrabackup_checkpoints

backup_type = incremental

from_lsn = 121600825                    ##起始LSN位置

to_lsn = 121604745                      ##结束LSN位置

last_lsn = 121604745

compact = 0

recover_binlog_info = 0

这里看到，本次增量备份的起始LSN位置就是上一次全量备份的结束时的LSN位置。

 

OK，假设愉快的一天又过去了，我们再次对数据进行了修改：

mysql> insert into account01 select * from account00;        ##把一张表的查询结果插入到另一张表

Query OK, 6 rows affected (0.00 sec)

Records: 6  Duplicates: 0  Warnings: 0

 

mysql> select * from account01;

+-------------+--------------+-----------+--------------+

| AccountHash | AccountID    | ZoneID    | RoleID       |

+-------------+--------------+-----------+--------------+

|           1 | 2            |         3 |            4 |

|          23 | 45           |        67 |           89 |

|    21323211 | 787492757374 | 314342426 | 989997979798 |

|    21323212 | 787492757372 | 314342422 | 989997979799 |

|    21323213 | 787492757375 | 314342425 | 989997979791 |

|    21323214 | 787492757376 | 314342427 | 989997979795 |

+-------------+--------------+-----------+--------------+

6 rows in set (0.00 sec)

 

mysql> delete from account01 where RoleID=4;

Query OK, 1 row affected (0.01 sec)

 

mysql> select * from account01;             

+-------------+--------------+-----------+--------------+

| AccountHash | AccountID    | ZoneID    | RoleID       |

+-------------+--------------+-----------+--------------+

|          23 | 45           |        67 |           89 |

|    21323211 | 787492757374 | 314342426 | 989997979798 |

|    21323212 | 787492757372 | 314342422 | 989997979799 |

|    21323213 | 787492757375 | 314342425 | 989997979791 |

|    21323214 | 787492757376 | 314342427 | 989997979795 |

+-------------+--------------+-----------+--------------+

5 rows in set (0.00 sec)

 

ok，我们再次执行增量备份指令：

[root@VM-75-68 backup]# innobackupex --defaults-file=/etc/my.cnf --user=root --password=51..dmz --host=192.168.75.68 --incremental /backup/ --incremental-basedir=/backup/2019-10-12_14-33-14/

...

...

191012 15:09:26 Finished backing up non-InnoDB tables and files

191012 15:09:26 [00] Writing xtrabackup_binlog_info

191012 15:09:26 [00]        ...done

191012 15:09:26 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...

xtrabackup: The latest check point (for incremental): '121610660'

xtrabackup: Stopping log copying thread.

.191012 15:09:26 >> log scanned up to (121610660)

 

191012 15:09:27 Executing UNLOCK TABLES

191012 15:09:27 All tables unlocked

191012 15:09:27 Backup created in directory '/backup/2019-10-12_15-09-15/'

MySQL binlog position: filename 'mysql-bin.000001', position '978'

191012 15:09:27 [00] Writing backup-my.cnf

191012 15:09:27 [00]        ...done

191012 15:09:27 [00] Writing xtrabackup_info

191012 15:09:27 [00]        ...done

xtrabackup: Transaction log of lsn (121610660) to (121610660) was copied.

191012 15:09:27 completed OK!

 

这次我们看到，--incremental-basedir指定的是第一次增量备份的目录，而不是全量备份的路径，因为这里我们测试的是增量备份，不是差量备份，如果测试差量备份的话，每次指定的‘--incremental-basedir’都要是那个全量备份，明白了吧！

[root@VM-75-68 backup]# ll

total 12

drwxr-x---. 9 root root 4096 Oct 12 10:44 2019-10-12_10-44-22

drwxr-x---. 9 root root 4096 Oct 12 14:33 2019-10-12_14-33-14

drwxr-x---. 9 root root 4096 Oct 12 15:09 2019-10-12_15-09-15

[root@VM-75-68 backup]# cd 2019-10-12_15-09-15

[root@VM-75-68 2019-10-12_15-09-15]# ll

total 420

-rw-r-----. 1 root root    419 Oct 12 15:09 backup-my.cnf

-rw-r-----. 1 root root 360448 Oct 12 15:09 ibdata1.delta

-rw-r-----. 1 root root     44 Oct 12 15:09 ibdata1.meta

drwxr-x---. 2 root root   4096 Oct 12 15:09 mysql

drwxr-x---. 2 root root   4096 Oct 12 15:09 ossec

drwxr-x---. 2 root root   4096 Oct 12 15:09 performance_schema

drwxr-x---. 2 root root   4096 Oct 12 15:09 relay

drwxr-x---. 2 root root   4096 Oct 12 15:09 RW

drwxr-x---. 2 root root   4096 Oct 12 15:09 test

-rw-r-----. 1 root root     21 Oct 12 15:09 xtrabackup_binlog_info

-rw-r-----. 1 root root    123 Oct 12 15:09 xtrabackup_checkpoints

-rw-r-----. 1 root root    588 Oct 12 15:09 xtrabackup_info

-rw-r-----. 1 root root   2560 Oct 12 15:09 xtrabackup_logfile

drwxr-x---. 2 root root  20480 Oct 12 15:09 zabbix

[root@VM-75-68 2019-10-12_15-09-15]# cat xtrabackup_checkpoints

backup_type = incremental

from_lsn = 121604745

to_lsn = 121610660

last_lsn = 121610660

compact = 0

recover_binlog_info = 0

同样可以看到，本次增量备份的起始LSN点位是上一次增量备份的结束LSN点位，OK，以上过程表示两次的增量备份是没有问题的！

 

数据还原：

好的， 备份好了我们开始还原数据，依旧是在另一台搭建了相同版本的mysql中去恢复，我们就在本机...

在之前的数据恢复中，只需要对全量备份进行准备操作即可，但是这里我们除了全量备份，还有增量备份，所以准备工作要进行多次，首先对全量进行准备工作：

[root@VM-75-68 backup]# innobackupex --apply-log --redo-only --use-memory=1G /backup/2019-10-12_10-44-22

191012 15:29:49 innobackupex: Starting the apply-log operation

 

IMPORTANT: Please check that the apply-log run completes successfully.

           At the end of a successful apply-log run innobackupex

           prints "completed OK!".

 

innobackupex version 2.4.6 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 8ec05b7)

xtrabackup: cd to /backup/2019-10-12_10-44-22/

xtrabackup: This target seems to be not prepared yet.

InnoDB: Number of pools: 1

xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(121600825)

xtrabackup: using the following InnoDB configuration for recovery:

xtrabackup:   innodb_data_home_dir = .

xtrabackup:   innodb_data_file_path = ibdata1:12M:autoextend

...

...

xtrabackup: starting shutdown with innodb_fast_shutdown = 1

InnoDB: Starting shutdown...

InnoDB: Shutdown completed; log sequence number 121600834

InnoDB: Number of pools: 1

191012 15:29:51 completed OK!

 

这里看到是成功了，但是，跟之前使用的指令相比，多了‘--redo-only’选项，这是为什么？

该选项表示在进行准备工作时，只进行redo操作，因为在备份开始时，有些事务日止已经提交了，但是还没有完全应用到数据文件中，有的事务还没有提交，这些没有提交的事务需要进行回滚操作，在进行‘准备工作’时，如果添加‘--redo-only’选项时，表示只会重做已经提交但是没有应用到数据文件的事务，而不会回滚未提交的事务，为什么之前没有添加该选项？

因为前面只还原了一个全量备份，全量备份之后没有其他备份需要合并，但是此处不同，除了全量，后面还有两个增量，那么在全量中那些没有提交的事务，有可能在后面的事务中已经提交了，因此，在准备最后一个‘备份’之前的‘备份’时，都不能进行回滚操作，只有在最后一个备份中的准备工作中才需要进行回滚操作。

 

OK，全量的准备完了，现在要做的是将第一次的增量备份合并到之前准备好的全量备份中：

[root@VM-75-68 backup]# innobackupex --apply-log --redo-only --use-memory=1G /backup/2019-10-12_10-44-22 --incremental-dir=/backup/2019-10-12_14-33-14

 

上面的指令中依旧使用了‘--redo-only’选项；

/backup/2019-10-12_10-44-22：这是已经准备好的全量的地址

--incremental-dir：该项对应的目录是增量备份的文件目录

上面的指令表示对增量备份做‘准备’工作，并且把准备好的增量备份合并到对应的全量备份中。

 

执行完上面的指令即表示第一份增量备份已经整理完毕，并且合并到了全量备份中，此时查看全量的xtrabackup_checkpoints：

[root@VM-75-68 2019-10-12_10-44-22]# cat xtrabackup_checkpoints

backup_type = log-applied

from_lsn = 0

to_lsn = 121604745

last_lsn = 121604745

compact = 0

recover_binlog_info = 0

此时备份类型变成了‘log-applied’，同时，to_lsn也从第一次全量备份的点，延伸至第一次增量备份结束时的点，这表明全量已经和第一次增量完美合并在一起了！

 

OK，现在继续合并最后一个增量：

innobackupex --apply-log --use-memory=1G /backup/2019-10-12_10-44-22 --incremental-dir=/backup/2019-10-12_15-09-15

...

...

InnoDB: 5.7.13 started; log sequence number 121612309

xtrabackup: starting shutdown with innodb_fast_shutdown = 1

InnoDB: FTS optimize thread exiting.

InnoDB: Starting shutdown...

InnoDB: Shutdown completed; log sequence number 121613653

191012 15:47:53 completed OK!

 

OK，这里我们把‘--redo-only’选项去掉了！

因为最后一次中，需要把没有提交的事务都回滚掉！

 

OK，准备工作完成了，合并也完成了，下面开始恢复数据：

[root@VM-75-68 backup]# mysql.server stop

[root@VM-75-68 backup]# rm -rf /var/lib/mysql/*

[root@VM-75-68 backup]# innobackupex --datadir=/var/lib/mysql/ --copy-back /backup/2019-10-12_10-44-22

...

...

191012 15:50:58 [01]        ...done

191012 15:50:58 [01] Copying ./zabbix/groups.ibd to /var/lib/mysql/zabbix/groups.ibd

191012 15:50:58 [01]        ...done

191012 15:50:58 [01] Copying ./zabbix/hostmacro.ibd to /var/lib/mysql/zabbix/hostmacro.ibd

191012 15:50:58 [01]        ...done

191012 15:50:58 [01] Copying ./zabbix/services_links.ibd to /var/lib/mysql/zabbix/services_links.ibd

191012 15:50:58 [01]        ...done

191012 15:50:58 [01] Copying ./ibtmp1 to /var/lib/mysql/ibtmp1

191012 15:50:58 [01]        ...done

191012 15:50:58 completed OK!

 

还有一步不能忘：

[root@VM-75-68 backup]# chown -R mysql:mysql /var/lib/mysql/

 

开启服务：

[root@VM-75-68 backup]# mysql.server start

Starting MySQL....                                         [  OK  ]

 

[root@VM-75-68 backup]# mysql -uroot -p51..dmz

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 1

Server version: 5.6.41-log MySQL Community Server (GPL)

 

Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

 

Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names may be trademarks of their respective

owners.

 

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

 

mysql> use RW;

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A

 

Database changed

mysql> show tables;

+--------------+

| Tables_in_RW |

+--------------+

| T            |

| account00    |

| account01    |

+--------------+

3 rows in set (0.00 sec)

 

mysql> select * from account01;

+-------------+--------------+-----------+--------------+

| AccountHash | AccountID    | ZoneID    | RoleID       |

+-------------+--------------+-----------+--------------+

|          23 | 45           |        67 |           89 |

|    21323211 | 787492757374 | 314342426 | 989997979798 |

|    21323212 | 787492757372 | 314342422 | 989997979799 |

|    21323213 | 787492757375 | 314342425 | 989997979791 |

|    21323214 | 787492757376 | 314342427 | 989997979795 |

+-------------+--------------+-----------+--------------+

5 rows in set (0.00 sec)

 

我们看到，所有的数据都是最后修改过的样子，也就是说，我们的恢复成功了！

 

 

总结：

这里的截图来自朱双印的技术博客：

 

 以上就是xtrabackup的增量和差量备份以及数据恢复的流程，共勉！