MySQL集群部署难点在于设计决策与运维细节而非技术本身，需权衡架构选型、一致性模型、故障恢复、监控告警及配置同步等多维度因素。
MySQL集群部署确实比单机部署复杂，但难点不在技术本身，而在于设计决策和运维细节的把控。
架构选型是第一道坎
MySQL官方没有“开箱即用”的原生集群方案，常见组合包括：主从复制（Replication）、InnoDB Cluster（基于Group Replication）、MGR（MySQL Group Replication）、ProxySQL + MHA、或第三方方案如Percona XtraDB Cluster（PXC）。不同方案一致性模型、故障切换逻辑、写入限制、网络要求差异很大。比如MGR默认强制多数派写入，3节点集群中挂掉2个就不可写；而异步主从虽简单，但存在数据延迟和脑裂风险。
- 业务能容忍多少秒级延迟？决定是否用异步/半同步/组复制
- 是否需要多点写入？PXC支持，但冲突处理需应用层配合
- 是否有跨机房需求？要考虑网络延迟对共识协议的影响
数据一致性与故障恢复难验证
配置写完不等于跑得稳。主从延迟可能在压力下飙升，GTID错位、relay log损坏、auto-position失效等问题常在故障时集中暴露。更隐蔽的是“伪一致”——从库SQL线程没报错，但因唯一键冲突或非事务引擎导致数据实际不一致。
创建或更新经过代理的 Cloudflare DNS A 记录，用于通过编程方式将子域名指向 IP 地址。输入参数为记录名称、区域名称和 IP 地址。
- 必须定期用pt-table-checksum校验主从数据一致性
- 模拟网络分区、kill -9主库进程、拔网线等真实故障，观察切换是否自动、日志是否连续、有无数据丢失
- 备份恢复流程要实测：从全量+binlog恢复到指定时间点，不能只停留在脚本存在
运维监控不能只看“是否存活”
集群健康不是“所有节点show slave status显示Yes”就够了。真正关键指标包括：Seconds_Behind_Master抖动趋势、Group Replication成员状态变化频率、Flow Control触发次数、ProxySQL后端权重异常漂移、慢查询在从库积压情况。
- 用Prometheus + mysqld_exporter采集细粒度指标，而非仅依赖Zabbix连通性检测
- 设置动态告警阈值：比如延迟超过平均值3倍且持续60秒才触发，避免毛刺误报
- 为每个节点单独配置max_connections和innodb_buffer_pool_size，避免资源争抢引发雪崩
权限与配置同步容易被忽略
集群里用户账号、密码、SSL证书、防火墙规则、系统参数（如net.core.somaxconn）必须严格统一。一个节点my.cnf漏配skip_name_resolve，可能导致DNS解析超时阻塞整个组通信；某个从库少了replication slave权限，切换后立刻中断复制链路。
- 用Ansible或SaltStack统一推送配置，禁止手工修改
- 账号管理走mysql.user表导出+导入，不用CREATE USER语句逐台执行（密码哈希可能因版本差异失效）
- SSL证书用内部CA签发，所有节点共用同一套CA证书和私钥策略
