细说MySQL备份的基本原理（系列一 ） 备份与锁

数据库作为一个系统中唯一或者主要的持久化组件，对服务的可用性和数据的可靠性要求极高。 作为能够有效应对因为系统软硬件故障、人工误操作导致数据丢失的预防手段，备份是目前最为常见的数据库运维操作。 考虑到备份操作对数据库可用性的影响， MySQL官方将备份方式划主要划分为以下三类：

• 热备：备份过程中，MySQL实例始终是运行的，所有用户的读写请求都不会受到影响。

• 冷备：备份前首先需要停止MySQL实例的运行，整个备份过程中，用户均无法访问数据库。

• 温备：备份过程中，虽然MySQL实例是运行的，但是为了保证数据的一致性，允许用户通过加锁的方式来防止可能的更新或者修改操作。备份过程中，数据是只读的，所有的写请求会被阻塞。

针对MySQL数据库，目前主流的备份软件主要有mysqldump和XtraBackup两种。

 

mysqldump

 

mysqldump是MySQL自带的备份工具，通过create table、drop table和insert into 等SQL语句，将数据库中的数据导出成.sql文件。由于该文件是可读的，所以称之为逻辑备份。为了保证备份数据的一致性，mysqldump为用户提供了以下参数：

• --add-locks 为了保证一张表的数据一致性，对该表执行lock table xxx read，无论是innodb表还是myisam表，插入、删除、更新、带X锁的读（select for update）和DDL（alter）请求均会被阻塞，不影响快照读和S锁读（select lock in share mode）请求。该参数不保证表之间的数据一致性，如果涉及到跨表的查询，备份不能保证表之间数据是一致的。

• --lock-tables  锁定某一个数据库的所有的表，能够保证某一个库中的所有表的数据一致性，但是不保证库之间的数据一致,相当于在一个数据库的所有表上执行了--add-locks参数，此外该库的DDL语句均会给阻塞。

• --lock-all-tables 锁定某个实例的所有表，可以保证所有库的数据一致性,相当于所有的库同时指定lock tables参数，此外，实例的所有DDL语句（create database）均会阻塞。除非指定--single-transaction选项，如果指定，则mysqldump仅在备份开始时，加一个flush tables with read lock的全局锁，防止所有的DDL和写操作，在开启事务后，释放该锁，备份过程中，如果是innodb表则不受影响。

• --single-transaction 针对支持MVCC（多版本）事务的存储引擎，例如innodb，mysqldump提供了在导出数据之前，开启一个事务，由数据库保证单次导出数据的一致性，此时针对Innodb表的所有读写操作，均不会被阻塞。

• --master-data 获取备份数据的Binlog位置和Binlog文件名，用于通过备份恢复的实例之间建立复制关系时使用，该参数会默认开启。

从对mysqldump参数的分析我们可以看出，之所以备份过程中要上锁，主要基于以下几个原因：

• 备份的数据库中包含不支持事务的表，需要通过锁来保证单个表、一个库中的表之间、同一个实例的不同库的表之间的数据一致性。该锁可以表锁、库级别的锁甚至实例级别的锁，应根据实际业务对一致性的需求选择不同粒度的锁，最大程度的减少锁对用户读写请求的影响。

• 为了保证备份时，表结构的一致性，需要通过锁来阻止对表、库和实例的DDL操作。

• 为了保证获取正确的Binlog位置和文件名，需要短暂的锁定整个实例的所有库，因为Binlog是实例级别的，一个实例的所有库是共享Binlog文件和位置的。同时值得注意的是，无论是innodb表还是myisam表，此都为必须步骤，只是innodb表可以在开启事务后即释放该锁，而myisam需要在整个备份过程中，一直持有该锁，对用户访问的影响时间长短区别。

mysqldump由于依赖数据库层的转换，所以并不关心底层的存储引擎，既适用于支持事务的，也适用于不支持事务的，并且可以同时在不同MySQL版本之间进行转换，由于是逻辑备份，用户可以在备份的过程中，同时对数据进行修改。但是也正是因为需要经过数据库层的转换，mysqldump生成的备份文件往往很大，而且速度较慢，备份过程对数据库的访问有较大的影响，对于数据量大、业务压力高的实例并不适用。

