MySQL备份原理详解

     备份是数据安全的最后一道防线，对于任何数据丢失的场景，备份虽然不必定能恢复百分之百的数据(取决于备份周期)，但至少能将损失降到最低。衡量备份恢复有两个重要的指标：恢复点目标(RPO)和恢复时间目标(RTO)，前者重点关注能恢复到什么程度，然后者则重点关注恢复须要多长时间。这篇文章主要讨论MySQL的备份方案，重点介绍几种备份方式的原理，包括文件系统快照(LVM)，逻辑备份工具Mysqldump，Mydumper，以及物理备份工具Xtrabackup，同时会详细讲解几种方案的优缺点，以及可能遇到的问题。

冷备份
     最简单的备份方式就是，关闭MySQL服务器，而后将data目录下面的全部文件进行拷贝保存，须要恢复时，则将目录拷贝到须要恢复的机器便可。这种方式确实方便，可是在生产环境中基本没什么做用。由于全部的机器都是要提供服务的，即便是Slave有时候也须要提供只读服务，因此关闭MySQL停服备份是不现实的。与冷备份相对应的一个概念是热备份，所谓热备份是在不影响MySQL对外服务的状况下，进行备份，热备份是这篇文章讨论的重点。

快照备份
     首先要介绍的热备份是快照备份，快照备份是指经过文件系统支持的快照功能对数据库进行备份。备份的原理是将全部的数据库文件放在同一分区中，而后对该分区执行快照工做，对于Linux而言，须要经过LVM(Logical Volumn Manager)来实现。LVM使用写时复制(copy-on-write)技术来建立快照，例如，对整个卷的某个瞬间的逻辑副本，相似于数据库中的innodb存储引擎的MVCC，只不过LVM的快照在文件系统层面，而MVCC在数据库层面，并且仅支持innodb存储引擎。LVM有一个快照预留区域，若是原始卷数据有变化时，LVM保证在任何变动写入以前，会复制受影响块到快照预留区域。简单来讲，快照区域内保留了快照点开始时的一致的全部old数据。对于更新不多的数据库，快照也会很是小。对于MySQL而言，为了使用快照备份，须要将数据文件，日志文件都放在一个逻辑卷中，而后对该卷快照备份便可。因为快照备份，只能本地，所以，若是本地的磁盘损坏，则快照也就损坏了。快照备份更偏向于对误操做防范，能够将数据库迅速恢复到快照产生的时间点，而后结合二进制日志能够恢复到指定的时间点。基本原理以下图：

 

逻辑备份
      冷备份和快照备份因为其弊端在生产环境中不多使用，使用更可能是MySQL自带的逻辑备份和物理备份工具，这节主要讲逻辑备份，MySQL官方提供了Mysqldump逻辑备份工具，虽然已经足够好，但存在单线程备份慢的问题。在社区提供了更优秀的逻辑备份工具mydumper，它的优点主要体如今多线程备份，备份速度更快。

Mysqldump
Mysqldump用于备份，不得不提两个关键的参数：
--single-transaction：在开始备份前，执行start transaction命令，以此来获取一致性备份，该参数仅对innodb存储引擎有效。
--master-data=2：主要用于记录一致性备份的位点。
理解Mysqldump工做原理，必定要将事务表(innodb)和非事务表(好比myisam)区别对待，由于备份的流程与此息息相关。并且，到目前为止，咱们也没法规避myisam表，即便咱们的全部业务表都是innodb，由于mysql库中系统表仍然采用的myisam表。备份的基本流程以下：
1.调用FTWRL(flush tables with read lock)，全局禁止读写
2.开启快照读，获取此时的快照(仅对innodb表起做用)
3.备份非innodb表数据(*.frm,*.myi,*.myd等)
4.非innodb表备份完毕后，释放FTWRL锁
5.逐一备份innodb表数据
6.备份完成。
整个过程，能够参考我同事的一张图，但他的这张图只考虑innodb表的备份状况，实际上在unlock tables执行完毕以前，非innodb表已经备份完毕，后面的t1,t2和t3实质都是innodb表，并且5.6的mysqldump利用保存点机制，每备份完一个表就将一个表上的MDL锁释放，避免对一张表锁更长的时间。这里能够参考我以前的blog：FLUSH TABLE WITH READ LOCK

说明：
你们可能有一个疑问，为啥备份innodb表以前，就已经将锁释放掉了，这其实是利用了innodb引擎的MVCC机制，开启快照读后(

set transaction isolation level repeatable read)，就能获取那个时间的一致的数据，不管须要备份多长时间，直到整个事务结束(commit)为止。固然，这个RR级别的快照，对表的元数据也有要求，由于逻辑备份表是一个个进行的，若是在备份某个表以前，这个表作了DDL操做(此时备份事务暂时尚未加MDL锁)，后续再备份这个表时，就会由于表定义不一致而报错(Table definition has changed, please retry transaction)。因此总地来讲，经过保存点机制，能够有效减小DDL操做的限制，可是也不能彻底消除因为DDL操做致使的备份失败问题。

 

