备份与恢复

对于DBA来说，数据库的备份与恢复是一项最基本的操作与工作。在意外情况下（如

服务器宕机、磁盘损坏、RAID卡损坏等）要保证数据不丢失，或者是最小程度地丢失，每

个DBA应该每时每刻关心所负责的数据库备份情况。

本章主要介绍对InnoDB存储引擎的备份，应该知道MySQL数据库提供的大多数工具

（如mysqldump、ibbackup、replication）都能很好地完成备份的工作，当然也可以通过第

三方的一些工具来完成，如xtrabacup、LVM快照备份等。DBA应该根据自己的业务要求，

设计出损失最小、对于数据库影响最小的备份策略。

8.1 备份与恢复概述

可以根据不同的类型来划分备份的方法。根据备份的方法不同可以将备份分为：

Hot Backup（热备）

Cold Backup（冷备）

Warm Backup（温备）

Hot Backup是指数据库运行中直接备份，对正在运行的数据库操作没有任何的影响。

这种方式在MySQL官方手册中称为Online Backup（在线备份）。Cold Backup是指备份操作

是在数据库停止的情况下，这种备份最为简单，一般只需要复制相关的数据库物理文件即

可。这种方式在MySQL官方手册中称为Offline Backup（离线备份）。Warm Backup备份同

样是在数据库运行中进行的，但是会对当前数据库的操作有所影响，如加一个全局读锁以

保证备份数据的一致性。

按照备份后文件的内容，备份又可以分为：

逻辑备份

裸文件备份

在MySQL数据库中，逻辑备份是指备份出的文件内容是可读的，一般是文本文件。内

容一般是由一条条SQL语句，或者是表内实际数据组成。如mysqldump和SELECT*INTO

OUTFILE的方法。这类方法的好处是可以观察导出文件的内容，一般适用于数据库的升

级、迁移等工作。但其缺点是恢复所需要的时间往往较长。

裸文件备份是指复制数据库的物理文件，既可以是在数据库运行中的复制（如

ibbackup、xtrabackup这类工具），也可以是在数据库停止运行时直接的数据文件复制。这

类备份的恢复时间往往较逻辑备份短很多。

若按照备份数据库的内容来分，备份又可以分为：

完全备份

增量备份

日志备份

完全备份是指对数据库进行一个完整的备份。增量备份是指在上次完全备份的基础

上，对于更改的数据进行备份。日志备份主要是指对MySQL数据库二进制日志的备份，通

过对一个完全备份进行二进制日志的重做（replay）来完成数据库的point-in-time的恢复工

作。MySQL数据库复制（replication）的原理就是异步实时地将二进制日志重做传送并应用

到从（slave/standby）数据库。

对于MySQL数据库来说，官方没有提供真正的增量备份的方法，大部分是通过二进制

日志完成增量备份的工作。这种备份较之真正的增量备份来说，效率还是很低的。假设有

一个100GB的数据库，要通过二进制日志完成备份，可能同一个页需要执行多次的SQL语

句完成重做的工作。但是对于真正的增量备份来说，只需要记录当前每页最后的检查点的

LSN，如果大于之前全备时的LSN，则备份该页，否则不用备份，这大大加快了备份的速

度和恢复的时间，同时这也是xtrabackup工具增量备份的原理。

此外还需要理解数据库备份的一致性，这种备份要求在备份的时候数据在这一时间点

上是一致的。举例来说，在一个网络游戏中有一个玩家购买了道具，这个事务的过程是：

先扣除相应的金钱，然后向其装备表中插入道具，确保扣费和得到道具是互相一致的。否

则，在恢复时，可能出现金钱被扣除了而装备丢失的问题。

对于InnoDB存储引擎来说，因为其支持MVCC功能，因此实现一致的备份比较简单。

用户可以先开启一个事务，然后导出一组相关的表，最后提交。当然用户的事务隔离级别

必须设置为REPEATABLE READ，这样的做法就可以给出一个完美的一致性备份。然而这

个方法的前提是需要用户正确地设计应用程序。对于上述的购买道具的过程，不可以分为

两个事务来完成，如一个完成扣费，一个完成道具的购买。若备份这时发生在这两者之

间，则由于逻辑设计的问题，导致备份出的数据依然不是一致的。

对于mysqldump备份工具来说，可以通过添加--single-transaction选项获得InnoDB存储

引擎的一致性备份，原理和之前所说的相同。需要了解的是，这时的备份是在一个执行时

间很长的事务中完成的。另外，对于InnoDB存储引擎的备份，务必加上--single-transaction

的选项（虽然是mysqldump的一个可选选项，但是我找不出任何不加的理由）。

同时我建议每个公司要根据自己的备份策略编写一个备份的应用程序，这个程序可以

方便地设置备份的方法及监控备份的结果，并且通过第三方接口实时地通知DBA，这样才

能真正地做到24×7的备份监控。久游网开发过一套DAO（Database Admin Online）系统，

这套系统完全由DBA开发完成，整个平台用Python语言编写，Web操作界面采用Django。

通过这个系统DBA可以方便地对几百台MySQL数据库服务器进行备份，同时查看备份完成

后备份文件的状态。之后DBA又对其进行了扩展，不仅可以完成备份的工作，也可以实时

监控数据库的状态、系统的状态和硬件的状态，当发生问题时，通过飞信接口在第一时间

以短信的方式告知DBA。

最后，任何时候都需要做好远程异地备份，也就是容灾的防范。只是同一机房的两台

服务器的备份是远远不够的。我曾经遇到的情况是，公司在2008年的汶川地震中发生一个

机房可能被淹的的情况，这时远程异地备份显得就至关重要了。

8.2 冷备

对于InnoDB存储引擎的冷备非常简单，只需要备份MySQL数据库的frm文件，共享表

空间文件，独立表空间文件（*.ibd），重做日志文件。另外建议定期备份MySQL数据库的

配置文件my.cnf，这样有利于恢复的操作。

通常DBA会写一个脚本来进行冷备的操作，DBA可能还会对备份完的数据库进行打包

和压缩，这都并不是难事。关键在于不要遗漏原本需要备份的物理文件，如共享表空间和

重做日志文件，少了这些文件可能数据库都无法启动。另外一种经常发生的情况是由于磁

盘空间已满而导致的备份失败，DBA可能习惯性地认为运行脚本的备份是没有问题的，少

了检验的机制。

正如前面所说的，在同一台机器上对数据库进行冷备是远远不够的，至少还需要将本

地产生的备份存放到一台远程的服务器中，确保不会因为本地数据库的宕机而影响备份文

件的使用。

冷备的优点是：

备份简单，只要复制相关文件即可。

备份文件易于在不同操作系统，不同MySQL版本上进行恢复。

恢复相当简单，只需要把文件恢复到指定位置即可。

恢复速度快，不需要执行任何SQL语句，也不需要重建索引。

冷备的缺点是：

InnoDB存储引擎冷备的文件通常比逻辑文件大很多，因为表空间中存放着很多其他

的数据，如undo段，插入缓冲等信息。

冷备也不总是可以轻易地跨平台。操作系统、MySQL的版本、文件大小写敏感和浮

点数格式都会成为问题。