Linux MySQL如何实现高可用性架构

Linux MySQL高可用架构实现指南

一、常见架构选型与适用场景

• 主从复制（Master–Slave）：一主多从，写主读从，读扩展能力强；主库故障需人工或配合中间件/脚本提升从库为主，适合大多数在线业务的基础形态。
• 双主互备（Master–Master）：两节点互为主从，配合VIP对外统一入口，任一节点故障可快速切换；需严格避免双写冲突，适合写可用性要求较高的场景。
• InnoDB Cluster（Group Replication/MGR）：基于组复制的多节点一致性集群，提供自动故障检测与恢复、读写分离与横向扩展能力，适合对一致性与自动化要求高的场景。
• Kubernetes 上的 MySQL：通过 **Helm（Bitnami）**部署复制型集群，结合 StatefulSet、持久卷、Service，便于弹性与自愈，适合云原生环境。
• 传统 HA 组件组合：如 DRBD + Heartbeat、MMM 等，通过块设备镜像与虚拟 IP 漂移实现主备切换，适合有存量系统改造需求的场景。

二、落地实现步骤

• 主从复制（入门与通用）
  1. 配置主库：开启二进制日志并设置唯一 server-id，创建复制账号并记录位置。
  2. 初始化数据：主库已有数据时，用 mysqldump --master-data=2 或物理备份（如 Percona XtraBackup）在从库恢复。
  3. 配置从库：设置唯一 server-id、relay-log，执行 CHANGE MASTER TO … 指向主库并启动复制。
  4. 校验复制：在从库执行 SHOW SLAVE STATUS\G，确认 Slave_IO_Running 与 Slave_SQL_Running 均为 Yes。
  5. 读写分离：应用或中间件将写发往主库、读发往从库，提升读吞吐。
• 双主互备 + Keepalived（自动切换）
  1. 搭建双向复制：两节点互为主从，建议仅在一端开启写入或按库/表做写入分片，避免自增主键冲突。
  2. 配置 VIP 与 Keepalived：在两台机器上部署 Keepalived，定义 vrrp_instance 与 virtual_ipaddress，通过 TCP_CHECK 检测本地 MySQL 3306 端口健康。
  3. 故障切换：当检测到 MySQL 异常时执行脚本（如 notify_down 中 pkill keepalived）使 VIP 漂移到对端，实现主从自动切换。
• InnoDB Cluster（MGR，自动化高可用）
  1. 准备 3–7 个节点，启用 group_replication 相关参数与复制用户。
  2. 使用 MySQL Shell 初始化集群（如 dba.createCluster()）、添加实例（cluster.addInstance()），形成多节点一致性组。
  3. 通过 MySQL Router 提供应用透明的读写分离与故障转移入口。
• Kubernetes（云原生）
  1. 使用 Helm 部署 Bitnami MySQL 复制集群（如 –set architecture=replication），配置 primary.replicaCount、persistence.size。
  2. 通过 Service 暴露读写端点，结合应用或 ProxySQL/MaxScale 做读写分离与健康检查。

三、关键配置与最佳实践

• 复制与一致性
  • 主从开启 GTID（如 gtid_mode=ON、enforce_gtid_consistency=ON）便于故障切换与一致性校验。
  • 选择 ROW 格式复制，减少不确定语句带来的不一致风险。
  • 从库建议设置 read_only=1（超级用户除外），避免误写。
• 切换与流量治理
  • 双主场景通过 VIP + Keepalived 或 MGR 的内置故障转移实现自动切换；应用尽量使用域名或服务名而非固定 IP。
  • 读写分离建议通过 HAProxy/MaxScale/MySQL Router 实现，并配置健康检查与连接池。
• 监控与备份
  • 监控复制延迟（如 Seconds_Behind_Master）、主从 IO/SQL 线程状态、连接数、慢查询、磁盘与延迟抖动。
  • 定期全量 + 增量备份（如 mysqldump/物理备份），保留可回滚的 binlog；定期做恢复演练与一致性校验。
• 版本与升级
  • 主从/集群节点版本尽量一致或兼容；变更窗口内滚动升级，先从只读从库/非核心节点开始。

四、故障切换与演练要点

• 主从切换流程
  1. 确认主库异常且不可快速恢复；选择一个数据最新的从库（如 GTID 最靠前、复制延迟最低）。
  2. 在从库上停止复制（STOP SLAVE; RESET SLAVE ALL;），提升为新的主库。
  3. 将应用与中间件指向新主库；双主/VIP 场景触发 VIP 漂移或对 MGR 执行 cluster.rejoinInstance()。
  4. 原主库恢复后，以从库身份重新加入集群并追平数据。
• 演练与回放
  • 定期在灰度环境演练主从切换、双主切换与 MGR/K8s 故障恢复，记录 RTO/RPO 指标并优化脚本与超时参数。
  • 对关键业务在切换前做 备份快照，确保可快速回滚。

五、方案对比与选型建议