读高性能MySQL（第4版）笔记13_备份与恢复（上），

1. 每个人都知道需要备份，但并不是每个人都能意识到需要的是可恢复的备份

1.1. 如果你没有提前做好备份规划，也许以后会发现已经错失了一些最佳的选择

1.2. 在服务器已经配置好以后，才想起应该使用LVM，以便获取文件系统的快照——但这时已经太迟了

1.3. 如果你没有计划做定期的恢复演练，当真的需要恢复时，就会发现并没有那么顺利

2. 不要掉进副本就是备份的陷阱

2.1. 副本对生成备份而言是一个干涉较少的源，但它不是备份本身

2.2. 确保备份可以通过DROP TABLE测试

2.2.1. “遭受黑客攻击”的测试

2.2.2. 能通过数据中心失败的测试

2.2.3. 如果是基于备库生成备份，需要通过从源重建备份，并从那时起强制执行super_read_only来确保你的所有副本是一致的

3. 裸文件备份

3.1. 物理备份

3.2. 文件系统中的文件副本

4. 逻辑备份

4.1. 重建数据所需的SQL语句

5. 推荐的备份方式

5.1. Percona XtraBackup进行裸文件备份

5.2. mydumper进行逻辑备份

5.3. 无侵入地实现二进制的原始数据备份

5.3.1. 备份可以通过启动mysqld实例检查所有的表来进行验证

5.3.2. 建议备份二进制日志

5.3.2.1. 尽可能久地保留多份备份的数据和二进制文件

5.3.2.2. 即使最近的备份无法使用，还可以使用较老的备份来执行恢复或者创建新的副本

6. 整体备份和恢复策略要点

6.1. 安全

6.1.1. 访问备份的入口

6.1.2. 恢复数据的权限

6.1.3. 文件是否需要加密

6.2. 备份存储在哪里

6.2.1. 离源数据多远

6.2.1.1. 在一块不同的磁盘上

6.2.1.2. 一台不同的服务器上

6.2.1.3. 离线存储

6.2.2. 如何将数据从源头移动到目的地

6.3. 保留策略、审计、法律要求，以及相关的条款

6.4. 存储解决方案和介质，压缩，以及增量备份

6.5. 存储的格式

6.6. 对备份的监控和报告

6.7. 存储层内置备份功能

6.7.1. 其他专用设备

7. 热备份

7.1. 不需要任何的服务停机时间

8. 还原

8.1. 从备份文件中获取数据，可以将这些文件加载到MySQL里，也可以将这些文件放置到MySQL期望的路径中

9. 恢复

9.1. 当某些异常发生后对一个系统或其部分的拯救

9.2. 从备份中还原数据

9.3. 使服务器完全恢复功能的所有必要步骤

9.4. 存储引擎的崩溃恢复要求数据和日志文件一致

9.4.1. 要确保数据文件中只包含已经提交的事务所做的修改，恢复操作会将日志中还没有应用到数据文件的事务重新执行

10. 备份的理由

10.1. 灾难恢复

10.1.1. 硬件故障

10.1.2. 一个不经意的Bug导致数据损坏

10.1.3. 服务器及其数据由于某些原因不可获取或无法使用

10.1.4. 某人偶然连错服务器执行了一个ALTER TABLE操作

10.1.5. 机房大楼被烧毁

10.1.6. 恶意的黑客攻击

10.2. 人们改变想法

10.2.1. 经常会在删除某些数据后又想恢复这些数据

10.3. 审计

10.3.1. 需要知道数据或Schema在过去的某个时间点是什么样的

10.4. 测试

10.4.1. 最简单的基于实际数据来测试的方法是，定期用最新的生产环境数据更新测试服务器

10.4.2. 只要把备份文件还原到测试服务器上即可

11. 备份误区

11.1. 复制就是备份

11.1.1. 复制不是备份

11.1.2. 使用RAID阵列也不是备份

11.1.3. 不是备份，也不是备份的替代品

11.2. 快照就是备份

11.2.1. 无论是LVM、ZFS还是SAN快照，都不是真正的备份

11.2.1.1. 不包含数据的完整副本

11.2.2. 快照是写时复制

11.2.2.1. 只包含数据的实时副本与快照发生时的数据之间的差异

11.2.3. 如果备份是用于某些特殊用户的，那么快照可能是一个非常好的方法

12. 定义恢复需求

12.1. 备份在先

12.1.1. 只有已经做了备份才可能恢复，因此在构建系统时，注意力自然会集中在备份上

12.2. 备份由脚本和任务自动完成

12.3. 备份是日常任务，但恢复常常发生在危急情形下

12.4. 安全的需要

12.4.1. 做异地备份，可能需要对备份数据进行加密，或采取其他措施来进行保护

12.5. 需要培养几个人并有计划地让他们互为备份，这样就无须由一个不合格的人来恢复数据

12.6. 恢复点目标（PRO）

12.7. 恢复时间目标（RTO）

13. 备份方案

13.1. 备份仅是数据的一个副本，但是受限于应用程序的要求、MySQL的存储引擎架构，以及系统配置等因素，复制一份数据变得很困难

13.2. 对数据丢失的承受力越强，备份越简单

13.2.1. 一个“宽松”的基于故障时间点的恢复需求意味着需要重建数据，直到“足够接近”问题发生的时刻

13.2.2. 一个“硬性”的需求意味着不能容忍丢失任何一个已提交的事务，即使某些可怕的事情发生（例如，服务器着火了）

13.2.2.1. 将二进制日志保存在一个独立的SAN卷

13.2.2.2. 使用DRBD磁盘复制

13.3. 在生产实践中，对于大数据库来说，裸文件备份是必需的：逻辑备份太慢并受到资源限制，从逻辑备份中恢复需要很长时间

13.3.1. 基于快照的备份，例如Percona   XtraBackup和MySQL  EnterpriseBackup，是最好的选择

13.3.2. 对于较小的数据库，逻辑备份可以很好地胜任

13.4. 保留多个备份集

13.5. 定期从逻辑备份（或者裸文件备份）中抽取数据进行恢复测试

13.6. 保存二进制日志用于基于故障时间点的恢复

13.6.1. 将expire_logs_days参数的值设置得足够大，至少确保可以从最近两次裸文件备份中做基于时间点的恢复

13.6.2. 保持源运行且不应用任何二进制日志的情况下创建一个副本

13.6.3. 使备份二进制日志独立于过期设置，二进制日志需要保存在备份中足够长的时间，以便能从最近的逻辑备份中进行恢复

13.6.4. 重放二进制日志来恢复到想要的时间点

13.7. 完全不借助备份工具本身来监控备份和备份的过程

13.7.1. 需要额外验证备份是否正常

13.8. 通过演练整个恢复过程来测试备份和恢复

13.8.1. 测算恢复所需要的资源（CPU、磁盘空间、实际时间，以及网络带宽等）

13.9. 考虑安全性