在 CentOS 上构建 MySQL 容灾的可落地方案
一、方案选型与适用场景
| 方案 |
架构要点 |
容灾能力 |
一致性 |
复杂度 |
典型场景 |
| 主从复制 + Keepalived VIP |
一主一从/一主多从，应用通过 VIP 访问主库 |
主机宕机可切换至从库，读扩展 |
异步为主，可上半同步 |
低-中 |
读多写少、成本敏感 |
| 双主复制 + Keepalived VIP |
两节点互为主从，各自写入，通过 VIP 对外 |
单节点宕机可切换，写能力保留 |
需防自增冲突，建议配合GTID |
中 |
需要基本双活与自动漂移 |
| MySQL InnoDB Cluster（MGR） |
官方多主/单主集群，基于 Group Replication |
自动选主、自动恢复 |
强一致（多数派） |
中-高 |
新项目、对一致性与自动化要求高 |
| MHA + 主从 |
管理节点监控主库，故障自动提升从库 |
秒级切换（依赖复制延迟） |
异步/半同步，可能丢少量数据 |
中 |
传统架构过渡、兼容性好 |
| Galera Cluster |
多主同步复制（wsrep） |
多节点高可用 |
同步一致 |
中-高 |
需要多主写与强一致 |
以上方案在业界广泛使用，均可在 CentOS 7/8 上落地；选择时优先考虑一致性、切换自动化程度与团队运维能力。
二、快速落地两套常用架构
三、关键配置与切换要点
- 复制必备参数
- 建议启用 GTID（gtid_mode=ON、enforce_gtid_consistency=ON），便于故障切换与一致性校验。
- 性能与安全：sync_binlog=1、binlog_format=ROW，必要时开启 SSL/TLS 加密复制链路。
- 一致性策略
- 主从/双主以异步为主，关键业务建议上 半同步复制 降低数据丢失风险。
- 双主务必配置 auto_increment_offset/increment 或使用业务唯一键策略，避免主键冲突。
- 切换与演练
- 定期演练主从/双主切换与恢复流程，验证 复制延迟、数据一致性、VIP 漂移 是否符合 RTO/RPO 目标。
- 切换后优先保障数据不丢与顺序一致性，再恢复写入与读流量。
四、备份恢复与监控告警
- 备份策略
- 逻辑备份：mysqldump/mysqlpump 做全量/增量导出，便于迁移与快速恢复。
- 物理备份：Percona XtraBackup 支持在线热备与时间点恢复（PITR），适合大库与严格 RPO 场景。
- 监控与告警
- 持续监控 复制延迟、复制错误、连接数、慢查询、磁盘/IO 等关键指标；结合 Prometheus/Grafana 或 Zabbix 设置阈值告警。
- 建议对 VIP 漂移、主从角色变化、备份成功率 建立事件告警与值班响应机制。
五、如何选择与落地顺序
- 若追求自动化与强一致，优先选 InnoDB Cluster（MGR）；若强调兼容与成本，先上 主从 + Keepalived VIP；需要基本双活可用 双主 + Keepalived VIP。
- 落地顺序建议：容量与一致性评估 → 方案与切换流程设计 → 预演与压测 → 监控告警与备份策略上线 → 灰度切换与复盘优化。