mysql在线升级需依托主从切换、mgr滚动升级或proxy灰度引流三类方案，核心是避免停机；须控制版本跨度、充分预演、禁用ddl并保留回滚能力。
MySQL 在线升级（不停机升级）是生产环境常见需求，核心思路是利用主从架构或高可用方案实现平滑过渡，避免服务中断。直接就地升级（如 yum upgrade 或二进制替换）风险极高，不推荐用于关键业务。
主从切换式升级（最常用、最稳妥）
适用于已部署主从复制的环境。通过将从库升级后再提升为新主库，原主库降级为从库并升级，最终完成双节点升级。
- 确保主从复制延迟接近 0，且 binlog_format = ROW、gtid_mode = ON（推荐），便于故障回切和一致性校验
- 先停止从库的 SQL 线程（STOP SLAVE SQL_THREAD），再关闭 mysqld 进程，用新版本 MySQL 二进制文件替换并更新 my.cnf（注意兼容参数，如 remove废弃选项 innodb_locks_unsafe_for_binlog）
- 启动新版本从库，执行 START SLAVE；确认 Seconds_Behind_Master = 0 且 SHOW SLAVE STATUS 中无错误
- 执行主从切换：应用层切流至新主库（需配合 VIP/Proxy 或 DNS 切换），原主库停写后降级为从库，再按同样流程升级
- 升级完成后运行 mysql_upgrade（仅 8.0.16+ 可省略，但建议仍执行以检查系统表兼容性）
使用 MySQL Router + 多副本滚动升级（适合 InnoDB Cluster / Group Replication）
基于 MGR 的集群可借助 MySQL Router 实现自动故障转移与读写分离，支持滚动升级单个节点。
- 逐个将集群中节点设置为 super_read_only=ON 并 STOP GROUP_REPLICATION，安全退出集群
- 停掉 mysqld，替换为新版二进制，调整配置（如 group_replication_group_name 必须保持一致，server_id 需唯一）
- 启动新版本实例，执行 START GROUP_REPLICATION；等待其同步完成并进入 ONLINE 状态
- 重复上述步骤升级其余节点；Router 会自动剔除不可用节点，流量始终落在健康节点上
- 升级全程无需人工干预主从关系，强一致性保障更好
Proxy 层灰度引流 + 双写验证（适合无法停写、对一致性要求极高的场景）
在应用与数据库之间引入 Proxy（如 MyCat、ShardingSphere-Proxy、Vitess），通过路由规则控制流量分发，实现“老库读写 + 新库只读 → 新库读写 + 老库只读 → 全量切新库”三阶段过渡。
- 提前部署同构新版本 MySQL 集群，并开启基于 GTID 的主从复制，与旧主库保持实时同步（可借助外部工具如 MaxScale 或自研 binlog 解析同步）
- Proxy 配置灰度规则：按用户 ID、订单号哈希或百分比分流，将部分请求写入新库，同时保留旧库全量写入（双写需注意幂等与冲突处理）
- 通过数据比对工具（如 pt-table-checksum + pt-table-sync）定期校验双库一致性；监控 QPS、慢查、连接数等指标是否异常
- 确认稳定运行 1–2 天后，逐步扩大新库流量占比，最终关闭旧库写入，完成切换
注意事项与避坑点
在线升级不是“一键操作”，细节决定成败：
- 版本跨度不宜过大：官方仅保证相邻大版本间兼容（如 5.7 → 8.0 可行，5.6 → 8.0 不支持），小版本建议逐级升级（5.7.30 → 5.7.40）
- 必须提前测试：在预发环境完整走一遍升级流程，包括备份恢复、权限迁移、字符集兼容性（尤其 utf8mb4）、SQL 模式变更（STRICT_TRANS_TABLES 默认启用影响插入行为）
- 禁用可能导致中断的操作：升级期间禁止 DDL（尤其是大表 ALTER），避免触发元数据锁阻塞；关闭 event_scheduler 防止定时任务干扰
- 保留回滚能力：升级前确保有可用的物理备份（xtrabackup）和 binlog 归档，记录旧版本 checksum，以便快速回退
