高可用架构方案

MySQL 高可用架构设计

高可用确保MySQL数据库在故障期间保持可访问。本指南涵盖架构模式、故障转移机制和操作挑战。

1. 高可用基础

RTO（恢复时间目标）：故障后多久恢复服务
RPO（恢复点目标）：可接受多少数据丢失

99% 可用性 = 3.65 天/年 停机时间
99.99% 可用性 = 52.6 分钟/年 停机时间

高可用需要：
├─ 冗余（多个服务器）
├─ 自动检测（健康检查）
├─ 自动故障转移（切换到副本）
├─ 数据一致性（无数据丢失）
└─ 监控（告警）

2. 主从复制

异步复制（传统）：
└─ 主立即返回成功（宾日志稍后发送）
└─ 风险：宾日志发送前主宕机 = 数据丢失

同步复制（MySQL 5.7+）：
└─ 主等待从确认后再返回成功
└─ 优点：无数据丢失，缺点：延迟高

半同步复制（混合）：
└─ 主等待至少ONE从确认
└─ 好性能 + 好安全（最常见）

3. HA解决方案对比

MHA（主高可用）：
├─ 3+节点
├─ 自动故障转移（10-30秒）
├─ 复杂配置
└─ 支持旧版本

Keepalived：
├─ 2节点（VIP）
├─ 非常快故障转移（<1秒）
├─ 简单配置
└─ 无自动从提升

InnoDB集群（MGR）：
├─ 3+节点，自动多主
├─ 完全自动化
├─ MySQL 8.0+
├─ 最新解决方案

4. 关键挑战

脑裂问题：网络分区导致两个主
├─ 解决方案1：仲裁（多数节点同意）
├─ 解决方案2：隔离（关闭失败主）
└─ 解决方案3：VIP（虚拟IP转移）

数据一致性：转移前丢失的宾日志
├─ 解决方案1：同步复制
├─ 解决方案2：半同步复制
└─ 解决方案3：宾日志恢复（应用未复制事件）

5. 最佳实践

• 使用半同步复制 — 安全与性能平衡
• 部署3+节点 — 仲裁防止脑裂
• 实施监控 — 快速检测故障
• 定期测试故障转移 — 验证程序
• 使用VIP/DNS — 应用透明故障转移
• 配置隔离 — 防止脑裂
• 文档化程序 — 手动转移有时需要
• 考虑InnoDB集群 — MySQL 8.0+更简单

总结

高可用需要结合复制、监控和自动故障转移。根据节点数、版本和自动化需求选择解决方案。在生产部署前彻底测试故障转移程序。