mysqldump如何保证数据一致性

作为DBA的小K，搭建备机应该是家常便饭了，这时候用到的方法无非有如下三种：

1、停掉一台备机（这里叫备机1），直接拷贝整个数据目录下的所有文件到新的备机（这里叫备机2）。优点是简单、快速，只需要拷贝；缺点也很明显，在整个备份过程中备机1处于完全不可用的状态，且备机2无法释放备机1中因为碎片导致的空间浪费和无法回收已发生扩展的innodb表空间。

2、用xtrabackup进行热备。优点是备份过程中可继续提供服务；缺点和第一种方法差不多，备机2无法释放备机1中因为碎片导致的空间浪费和无法回收已发生扩展的innodb表空间。

3、使用官方自带的mysqldump逻辑重做。优点是在整个备份过程中备机1可以向外提供服务，最重要的一点是可以解决碎片浪费。

这三种方法的步骤都比较简单，所以这里不做介绍。小K在这里主要是解释一下mysqldump是如何在备份过程中确保数据一致性这个问题

首先要介绍一下repeatable read这个事务隔离级别，这是理解下面内容的基础，主要有两点：

1、在repeatable read事务隔离级别下，在同一个事务内，每次读到的数据都是一样的，这个特性也叫可重复读；

2、事务隔离级别可以在session级别设置

mysqldump对不同类型的存储引擎，内部实现也不一样。主要是针对两种类型的存储引擎：支持事务的存储引擎（如InnoDB）和不支持事务的存储引擎（如MyISAM），下面分别看看这两种存储引擎的实现：

1、对于支持事务的引擎如InnoDB，参数上是在备份的时候加上--single-transaction保证数据一致性
--single-transaction实际上通过做了下面两个操作：
①、在开始的时候把该session的事务隔离级别设置成repeatable read；
②、然后启动一个事务（执行bigin），备份结束的时候结束该事务（执行commit）
有了这两个操作，在备份过程中，该session读到的数据都是启动备份时的数据（同一个点），所以导入完成后从该点（可通过添加--master-data=2获取）应用binlog得到的数据是和主机完全一致的。

2、对于不支持事务的引擎如MyISAM，只能通过锁表来保证数据一致性，这里分三种情况：
①、导出全库：加--lock-all-tables参数，这会在备份开始的时候启动一个全局读锁（执行flush tables with read lock），其他session可以读取但不能更新数据，备份过程中数据没有变化，所以最终得到的数据肯定是完全一致的；
②、导出单个库：加--lock-tables参数，这会在备份开始的时候所在该库的所有表，其他session可以读但不能更新该库的所有表，该库的数据一致；
③、导出单个表：加--lock-tables参数，这会在备份开始的时候所在该表，其他表不受影响，该表数据一致。


有一次一个同事这么跟我说：MyISAM表不锁表最终也不会不一致啊，只要从备份开始的点应用binlog，不就把所有数据库的所有变化都应用上了嘛。一开始我走入过这个坑，但是后来请教了组内大牛后，豁然开朗。有图有真相啊有木有，小K用下面这张图来介绍为什么在备份不支持事务的存储引擎如MyISAM表时，不锁表最终得到的数据是不一致的。

说明：

1、在t1时间点，用mysqldump启动不锁表备份；

2、先导出a表，共耗时5分钟，因为没有锁表，在这5分钟内b表insert了10行数据；

3、到了t2时间点，a表导出完成，开始导出b表；

4、导出b表耗时10分钟，在导出b表的过程中，a、b表均没有数据变化；

5、到了t3时间点，b表导出完成，全部备份结束；

6、然后备机从t1时间点的binlog位置开始应用binlog，最后备机中b表的数据比主机多10行，数据不一致。

从这个图可以看出，对于不支持事务的存储引擎如MyISAM如果备份过程中不锁表，不同表开始备份时对应的binlog和pos是不一致的，这时候所有表都从备份开始的点应用binlog，有很大肯会出现数据不一致（备份过程中所有表均无数据更新除外）。