mysql集群是什么_mysql高可用方案说明

mysql集群是为解决单点故障、读写瓶颈和数据一致性而组合使用的多种架构模式，包括主从复制、InnoDB Cluster（MGR）、DRBD+Keepalived、MHA/Orchestrator等，选型需匹配具体目标，落地成败关键在版本统一、危险SQL禁用、备份验证与监控嵌入。

MySQL 集群不是单一技术，而是**为解决单点故障、读写瓶颈和数据一致性问题而组合使用的多种架构模式的统称**。它不等于“装一堆 MySQL 就叫集群”，真正落地时必须明确目标：你要的是自动故障转移？读写分离？强一致多主？还是纯粹防宕机？ 下面从实操角度拆解最常遇到的几个真实场景。

主从复制（Replication）是所有高可用方案的地基

几乎所有 MySQL 高可用方案都依赖二进制日志（binlog）同步机制。主库写入变更后生成 binary log events，从库通过 I/O Thread 拉取并写入 relay log，再由 SQL thread 重放——这就是经典异步复制链路。

• 必须开启 log-bin，且主从 server-id 绝对不能重复
• GTID 模式（MySQL 5.6+）强烈推荐，避免手动找 File/position，切换更可靠
• 常见翻车点：slave_sql_running: No 往往是主从表结构不一致或从库执行了 DML；seconds_behind_master 持续增长说明从库 IO 或磁盘慢，不是网络问题
• 不要在从库写入数据——除非你已用 read_only=ON + super_read_only=ON 双锁死

InnoDB Cluster（MGR）适合需要自动选主和强一致的中小规模业务

MySQL 官方 5.7.17+ 提供的 Group Replication（MGR）是基于 Paxos 协议的多节点共识机制，天然支持单主/多主模式，故障后秒级自动切换，无需外部工具干预。

• 必须使用 ROW 格式 binlog（binlog_format=ROW），否则事务无法校验
• enforce_gtid_consistency=ON 和 gtid_mode=ON 是硬性前提
• 节点间网络延迟必须稳定 ≤ 100ms，否则频繁踢出节点（MEMBER_STATE=UNREACHABLE）
• 别跳过 MySQL router 直连节点——它是唯一能感知集群状态并自动路由到当前主库的代理

CHANGE MASTER TO    MASTER_USER='repl',    MASTER_PASSword='xxx',   MASTER_HOST='cluster-node-1',   MASTER_PORT=3306,   GET_MASTER_PUBLIC_KEY=1;

DRBD + Heartbeat / Keepalived 是“类 SAN”但成本更低的双机热备方案

DRBD 不同步 SQL 日志，而是直接镜像整个块设备（/dev/sdb），主库写磁盘前强制同步到备机，故障时 VIP 漂移 + 文件系统重新挂载即可启动 MySQL——数据零丢失，但仅限两节点。

• DRBD 同步模式必须设为 protocol C（同步写），否则有丢数据风险
• Heartbeat 已基本被 Keepalived 替代，后者轻量、配置直观，配合 notify_master 脚本可自动启停 MySQL
• 注意：DRBD 无法跨数据中心，两地三中心场景必须用异步复制+人工干预
• 升级 MySQL 版本前务必先停 DRBD，否则元数据不兼容直接导致脑裂

MHA 和 Orchestrator 这类工具只解决“故障发现+切换”，不解决数据一致性

MHA（Master High Availability）是 perl 写的老牌切换工具，能在 10–30 秒内完成主从提升，但它本身不保证从库没延迟、不校验 GTID、也不管你有没有未提交事务。现在更推荐 Orchestrator（go 编写，带 Web ui）或 proxySQL + 自动化脚本。

• MHA 的 master_ip_failover_script 必须自己写，否则 VIP 不会漂移
• 切换后务必检查新主库的 Executed_Gtid_Set 是否包含旧主库最后的事务，否则可能丢写
• 别在 MHA 环境里混用半同步（rpl_semi_sync_master_enabled），它和 MHA 的 failover 逻辑有冲突
• 如果业务允许几秒延迟，用 ProxySQL + read/write hostgroup 做读写分离比折腾 MHA 更稳

真正决定方案成败的，往往不是选哪个架构，而是**是否统一了 MySQL 版本、是否禁用了危险 SQL（如 CREATE TEMPORARY table）、是否定期验证备份可恢复、以及是否把监控嵌进了切换流程**——这些细节比“集群”二字重要得多。