MySQL高可用集群需基于主从复制+故障检测+自动切换构建，主流推荐MHA或Orchestrator配合GTID与ProxySQL；必须启用binlog_format=ROW、slave_parallel_workers>0且slave_preserve_commit_order=ON、innodb_flush_log_at_trx_commit=1与sync_binlog=1，并确保server_id全局唯一；健康检查须验证Slave_IO_Running、Slave_SQL_Running状态及Seconds_Behind_Master、GTID集一致性，而非仅端口探测。
MySQL 高可用集群不是单靠“部署几个实例”就能实现的
MySQL 本身不内置分布式集群（如 TiDB 或 Cassandra 那种），所谓“高可用集群”实际是围绕主从复制 + 故障检测 + 自动切换构建的一套协作体系。直接用 mysqld 启动多个实例，不加协调机制，挂一个就断服务——这不是高可用，只是多副本而已。
主流方案选型：MHA、Orchestrator、ProxySQL + GTID 是当前最可控的组合
不推荐用已停止维护的 MMM，也别迷信 MySQL Group Replication（MGR）开箱即用：它对网络稳定性、时钟同步、配置一致性极其敏感，小团队踩坑成本远高于收益。
-
MHA（Master High Availability）仍是最轻量、故障切换最稳的选择，但需手动补全 VIP 漂移和客户端重连逻辑 -
Orchestrator提供 Web 界面和自动拓扑发现，支持多种切换策略，且能对接 Consul 或 ZooKeeper 做状态同步 - 必须开启
GTID（gtid_mode=ON+enforce_gtid_consistency=ON），否则从库跳过错误或切换后数据不一致几乎不可避免 -
ProxySQL不是必须，但加一层能屏蔽后端切换对应用的影响；注意它的mysql_servers表需配合 Orchestrator 的 hooks 自动更新
关键配置项漏设会导致切换失败或脑裂
很多集群在压测时看似正常，一到真实主库宕机就丢数据或双主写入——问题往往出在几个看似“可选”的参数上。
-
binlog_format=ROW：语句级（STATEMENT）在跨版本或函数调用时极易导致从库执行失败 -
slave_parallel_workers > 0且slave_preserve_commit_order=ON：否则并行回放可能打乱事务提交顺序，GTID 切换后位置错乱 -
innodb_flush_log_at_trx_commit=1和sync_binlog=1必须同时启用，否则主库崩溃可能丢失已确认的事务 - 所有节点的
server_id必须全局唯一，且不能为 0 或重复——Orchestrator 会直接拒绝纳管
健康检查不能只 ping 端口，得查 SHOW SLAVE STATUS 的关键字段
很多运维脚本用 nc -z host 3306 判断 MySQL 是否存活，这完全没意义：从库可能端口通、SQL 线程却已停止（Slave_SQL_Running: No），或者延迟高达数小时（Seconds_Behind_Master 虚高）。真正的可用性判断必须落到复制状态上。
- 检查
Slave_IO_Running和Slave_SQL_Running是否均为Yes - 确认
Seconds_Behind_Master≤ 5（根据业务容忍度调整，但绝不接受 NULL 或 NULLABLE 值） - 核对
Retrieved_Gtid_Set和Executed_Gtid_Set差值是否为 0（非 GTID 模式则比对Relay_Master_Log_File与Exec_Master_Log_Pos） - Orchestrator 默认每 3 秒执行一次该检查，频率过高会加重主库压力，过低则故障发现滞后
真正难的从来不是“怎么搭起来”，而是让所有节点在主库异常、网络分区、磁盘满、relay log 损坏等十几种边缘场景下，依然能给出确定性响应——这些细节藏在日志轮转策略、relay_log_purge 开关、max_relay_log_size 设置和监控告警阈值里。
