mysqldump备份时保持数据一致性

共计 2034 个字符，预计需要花费 6 分钟才能阅读完成。

对 MySQL 数据进行备份，常见的方式如以下三种，可能有很多人对备份时数据一致性并不清楚

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

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

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

以上几种方法相信大家也都很熟悉，就不再详细介绍。下面主要讲解一下 MySQLdump 备份时如何保持数据的一致性。

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

1、对于支持事务的引擎如 InnoDB，参数上是在备份的时候加上 –single-transaction 保证数据一致性

–single-transaction 实际上通过做了下面两个操作：

①、在开始的时候把该 session 的事务隔离级别设置成 repeatable read；

②、然后启动一个事务（执行 bigin），备份结束的时候结束该事务（执行 commit）

有了这两个操作，在备份过程中，该 session 读到的数据都是启动备份时的数据（同一个点）。可以理解为对于 innodb 引擎来说加了该参数，备份开始时就已经把要备份的数据定下来了，备份过程中的提交的事务时是看不到的，也不会备份进去。

2、对于不支持事务的引擎如 MyISAM，只能通过锁表来保证数据一致性，这里分三种情况：

①、导出全库：加 –lock-all-tables 参数，这会在备份开始的时候启动一个全局读锁（执行 flush tables with read lock），其他 session 可以读取但不能更新数据，备份过程中数据没有变化，所以最终得到的数据肯定是完全一致的；

②、导出单个库：加 –lock-tables 参数，这会在备份开始的时候锁该库的所有表，其他 session 可以读但不能更新该库的所有表，该库的数据一致；

③、导出单个表：加 –lock-tables 参数，这会在备份开始的时候锁该表，其他表不受影响，该表数据一致。

上面只是展示了对不同引擎来讲加的参数只是为了让数据保持一致性，但在备份中业务并没有停止，时刻可能有新的数据进行写入，为了让我们知道备份时是备份了哪些数据，或者截止到那个指针（二进制日志），我们可以再加入 –master-data 参数，备份好的 sql 文件就会记录从备份截至到哪个指针，指针之后的数据更新我们可以通过二进制日志进行恢复。

# MySQLdump -u root -p –single-transaction –master-data –flush-log –database test > test.sql                            –> –flush-log 表示备份开始之后的更行都切到下一个二进制日志

可以在备份的 test.sql 文件中前几行看到记录着备份当时的二进制日志信息
# vim test.sql
–CHANGE MASTER TO MASTER_LOG_FILE=’mysql-bin.000004′, MASTER_LOG_POS=436263492;
—- Current Database: `test`
…..
# mysqlbinlog –start-position=436263492 mysql-bin.000004 > 00004.sql                    –> 在全备恢复之后，我们可以通过之后的二进制日志进行恢复

另外解释下 mysqldump 备份时为什么要锁表才能保持数据的一致性:

说明：
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，有很大肯会出现数据不一致（备份过程中所有表均无数据更新除外）。

本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-06/144782.htm