通过Xtrabackup日志来恢复检查点文件

最近积压了很多朋友的问题，我想起来的时候就回复一下，别见怪，不是我有势利眼。

前几天有个朋友问我的问题，是在xtrabackup的时候，没有特别保留checkpoints文件，想问问能否通过日志来推理得到里面的LSN信息呢，背景条件是做全备。

一个参考的日志如下：

171208 11:21:54 [01] Copying ./sbtest/dba_xtrabackupresult.frm to /data/backup/sbtest/dba_xtrabackupresult.frm
171208 11:21:54 [01]        ...done
171208 11:21:54 Finished backing up non-InnoDB tables and files
171208 11:21:54 [00] Writing /data/backup/xtrabackup_binlog_info
171208 11:21:54 [00]        ...done
171208 11:21:54 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '3985406424'
xtrabackup: Stopping log copying thread.
....171208 11:21:55 >> log scanned up to (4060591382)
171208 11:21:55 >> log scanned up to (4060591382)

171208 11:21:55 Backup created in directory '/data/backup/'
MySQL binlog position: filename 'mysqlbin.000017', position '96607849'
171208 11:21:55 [00] Writing /data/backup/backup-my.cnf
171208 11:21:55 [00]        ...done
171208 11:21:55 [00] Writing /data/backup/xtrabackup_info
171208 11:21:55 [00]        ...done
xtrabackup: Transaction log of lsn (3597739074) to (4060591382) was copied.
171208 11:21:57 completed OK!

可以看到日志里面出现了很多的LSN的信息，首先是能够根据日志得到LSN的信息，然后是如果可以的话，这些LSN是如何做选择的。

我们必然要引入xtrabackup的原理和过程图

总体来说xtrabackup会通过物理拷贝的方式，然后来补充增量的数据变化。整个过程和Oracle的热备有些类似。日志中的信息相对来说还是很全的，作为参考是足够的。

然后如何恢复呢，我们需要知道有哪些LSN是需要的。

一般来说，一个checkpoints文件需要如下的LSN信息

[root@tk-dba-mysql10-202 backup]# cat *checkpoints
backup_type = full-backuped
from_lsn = xx
to_lsn = xx
last_lsn = xx
compact = 0
recover_binlog_info = 0

为了避免干扰，我做了一些过滤，可以看到基本是由FROM_LSN,TO_LSN,LAST_LSN组成的，如果是全备，from_lsn应该是0，如果数据库没有负载，或者在这个备份的过程中没有什么写入，那么to_lsn和last_lsn是一致的。

可是上面的日志很明显，是在数据库比较繁忙的情况下做的备份，所以产生了很多的临界点的 LSN,所以通过这些细节就需要我们知道整个xtrabackup的过程中LSN的变化

我就不兜圈子了，通过模拟，得到的一个初步结论如下：

[root@tk-dba-mysql10-202 backup]# cat *checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 3985406424
last_lsn = 4060591382
compact = 0
recover_binlog_info = 0

这个过程是怎么模拟的呢，是在前端通过sysbench做压力测试，然后使用xtrabackup来备份。整个过程还是比较快的，大概半个小时内能够验证完成。