MySQL主从迁集群是架构重构，需分阶段实施：先选型（InnoDB Cluster强一致、PXC多点写、ProxySQL灵活）、再准备（版本/引擎/应用适配）、然后灰度切流（读→写）、最后下线旧架构，并强化监控与运维。
MySQL 从主从架构迁移到集群（如 InnoDB Cluster、MGR 或 Percona XtraDB Cluster）不是简单升级，而是架构重构。核心目标是提升高可用性、故障自动恢复能力与读写扩展性，同时保障数据一致性与业务连续性。迁移需分阶段设计，不能直接替换。
明确集群选型与适用场景
不同 MySQL 集群方案定位差异明显，选错会增加运维复杂度甚至引入新风险：
- InnoDB Cluster（基于 MGR）：官方推荐，强一致性（多数派写入）、自动故障转移、集成 MySQL Shell 管理；适合对一致性要求高、希望轻量级集群的中大型业务。
- Percona XtraDB Cluster（PXC）：基于 Galera，同步复制、多点写入支持好；但写入性能受最慢节点拖累，DDL 操作需谨慎；适合读多写少、需多活写入的场景。
- ProxySQL + 多主/一主多从 + 自定义健康检查：非原生集群，灵活性高，但 HA 逻辑需自行实现；适合已有成熟运维体系、需要渐进式改造的团队。
迁移前必须完成的准备动作
跳过评估和预检，90% 的迁移失败源于基础不牢：
- 确认所有节点 MySQL 版本一致且 ≥ 8.0.19（MGR 推荐）或 ≥ 5.7.21（PXC 最低要求），禁用不兼容参数（如 red">binlog_format=STATEMENT 必须改为 ROW）。
- 清理主从延迟、GTID 不一致、匿名事务、非事务引擎表（MyISAM） —— MGR/PXC 不支持 MyISAM，必须转为 InnoDB。
- 应用层适配检查：关闭长连接自动重连（避免切换时连接残留）、禁用查询缓存、确认无依赖 binlog 解析的逻辑（如 Canal）、验证事务边界是否合理（大事务易触发流控或超时）。
- 搭建最小三节点测试集群，用生产备份 + 重放增量 binlog 方式还原数据，全流程演练部署、故障模拟（kill 节点）、切换验证与回滚流程。
分阶段平滑迁移路径
不中断业务的关键是“流量可灰度、状态可回退”：
- 第一阶段：主从并行双写（可选） —— 在应用侧或中间件层，将写请求同时发往旧主从和新集群（仅限关键表），用于校验数据一致性；此步非必须，但对核心系统强烈建议。
- 第二阶段：只读流量切流 —— 将查询请求逐步导向集群 Proxy（如 MySQL Router 或 ProxySQL），主从仍承担写入；观察集群负载、复制延迟、慢查询变化。
- 第三阶段：写入切换与验证 —— 选择业务低峰期，停写旧主库 → 等待从库追平 → 切写入到集群写节点 → 开启集群读写 → 实时比对新旧库 binlog position/GTID set 和关键表 checksum。
- 第四阶段：旧主从下线 —— 确认集群稳定运行 48–72 小时、监控无异常、备份链路已切至集群后，再停用旧架构。
不可忽视的运维与监控升级
集群不是“设好就完事”，它改变了故障模式：
- 必须启用并告警关键指标：MGR 的 group_replication_primary_member、PXC 的 wsrep_local_state_comment、所有集群的 wsrep_cluster_size / group_replication_members、流控触发次数（flow_control_sent/received）。
- 备份策略调整：不再备份单点，改用 mydumper + LVM 快照 或 xtrabackup --slave-info（PXC）+ 集群全量快照；备份源应为非写节点，避免影响性能。
- DDL 变更规范：MGR 中 DDL 默认为全局锁（lock=SHARED），PXC 要求 wsrep_OSU_method=TOI（全集群同步执行），严禁在线大表变更未评估影响。
