Linux下实现MySQL高可用的主流方案与落地步骤
一、方案总览与选型
- 主从复制 + 读写分离 + VIP/中间件：一主多从提供读扩展，配合中间件（如 MyCat）或 Keepalived 提供故障切换与统一接入；适合读多写少、需要快速上手的场景。
- 双主互备 + Keepalived：两节点互为主从，通过 VIP 漂移实现写高可用；需严格避免双写冲突，适合写可用性优先且能接受一定复杂度的场景。
- MySQL NDB Cluster：无共享的共享无架构（NDB），多数据节点提供高可用与横向扩展；适合高并发、高吞吐和对可用性要求极高的场景。
- Group Replication / InnoDB Cluster：基于组复制的一致性高可用方案，支持多主/单主模式与自动故障转移；适合希望获得官方原生高可用能力的场景。
以上方案在业界均有成熟实践，可按业务规模、一致性与运维能力综合选择。
二、方案一 主从复制 + 读写分离 + VIP/中间件（入门与通用）
- 核心思路：主库写入，从库只读；通过 VIP 或中间件对外提供稳定接入，故障时切换主库或调整路由。
- 实施要点：
- 主库配置：启用 binlog、设置唯一 server-id，创建复制账号并授予 REPLICATION SLAVE 权限；记录 SHOW MASTER STATUS 的 File/Position。
- 从库配置：设置唯一 server-id、relay-log，使用 CHANGE MASTER TO … 指向主库并启动复制；用 SHOW SLAVE STATUS\G 检查 Slave_IO_Running/Slave_SQL_Running=Yes。
- 读写分离：应用侧使用中间件（如 MyCat）配置 balance/writeType/switchType 实现读写分离与故障切换；或在数据库前端使用 Keepalived 绑定 VIP 做主备切换。
- 适用场景：读多写少、并发中等、需要快速提升可用性与读扩展的业务。
三、方案二 双主互备 + Keepalived（写高可用）
- 核心思路：两节点互为主从，通常约定仅一侧可写，另一侧处于只读或延迟只读；通过 Keepalived 管理 VIP 漂移，实现秒级故障切换。
- 实施要点：
- MySQL 双主：双向复制，注意自增主键冲突（如设置 auto_increment_offset/increment）、避免同一时间双向写入。
- Keepalived：配置 vrrp_script 健康检查（如 mysqladmin ping），定义 vrrp_instance 与 virtual_ipaddress；主节点优先级更高，必要时配置 nopreempt 控制切换行为。
- 切换与回切：主机恢复后可按策略自动或手动回切，确保数据一致性与连接收敛。
- 适用场景：写可用性优先、能接受双主约束与更严格运维规范的场景。
四、方案三 MySQL NDB Cluster（共享无集群）
- 核心思路：由管理节点（ndb_mgmd）、数据节点（ndbd/ndbmtd）与 SQL 节点（mysqld）组成，数据在多个数据节点间分片与复制，提供高可用与横向扩展。
- 实施要点：
- 准备至少 3 台服务器（管理节点 1 台、数据节点 2+ 台、SQL 节点 1+ 台），安装 MySQL Cluster 软件。
- 配置 ndb_mgmd 管理文件（如 mycluster.ini），定义管理节点、数据节点与 SQL 节点；数据节点配置 ndbcluster 与连接串。
- 启动管理节点（ndb_mgmd）、数据节点（ndbd）与 SQL 节点（mysqld），使用 ndb_mgm 工具执行 show 查看集群状态。
- 适用场景：高并发、高吞吐、对一致性与可用性要求极高且可接受集群复杂度与内存开销的场景。
五、关键实践与避坑清单
- 复制一致性：优先使用 ROW 格式，结合 GTID 提升可运维性与切换可靠性；定期检查 Seconds_Behind_Master 与复制错误。
- 脑裂与双写：双主架构务必保证“单主写入”策略（应用层或中间件控制），并通过 auto_increment_offset/increment 规避主键冲突。
- 切换策略：明确自动/手动切换边界，切换前确保从库追平或采用最小一致性窗口；回切前完成数据校验与连接清理。
- 连接收敛：使用 VIP 或中间件统一接入，切换时通过 read-only 与连接重试策略降低业务感知时间。
- 监控与演练：对复制延迟、主从状态、VIP 漂移与健康检查脚本建立告警；定期故障演练验证切换时效与数据一致性。