高性能MySQL（第三版）第十五章：备份与恢复

15.1 为什么要备份

• 灾难恢复：硬件故障、一个不经意的Bug导致数据损坏，或者服务器及其数据由于某些原因不可获取或无法使用等。
• 人们改变想法：删除某些数据和又想要恢复这些数据
• 审计： 数据快照，过去某个时间点的数据状态
• 测试：取数据到测试环境做测试使用

15.2 定义恢复需求

不仅仅要有备份系统，还要有一个强大的恢复系统。

规划恢复策略时，有两个重要的需求可以帮助思考：恢复点目标（PRO)和恢复时间目标（RTO）。他们定义了可以容忍丢失多少数据，以及需要等待多久将数据恢复。

在定义RPO和RTO是，先尝试回答下面几类问题：

• 在不导致严重后果的情况下，可以容忍丢失多少数据？
• 需要故障恢复，还是可以接受自从上次日常备份后所有的工作全部丢失？
• 是否有法律法规的要求？
• 恢复需要在多长时间内完成？
• 哪种类型的宕机是可以接受的？
• 哪些影响（例如，部分服务不可用）是应用和用户可以接受的？
• 当那些场景发生时，又该如何持续服务？ 需要恢复什么？

常见的需求是恢复整个服务器，单个数据库，单个表，或仅仅是特定的事务或语句

复制 != 备份： 例如Drop table后需要恢复，复制就恢复不了，需要靠备份才能恢复，当然延迟复制有可能的。

15.3 设计MySQL备份方案

细节之前的建议：

• 在生产实践中，大数据库来说，物理备份是必须的：逻辑备份太慢并且受资源限制，逻辑备份中恢复需要很长时间。基于快照的备份，例如Perconna XtraBackup和MySQL Enterprise Backup是最好的选择。
• 保留多个备份集
• 定期从逻辑备份（或者物理备份）中抽取数据进行恢复测试
• 保存二进制日志以用于基于故障时间点的恢复。expire_logs_days应该设置的足够长.至少大于全量备份的间隔时间。
• 完不借助备份工具本身来监控备份和备份的过程。需要另外验证备份是否正常。
• 通过演练整个恢复过程来测试备份和恢复。测算恢复所需要的资源（CPU、磁盘空间、实际时间，以及网络带宽等）
• 对安全性要仔细考虑。

15.3.1 在线备份还是离线备份

规划备份是，有一些与性能相关的因素需要考虑：

• 锁时间：需要持有锁多长时间，例如备份期间持有的全局FLUSH TABLES WITH READ LOCK?
• 备份时间： 复制备份到目的地需要多久
• 备份负载：在复制备份到目的地时对服务器性能的影响有多少
• 恢复时间：把备份镜像从存储位置复制到MySQL服务器，重放二进制日志需要多久？

最大的权衡是备份时间与备份负载。提高备份的优先级，代价是降低服务器性能。

15.3.2 逻辑备份还是物理备份

逻辑备份（也叫"导出"）和直接复制原始文件的物理备份。

逻辑备份有如下的优点：

• 逻辑备份可以使用编辑器或grep和sed之类的命令查看和操作的普通文件。
• 恢复非常简单。直接导入。
• 可以通过网络来备份和恢复
• 可以在类似Amazon RDS这样不能访问底层文件系统中使