先升级从库再切换主库，确保数据一致性。逐步升级从库并验证复制状态，确认无延迟后选择已升级从库作为新主库，调整拓扑结构，最后启用GTID和半同步提升可靠性。
在 MySQL 中升级主从复制架构通常是为了提升性能、增强高可用性或支持新功能。这个过程需要谨慎操作，避免数据丢失或服务中断。核心思路是保证数据一致性的同时，逐步将现有架构迁移到更高版本或更合理的拓扑结构。
评估当前架构与目标版本兼容性
在开始升级前，必须确认当前 MySQL 版本与目标版本之间的复制兼容性。MySQL 官方文档明确列出了不同版本间主从复制的支持情况。
- 主库的版本不能低于从库版本（推荐主从同时升级或先升从库）
- 跨大版本升级（如 5.7 → 8.0）需注意系统表结构、认证插件（mysql_native_password vs caching_sha2_password）、默认字符集等变化
- 检查 binlog 格式是否兼容（建议使用 ROW 模式以提高兼容性和安全性）
可通过 SELECT VERSION(); 查看当前版本，并查阅官方升级路径说明。
逐步升级从库并验证复制状态
最安全的方式是逐个升级从库，确保每个节点稳定后再继续。
- 停止从库复制：STOP SLAVE;
- 备份从库数据（即使有主库也要做）
- 按照官方升级流程更新 MySQL 软件（使用包管理器或二进制替换）
- 启动 MySQL 并运行 mysql_upgrade（8.0 之后自动集成到启动流程）
- 重启从库并恢复复制：START SLAVE;
- 检查复制状态：SHOW SLAVE STATUS\G，确认 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes，且无错误
观察一段时间，确认无延迟、无报错后再升级下一个从库。
word报告自动生成神器
下载
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
切换主库并调整拓扑结构（可选）
如果需要将主库也升级到新版本，可以在所有从库升级完成后进行主从切换。
- 选择一个已升级的从库作为新主库候选
- 停止原主库写入（或进入只读模式）并等待所有从库追平数据
- 在新主库上执行 STOP SLAVE; RESET MASTER;（视情况而定）
- 将应用指向新主库，并将旧主库降级为从库接入新架构
- 更新其他从库的复制源（CHANGE MASTER TO MASTER_HOST='new_master'）
此过程也可借助 GTID 复制简化 failover 操作，前提是原环境已启用 GTID。
启用 GTID 或半同步提升架构可靠性
升级过程中可考虑引入更现代的复制特性。
- 启用 GTID：设置 gtid_mode=ON，enforce_gtid_consistency=ON，便于故障转移和拓扑变更
- 配置半同步复制（semi-sync）：使用插件 rpl_semi_sync_master 和 rpl_semi_sync_slave，确保至少一个从库接收到日志
- 监控复制延迟、IO/SQL 线程状态，使用 pt-heartbeat 等工具实现精准延迟检测
这些改进能显著提升主从架构的稳定性和可维护性。
基本上就这些。关键是按步骤操作，每一步都验证状态，避免跳跃式升级。只要提前测试、备份完整，主从架构的升级是可以平稳完成的。
