XtraBackup的安装和使用

XtraBackup是数据库物理备份工具，是阿里云RDS备份数据库的组件。它的优点是热备而且速度快，效率比mysqldump不知道高到哪里去了。它的备份原理如下:

innobackupex首先会启动一个xtrabackup_log后台检测的进程，实时检测mysql的redo log的变化，一旦发现redo有新的日志写入，立刻将日志写入到日志文件xtrabackup_log中。
物理拷贝innodb的数据文件和系统表空间文件idbdata1到对应的以默认时间戳为备份目录的地方
复制结束后，执行flush table with read lock操作进行全库锁表准备备份非InnoDB文件
复制.frm .myd .myi等非InnoDB引擎文件
查看binary log 的位置
解锁unlock tables
停止xtrabackup_log进程

安装与全量备份

先去https://www.percona.com/downloads/Percona-XtraBackup-2.4/LATEST/ 下载2.4版本的XtraBackup，虽然最新的版本是8.0.6，但是据说它只支持mysql8.0和percona8.0…

安装步骤如下：

[root@share ~]#	yum install -y cmake libaio-devel
[root@share ~]#	yum install glibc glibc-devel glibc-static perl-Digest-MD5 perl-DBD-MySQL -y
   [root@share ~]# wget ftp://rpmfind.net/linux/atrpms/el6-x86_64/atrpms/stable/libev-4.04-2.el6.x86_64.rpm
   [root@share ~]# rpm -ivh libev-4.04-2.el6.x86_64.rpm			#xtrabackup安装依赖libev.so.4()(64bit) 
[root@share ~]# rpm -ivh percona-xtrabackup-24-2.4.14-1.el6.x86_64.rpm 
warning: percona-xtrabackup-24-2.4.14-1.el6.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 8507efa5: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...
   1:percona-xtrabackup-24-2.4.14-1.el################################# [100%]
[root@share ~]#

安装完毕之后，就可以innobackupex --host=127.0.0.1 --user=root --password=数据库密码 --defaults-file=/etc/mysql/my.cnf /备份的文件夹名来备份数据库。同时备份结束之后会生成一个LSN号，在增量备份时候，就只备份大于此号的数据页。

如果有了备份文件想要全量恢复的话，就是如下操作：

scp -r /backup/备份文件夹/ 另一个mysqlIP:/backup/	#先将本机的备份文件夹拷贝到其他服务器里去
innobackupex --apply-log --use-memory=1G /backup/备份文件夹/	#在新的mysql里进行数据的准备工作，这一步用来合成可用的数据，--use-memory根据实际情况指定
systemctl stop mariadb
rm -rf /var/lib/mysql/*		#停止当前进程，并且删除数据目录和对应日志
innobackupex --datadir=/var/lib/mysql --copy-back /backup/备份文件夹/		#将准备好的数据还原到对应目录里
chown -R mysql: /var/lib/mysql/		#将文件夹属主和组都更改成mysql
systemctl start mariadb		#重启进程

增量备份与恢复

增量备份的前提是全量备份，假设我们已经进行了全量备份。增量备份过程如下：

innobackupex -p数据库密码 --incremental /全量备份文件夹 --incremental-basedir=/backup/增量备份文件夹1/	#与全量备份文件夹相比，进行增量备份
scp -r /backup/* 另一个mysqlIP:/backup/		#传递给另个mysql里
innobackupex --apply-log --redo-only --use-memory=1G /backup/全量备份文件夹/	#先对最早的全量备份进行恢复
innobackupex --apply-log --redo-only --use-memory=1G /backup/全量备份文件夹/ --incremental-dir=/backup/增量备份文件夹1		
#在之前全量备份的基础上合并一波增量备份
systemctl stop mariadb
rm -rf /var/lib/mysql/*		#停止当前进程，并且删除数据目录和对应日志
innobackupex --datadir=/var/lib/mysql --copy-back /backup/备份文件夹/		#将准备好的数据还原到对应目录里
chown -R mysql: /var/lib/mysql/		#将文件夹属主和组都更改成mysql
systemctl start mariadb		#重启进程

查看是否是增量备份还是全量备份，可以通过xtrabackup_checkpoints文件里的backup_type字段：full-prepared是全量备份、incremental是增量备份。

这里有一个坑，就是备份和恢复的时候使用的xtrabackup的版本要保持一致，如果不一致，就会有Failed to connect to MySQL server to detect version.的错误。如果出现了错误，就要根据mysql版本在原有命令后添加--ibbackup xtrabackup_版本号，比如我的mysql是5.6版本的，那么语句就是innobackupex --use-memory=1G --apply-log /data/back --ibbackup xtrabackup_56 。

Mysql如何恢复到任意时间点

众所周知，mysql的更新操作（UPDATE）是“先备份再覆盖”的一个过程，那备份在哪里呢?buffer。

但是这个瞬间就会出现buffer的数据页与磁盘的数据页内容不一致，这时的buffer的数据页叫dirty page。如果此时出现了mysql非正常宕机，就会出现“数据并没有同步到磁盘文件中，而且已经从内存里出来了”的现象，即数据丢失。

为了解决这个现象，就在buffer的dirty page变更结束之后，把相应修改记录记录到redo log里。如果在发现有数据丢失的现象，可以通过redo log回溯。更多内容可以看https://mp.weixin.qq.com/s?__biz=MjM5NjMyMjUzNg==&mid=2448131616&idx=1&sn=5af80b03adef5846b7dc51015d99f7e7&scene=0#wechat_redirect&rd2werd=1#wechat_redirect 这篇文章。

整理一下mysql里更新语句的内幕：

系统当取到一个UPDATE语句的时候，会先通过主键找到该行，判断此行是否在buffer里，如果在就直接返回给执行器，如果不在就先从磁盘拷贝一份到内存里，在内存里对数据进行修改，此时生成了dirty page，同时也将这个操作记录更新到redo log里，redo log处于prepare状态（mysql生成xid)，通知执行器可以提交覆盖磁盘（这是一个事务）。然后执行器先生成这个操作的bin log（mysql是日志先行的设计），然后再执行覆盖的操作（将xid写进bin log)，至此更新完成。

假设此时mysql出现了非正常宕机，那么先找一下有没有之前的xtrabackup等工具保留的备份，如果有当日的备份，再结合bin log可以恢复一个临时表。然后扫描最后一个bin log，提取出xid。重做检查点以后的redo log，搜集处于prepare阶段的事务链表，将事务的xid与bin log中的xid对比。若存在，说明事务记录到bin log成功，只是最终未commit成功，可以直接提交，否则就回滚。