7.3.1 Establishing a Backup Policy

7.3 Example Backup and Recovery Strategy 备份和恢复策略实例

7.3.1 Establishing a Backup Policy
7.3.2 Using Backups for Recovery
7.3.3 Backup Strategy Summary

这个章节讨论执行备份的过程让你可以在几种类型的crash后恢复数据

1.操作系统crash

2. 电源故障

3. 文件系统crash

4. 硬件问题(硬盘,主板等等)


示例命令不包含选项比如 --user 和--password 对于mysqldump 和mysql client程序。


你必须包含这些选项来让客户端程序连接到MySQL server


假设数据存储在 InnoDB storage engine, 已经支持事务和自动crash recovery.


假设MySQL server 是在负载时crash,如果不是,不需要任何恢复


操作系统crashed或者电源故障的情况下, 我们可以假设MySQL的磁盘数据是在重启后可用的。

InnoDB 数据文件可能不包含一致性的数据由于crash,但是InnoDB 读取它的logs 找到挂起的和未提交的事务的列表

没有没刷新到数据文件。

InnoDB 自动回滚那些没有提交的事务, 刷新到它的数据文件对于那些提交的。

7.3.1 Establishing a Backup Policy  建立备份策略:



为了有用,备份必须定期执行。一个群备份( 在一个时间点的数据库快照) 可以使用Mysql几个工具实现。


比如,MySQL Enterprise Backup 可以执行一个实例的物理备份, 这个章节讨论使用mysqldump

假设 我们做一个所有数据库的InnoDB表的全备份,使用下面的命令:

shell> mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql


通过mysqldump 产生的.sql文件包含了 一组INSERT 语句可以用于重新加载dumped表在以后的时间


这个备份操作需要一个 global read lock 在所有的表在dump开始时(使用FLUSH TABLES WITH READ LOCK). 

一旦这个锁被获取, binary log coordinates 被读取,lock被释放。


当场时间更新语句在执行当FLUSH 语句被执行, backup 操作可能停顿知道那些语句完成。

在那以后,dump 变的lock-free 不会打扰读和写在表上


假设备份的表是InnoDB表, 因此--single-transaction  使用一个一致性读和数据被mysqldump看到不改变

(被其他客户端对InnoDB表的改变不会被mysqldump进程看到）


如果 备份操作包含非事务表, 一致性需要它们不改变在备份期间。




全备份是必须的,但是 它总是不大方便创建它们。 它们产生大的备份文件 花费时间来生成。

它们不是罪有的在这个意义上每个成功的全备份包含所有的数据, 即使那部分没有改变自从上次全备份。

做一个初始的全备份是更加有效的,然后做增量备份。

增量备份是小的花费更少的时间来产生。

权衡是,在恢复时间, 你不能恢复你的数据只是通过加载全备份,你必须产生增量备份来恢复你的增量改变。


做增量备份, 我们需要保存增量改变。在Mysql，那些改变被记录到binary log，


MySQL server 应该总是启用 --log-bin 选项。


启动binary logging, server 写每个数据改变到一个文件 当它更新数据时。


查看MySQL server的数据目录 启用log-bin选项



每次他重启时, MySQL server 创建一个新的binary log 文件按顺序使用下一个数字。

当server 运行时, 你也可以告诉它来关闭当前的binary log 文件 开始一个新的通过执行一个FLUSH LOGS SQL statement

或者使用一个mysqladmin   flush-logs命令。


mysqldump 也有一个选项来刷新日志。.index 文件在数据目录包含 所有的mysql binlog 



MySQL binary logs 是重要的对于恢复 因为 它们构成增量备份的备份集。


如果你确保flush logs 当你做全备份时,binary log 文件被创建以后包含所有数据改变自动备份后。


让我们修改之前的mysqldump 命令 让它flushed MySQL binary logs 在全备份的时刻,


这样dump 文件包含了新的binary log 的名字

shell> mysqldump --single-transaction --flush-logs --master-data=2 
         --all-databases > backup_sunday_1_PM.sql


在执行这个命令后,数据目录包含一个新的binary log 文件,gbichot2-bin.000007, 

因为--flush-logs选项会让server flush 它的日志。


--master-data 选项让mysqldump 写binay log 信息到它输出,因此.sqldump文件包含下面行:
-- Position to start replication or point-in-time recovery from

-- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.000007',MASTER_LOG_POS=4;


因为mysqldump 命令做一个全备份,那些行意味着两个事情:

1.dump 文件包含所有的改变在任何改变谢雨到gbichot2-bin.000007  binary log 文件或者更高

2.所有的数据改变被记录在备份是不存在在dump文件里,但是是存在 gbichot2-bin.000007 binary log file或者更高的


在星期一在下午1点,  我们创建一个增量备份通过flushing logs 来开始一个新的binary log 文件。


例如,执行一个mysqladmin flush-logs command  创建一个gbichot2-bin.000008.


所有的改变在星期天下午1点的全备份和星期一下午1点会在gbichot2-bin.000007 file. 


这个增量备份是重要的, 需要拷贝到安全的地方