读高性能MySQL（第4版）笔记15_备份与恢复（下）

1. 二进制日志

1.1. 服务器的二进制日志是需要备份的最重要元素之一

1.2. 对于基于时间点的恢复是必需的，并且通常比数据要小，所以更容易被进行频繁的备份

1.3. 如果有某个时间点的数据备份和所有从那时以后的二进制日志，就可以重放从上次全备份以来的二进制日志并“向前回滚”所有的变更

1.4. 如果你不能承受丢失超过30分钟数据的代价，至少要每30分钟就备份一次

1.5. 需要制定日志的过期策略以防止磁盘被二进制日志写满

1.6. 日志增长的大小取决于工作负载和日志格式（基于行的日志会产生更大的日志记录）

1.7. 保留日志对于设置复制、分析服务器负载、审计和从上次全备份中按时间点进行恢复，都很有帮助

1.8. 使用binlog_expire_logs_seconds变量来通知MySQL定期清理日志，而不应该手动地去删除这些文件

1.9. MySQL服务器通过查看修改时间而不是内容来决定要清除哪些文件

2. 工具

2.1. MySQL Enterprise Backup

2.1.1. MySQL官方的备份工具

2.2. Percona XtraBackup

2.2.1. 开源并且免费的

2.2.2. 支持类似流、增量、压缩和多线程（并行）备份操作

2.2.3. 降低在高负载系统上进行备份的影响

2.2.4. 当使用Percona XtraBackup进行备份时，它会记录日志序列号（LSN），并使用该序列号对备份文件执行崩溃恢复

2.3. mydumper

2.3.1. 一个多线程（并发）的MySQL备份和恢复工具集

2.4. mysqldump

3. 备份数据

3.1. 应该最大化地利用网络、磁盘和CPU的能力以尽可能快地完成备份

3.2. 主要的问题

3.2.1. 将库表结构和数据存储在一起

3.2.2. 巨大的SQL语句

3.2.2.1. 服务器解析和执行SQL语句的工作量非常大，所以加载数据时会非常慢

3.2.3. 单个巨大的文件

3.2.4. 逻辑备份的成本很高

3.2.4.1. 在生产环境使用逻辑备份可能很难满足要求

3.2.4.2. 如果使用逻辑备份，强烈建议考虑使用mydumper，以避免单线程备份的一些问题，并实际测试使用该工具备份对数据库的影响

3.3. 文件系统快照

3.3.1. 一种非常好的在线备份方法

3.3.2. FreeBSD的文件系统、ZFS文件系统、GNU/Linux的逻辑卷管理（LVM）

3.3.3. 创建快照是减少必须持有锁的时间的一个简单方法；释放锁后，必须将文件复制到备份中

3.3.4. 使用文件系统快照，有些时候甚至无须任何锁定，就可以创建InnoDB的备份快照

3.3.5. 文件系统快照不是取得数据瞬间副本的唯一方法

3.3.5.1. 另外一个选择是RAID分裂

3.3.6. 快照不仅仅用于备份，还有很多其他用途

4. 恢复数据

4.1. 步骤

4.1.1. 停止MySQL服务器

4.1.2. 记录服务器的配置和文件权限

4.1.3. 将数据从备份中移到MySQL数据目录

4.1.4. 改变配置

4.1.5. 改变文件权限

4.1.6. 以限制访问模式重启服务器，等待其完成启动

4.1.7. 载入逻辑备份文件

4.1.8. 检查和重放二进制日志

4.1.9. 检测已经还原的数据

4.1.10. ⑩以完全权限重启服务器

4.2. 恢复逻辑备份

4.2.1. 如果恢复的是逻辑备份而不是裸文件备份，则与使用操作系统将文件简单地复制到适当位置的方式不同，需要使用MySQL服务器本身来将数据加载到表中

4.2.2. 一个值得倡导的规则是，恢复过程越难越复杂，也就越需要逻辑备份的保护

4.2.3. 应付某些无法使用裸文件备份的场景，准备好逻辑备份总是值得推荐的

4.3. 从快照中恢复

4.3.1. 恢复裸文件备份往往非常直接

4.3.2. 如果使用InnoDB的file-per-table特性（innodb_file_per_table），InnoDB会将每个表的数据和索引存储于一个.ibd文件中

4.3.3. 最大的限制是，只能在当初备份的服务器上还原单个表