XtraBackup

XtraBackup是Percona公司一款开源的数据库备份软件，相对于mysqldump，它是直接通过拷贝物理文件实现数据库备份的，所以速度相比要快很多。XtraBackup包含两部分：xtrabackup的c程序和innobackupex perl脚本；前者主要用于处理innodb表的备份；后者是前者的封装，主要包括一些与MySQL服务器的通信和mysiam表的备份。

首先我们先来简单的了解一下xtrabackup备份的基本原理。xtrabackup能够实现针对innodb表的无锁备份，即所有的读写请求、DDL语句在整个备份过程中都是不受影响的。它的实现是基于innodb对事务的支持，利用其崩溃恢复的功能来实现的。MySQL所有的更新操作都是在内存中完成的，然后异步的刷入磁盘进行持久化。支持事务的存储引擎，为了保证MySQL宕机后内存中还未刷出的更新不会丢失，设计了事务引擎日志(redo log)。通过将该部分的更新记录到日志中，然后记录日志序号(LSN)，异步线程在将脏页刷新到磁盘的同时，维护一个检查点LSN，两个LSN之间的差异就是数据宕机后丢失的更新。在数据库启动时，只要事务日志保存完好，就可以根据redo log和undo log将数据库恢复到崩溃前的一致性状态。

     

上图通过在MySQL执行show engine innodb status，我们可以清楚的看到：

• Log sequence number：表明当前redo log的最新LSN。

• Log flushed up to：表明当前已经刷新到磁盘上redo log的LSN。

• Last checkpoint at ：redo log记录的更新已经刷新到磁盘上的检查点LSN，该LSN之前的redo log上记录的更新已全部刷新到磁盘上，可以被覆盖重复使用。

 

xtrabackup备份时，首先会记录一个当前redo log最新的LSN，该点是备份数据一致最后一个矫正点，在利用该备份进行恢复时，即从该LSN作为起点，之后的所有redo log记录的更新都需要重做或者回滚。记录了LSN之后，xtrabackup就找到了一个数据一致点，然后直接拷贝数据文件。

Innodb存储引擎的表文件主要包括以下几类：

• ibdata1:默认表空间文件，如果没有设置innodb_file_per_table，则所有的表都是共用同一个文件的。如果启动了innodb_file_per_table，每张表的索引、数据和插入缓冲BITMAP信息是按照表分别独立存放在不同的文件中，但是undo log等其他信息还是存放在默认表空间中。

• table_name.bid：表文件，存放每张表的数据、索引和插入缓冲。

• ib_logfile0: 重做日志文件，备份前记录的LSN和备份结束时的LSN之间的redo log xtrabackup是需要保存的，用于在恢复时进行回放或者回滚。

MySQL的redo log是重用的，即检查点之间的redo log存在被覆盖的风险，而备份前和备份结束后之间的redo log是需要完整保存的，不允许被覆盖，如果备份时间比较长，redo log比较小的情况下，存在备份还没结束，原先记录的LSN之后的redo log即被覆盖，导致更新丢失的问题。为了解决该问题，xtrabackup额外启动了一个线程，不断的扫描redo log日志，一旦发现LSN有推进，则立即将该部分redo log拷贝出来，避免被覆盖。之后xtrabackup就开始拷贝包括默认表空间文件在内的所有表文件，直到拷贝结束，然后记录LSN，这样就完成了innodb表的备份。

从前面我们对数据库备份过程上锁的必要性的分析可知，除了解决数据文件的一致性外，还需要解决DDL和获取Binlog的问题。而该问题就需要依赖innobackupex来完成，首先在xtrabackup拷贝完数据文件后，innobackupex在MySQL上执行flush table with read lock，该操作会锁定整个实例的所有带X锁的读，更新、插入、删除和DDL语句，相当于冻结了LSN。此时MySQL 当前LSN不会再推进，然后记录LSN，此为最终一致的LSN；然后记录当前Binlog的文件名和位置；接着开始拷贝MySQL的表定义文件(.frm)，myisam表文件；最后unlock tables释放锁，这样就完成了一次完整的备份过程。