升级主从架构是为了应对数据量增长、并发上升和故障恢复要求提高带来的瓶颈，如主库单点压力大、从库延迟高、切换不自动、读能力无法弹性扩展。
为什么 要升级主从架构
主从架构在业务初期能解决读写分离、备份和简单高可用问题，但随着数据量增长、并发上升、故障恢复要求提高，原架构会暴露明显短板：主库单点压力大、从库延迟高、切换过程不自动、无法弹性扩展读能力。升级不是为了“上新技术”，而是应对实际瓶颈——比如报表查询拖慢交易、从库延迟超 30 秒导致数据不一致、人工 f ailover 耗时 5 分钟以上影响 SLA。
常见升级路径与适用场景
升级不是一步跳到分布式数据库，而是按需分阶段演进：
- 加中间件层（如 ShardingSphere-Proxy 或 MyCat）：适合已有大量单库应用、暂时无法改代码的场景。可透明实现读写分离 + 多从负载 + 延迟读策略，但不解决单表过大或写瓶颈。
- 引入 MHA 或 Orchestrator 替代传统主从切换：解决自动选主、GTID 一致性校验、避免脑裂等问题。比脚本化切换更可靠，部署轻量，建议作为主从架构的“增强标配”。
- 拆分为分库分表（如按用户 ID 哈希）：当单库 QPS 持续超 3000、单表行数过亿、磁盘使用率长期>80% 时考虑。需配合应用改造或使用代理层，重点控制跨分片 JOIN 和分布式事务成本。
- 迁移到 MySQL Group Replication 或 Percona XtraDB Cluster：需要强一致性多写、自动故障转移，但对网络稳定性、事务冲突敏感，适合中小规模核心系统，不推荐直接用于高冲突写场景。
升级中必须守住的底线
无论走哪条路，三件事不能妥协：
- 全链路 GTID 必须开启：这是复制一致性、故障定位、切换回切的基础，关闭 GTID 的主从环境几乎无法安全升级。
- 所有从库启用 relay_log_recovery=ON：避免主机重启后从库因 relay log 损坏导致复制中断，这个参数常被忽略但极其关键。
- 监控覆盖复制延迟、Seconds_Behind_Master 波动、IO/SQL 线程状态、半同步 ack 超时次数：仅看“复制是否运行中”远远不够，要能提前发现积压拐点和隐性异常。
平滑过渡的关键操作习惯
升级不是一次性割接，而是通过可控灰度降低风险：
- 新架构先接入只读流量，用影子流量或低峰时段验证查询正确性与性能；
- 主库变更操作（如 DDL）统一走 pt-online-schema-change，避免锁表阻塞复制；
- 每次升级后保留旧链路至少 2 周，设置双写比对或 checksum 校验，确认数据收敛再下线；
- 把“主从切换演练”纳入季度运维动作，不依赖文档，用真实故障注入（如 kill -9 mysqld）检验流程有效性。
