一、MySQL 灾备概述
- 资料已经分类整理好：
https://pan.quark.cn/s/f52968c518d3
核心目标
- 数据冗余：避免单点故障导致数据丢失。
- 业务连续性：在主库故障时快速切换至备用库，减少停机时间。
- 容灾恢复：应对自然灾害、人为误操作等极端情况。
关键指标
- RTO（恢复时间目标）：系统恢复可用的最大时间（如分钟级、小时级）。
- RPO（恢复点目标）：允许的数据丢失量（如秒级延迟、零数据丢失）。
二、常见 MySQL 灾备方案
1. 基于复制的灾备方案
利用 MySQL 原生复制功能（如 Binlog 复制）实现数据同步，分为单主多从、双主等模式。
（1）单主多从（异步复制）
- 架构：1 个主库（Master） + N 个从库（Slave），主库写入数据，从库异步复制主库 Binlog。
- 特点：
- 优点：部署简单，成本低，从库可用于读负载分担。
- 缺点：主库故障时，从库可能丢失未同步的 Binlog（RPO > 0），切换需人工操作（RTO 较长）。
- 适用场景：对数据一致性要求不高的中小型业务（如日志系统、报表查询）。
（2）半同步复制（Semi-Synchronous Replication）
- 改进：主库等待至少一个从库确认接收到 Binlog 后再提交事务。
- 特点：
- 优点：大幅降低数据丢失风险（RPO 接近 0）。
- 缺点：增加主库响应延迟（约几毫秒），需至少 2 个从库保证高可用。
- 适用场景：金融、电商等对数据一致性要求较高的场景。
（3）双主复制（Multi-Master）
- 架构：两个主库互为主从，双向复制数据。
- 特点：
- 优点：支持双活（Active-Active），故障时可快速切换。
- 缺点：可能出现更新冲突（需唯一键约束或业务层避免），复杂度高。
- 适用场景：需要两地数据中心同时读写的场景（如跨区域业务）。
2. 基于集群的高可用方案
通过集群管理节点自动检测主库故障并完成切换，减少人工干预。
（1）MySQL InnoDB Cluster（官方方案）
- 架构：3 个或更多节点组成集群，自动选举主节点，支持无损切换。
- 特点：
- 优点：原生支持高可用，自动处理脑裂，支持多写（实验性）。
- 缺点：需 MySQL 8.0+ 版本，资源消耗较高。
- 关键组件：
- Group Replication：基于 Paxos 协议的同步复制。
- MySQL Router：自动路由读写请求。
- RTO：秒级（自动故障检测与切换）。
（2）MHA（Master High Availability）
- 架构：由 Manager 节点和多个从库组成，监控主库状态，故障时自动提升从库为主库。
- 特点：
- 优点：成熟稳定，支持增量恢复（应用未同步的 Binlog），RPO 接近 0。
- 缺点：需额外部署 Manager 节点，仅支持单主架构。
- 适用场景：传统单主多从架构的企业级应用。
（3）Galera Cluster（同步复制集群）
- 架构：多节点同步复制，所有节点可读写（Active-Active），基于行级复制。
- 特点：
- 优点：强一致性（RPO=0），多写支持，适合实时数据同步。
- 缺点：写入性能受节点数影响，需避免大事务。
- 适用场景：需要多数据中心实时同步的高一致性业务（如金融交易）。
3. 基于备份的灾备方案
通过定期全量备份和增量备份（Binlog）实现数据恢复，适合冷备或异地容灾。
（1）物理备份（如 XtraBackup）
- 工具：Percona XtraBackup（开源，支持热备）。
- 流程：
- 全量备份：复制数据文件 + 锁表记录 Binlog 位置。
- 增量备份：基于上次备份后的 Binlog 持续备份。
- 恢复：
- 还原全量备份，应用增量 Binlog 至目标时间点。
- RPO：取决于备份频率（如每小时全备 + 实时 Binlog，RPO < 1 小时）。
（2）逻辑备份（如 mysqldump）
- 工具：mysqldump（导出 SQL 语句）。
- 特点：
- 优点：轻量级，适合跨版本恢复，可选择性备份表。
- 缺点：备份/恢复速度慢，需锁表（影响业务）。
- 适用场景：非核心数据的长期归档或小数据量恢复。
4. 异地灾备方案
将数据同步至异地数据中心，应对区域性灾难（如地震、机房故障）。
（1）异步复制 + 异地从库
- 架构：主库 → 同城从库（异步复制） → 异地从库（异步复制，延迟更高）。
- 特点：
- 优点：成本低，异地库平时可用于查询或备份。
- 缺点：异地库延迟较高（分钟级），故障切换需手动操作。
（2）基于日志传输的异地备份
- 方案：通过工具（如 rsync、scp）将本地 Binlog 实时传输至异地存储，故障时还原并应用日志。
- 适用场景：对 RTO 要求不高的合规性备份（如金融行业数据留存）。
三、灾备方案选型建议
| 场景 | 推荐方案 | RTO | RPO | 成本 |
|---|---|---|---|---|
| 中小型业务，读多写少 | 单主多从（异步复制） | 分钟级 | 秒级-分钟级 | 低 |
| 高一致性要求（如交易） | 半同步复制 + MHA | 秒级 | 接近 0 | 中 |
| 多数据中心双活 | Galera Cluster / InnoDB Cluster | 秒级 | 0 | 高 |
| 异地容灾（合规备份） | 物理备份 + 异地传输 | 小时级 | 分钟级 | 低 |
四、灾备实施关键步骤
- 需求分析：明确 RTO/RPO 指标、数据一致性要求、预算。
- 架构设计：选择复制模式（异步/半同步/同步）、集群方案。
- 部署与测试：
- 搭建灾备环境，同步主库数据。
- 定期进行故障演练（如模拟主库宕机，测试切换流程）。
- 监控与维护：
- 监控复制延迟、节点状态（如使用 Prometheus + Grafana）。
- 定期备份 Binlog，确保恢复链完整。
五、总结
- 核心原则：根据业务重要性分层设计灾备方案（如核心业务采用同步复制 + 集群，非核心业务采用异步复制）。
- 趋势：云原生灾备（如 AWS DMS、阿里云 RDS 灾备）逐渐普及，结合容器化（Kubernetes）实现弹性容灾。
通过合理组合复制、集群和备份技术，可在成本与可靠性之间找到平衡，确保 MySQL 系统在面对故障时具备足够的韧性。