Mydumper
     Mydumper原理与Mysqldump原理相似，最大的区别是引入了多线程备份，每一个备份线程备份一部分表，固然并发粒度能够到行级，达到多线程备份的目的。这里要解决最大一个问题是，如何保证备份的一致性，其实关键仍是在于FTWRL。对于非innodb表，在释放锁以前，须要将表备份完成。对于innodb表，须要确保多个线程都能拿到一致性位点，这个动做一样要在持有全局锁期间完成，由于此时数据库没有读写，能够保证位点一致。因此基本流程以下：

物理备份(Xtrabackup)
      相对于逻辑备份利用查询提取数据中的全部记录，物理备份更直接，拷贝数据库文件和日志来完成备份，所以速度会更快。固然，不管是开源的Mydumper仍是官方最新的备份工具(5.7.11的mysqlpump)都支持了多线程备份，因此速度差别可能会进一步缩小，至少从目前生产环境来看，物理备份使用仍是比较多的。因为Xtrabackup支持备份innodb表，实际生产环境中咱们使用的工具是innobackupex，它是对xtrabackup的一层封装。innobackupex 脚本用来备份非 InnoDB 表，同时会调用 xtrabackup 命令来备份 InnoDB 表，innobackupex的基本流程以下：
1.开启redo日志拷贝线程，从最新的检查点开始顺序拷贝redo日志；
2.开启idb文件拷贝线程，拷贝innodb表的数据
3.idb文件拷贝结束，通知调用FTWRL，获取一致性位点
4.备份非innodb表(系统表)和frm文件
5.因为此时没有新事务提交，等待redo日志拷贝完成
6.最新的redo日志拷贝完成后，至关于此时的innodb表和非innodb表数据都是最新的
7.获取binlog位点，此时数据库的状态是一致的。
8.释放锁，备份结束。

说明：咱们知道MySQL里面有个double-write为了防止写的时候页断裂，那么备份读的时候，有没有可能也只一半的page呢？这个实际上是有可能的，所以，咱们在拷贝page的时候，须要对page算checksum，若是checksum不符合预期，咱们认为拷贝的页面不完整(这种状况可能发生在你在读页面，然后台线程正在刷脏)，须要重试。因此，最终也能保证数据的一致性。

 

Xtrabackup的改进
     从前面介绍的逻辑备份和物理备份来看，不管是哪一种备份工具，为了获取一致性位点，都强依赖于FTWRL。这个锁杀伤力很是大，由于持有锁的这段时间，整个数据库实质上不能对外提供写服务的。此外，因为FTWRL须要关闭表，若有大查询，会致使FTWRL等待，进而致使DML堵塞的时间变长。即便是备库，也有SQL线程在复制来源于主库的更新，上全局锁时，会致使主备库延迟。从前面的分析来看，FTWRL这把锁持有的时间主要与非innodb表的数据量有关，若是非innodb表数据量很大，备份很慢，那么持有锁的时间就会很长。即便所有是innodb表，也会由于有mysql库系统表存在，致使会锁必定的时间。为了解决这个问题，Percona公司对Mysql的Server层作了改进，引入了BACKUP LOCK，具体而言，经过"LOCK TABLES FOR BACKUP"命令来备份非innodb表数据；经过"LOCK BINLOG FOR BACKUP"来获取一致性位点，尽可能减小由于数据库备份带来的服务受损。咱们看看采用这两个锁与FTWRL的区别：

LOCK TABLES FOR BACKUP
做用：备份数据
1.禁止非innodb表更新
2.禁止全部表的ddl
优化点：
1.不会被大查询堵塞(关闭表)
2.不会堵塞innodb表的读取和更新，这点很是重要，对于业务表所有是innodb的状况，则备份过程当中DML彻底不受损
UNLOCK TABLES

LOCK BINLOG FOR BACKUP
做用：获取一致性位点。
1.禁止对位点更新的操做
优化点：
1.容许DDl和更新，直到写binlog为止。
UNLOCK BINLOG

参考文档
http://mysql.taobao.org/monthly/2016/03/07/
https://www.percona.com/blog/2014/03/11/introducing-backup-locks-percona-server-2/
http://www.wtoutiao.com/p/1cbstSx.html
http://www.wtoutiao.com/p/10cEnZ7.html
http://www.wtoutiao.com/p/125vVWi.html
http://www.wtoutiao.com/p/120AXSH.html
http://www.cnblogs.com/cchust/p/4603599.html