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. 这个增量备份是重要的, 需要拷贝到安全的地方