备份与恢复
MySQL 的可恢复性通常由完整数据基线与连续 Binary Log 组成。Backup 解决历史和介质恢复，Replica 解决冗余与接管，两者不能互相替代。
备份方式
| 方式 | 特点 | 边界 |
|---|---|---|
mysqldump | 逻辑 SQL、可读且便于选择对象 | 大库慢，恢复需要重放 SQL 和重建索引 |
| MySQL Shell Dump | 并行逻辑导出导入 | 需确认版本、对象与目标兼容 |
| MySQL Enterprise Backup | InnoDB 在线物理备份 | 商业产品，版本与授权需确认 |
| 文件系统快照 | 生成快，适合大数据卷 | 必须保证数据、Redo 和所有表空间一致 |
| Replica 备份 | 降低 Source 负载 | 需记录 GTID/位置并确认复制追平 |
直接复制运行中的 Data Directory 通常不能得到一致备份。也不能通过删除 ibdata、Redo 或 Undo 文件尝试“重建”生产实例，这可能造成不可逆数据损坏。
PITR
Point-in-Time Recovery 先恢复完整备份，再用 mysqlbinlog 等工具重放备份之后的 Binlog，停止在误操作之前。
Binlog 归档必须连续。PURGE BINARY LOGS 前应确认 Replica、备份和 PITR 不再需要相关日志；不要直接删除文件系统中的 Binlog 文件。
备份范围
- 业务 Schema、表、View、Trigger、Event 和 Routine。
- 用户、角色、授权和认证插件信息。
- 配置文件、TLS 证书、Keyring 与加密密钥。
- GTID、Binlog 坐标和复制拓扑信息。
- 外部任务、代理、监控和连接配置。
只恢复业务表但缺少密钥或权限，数据库仍可能无法正常提供服务。
恢复演练
- 在隔离环境恢复完整备份。
- 重放 Binlog 到指定目标点。
- 检查表、索引、约束、账户和字符集。
- 比较关键行数、金额汇总和业务不变量。
- 测量实际 RPO/RTO，并记录自动化步骤。
“备份任务成功”只证明产出了文件，不证明文件完整、密钥可用或恢复时间满足要求。