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