mysql不支持真正在线升级进程，零停机本质靠主从切换实现，前提是严格满足复制兼容性：5.7→8.0可行但需提前调整sql_mode等配置，8.0→5.7或5.6→8.0均不被官方支持；必须验证gtid、binlog_format、认证插件及lower_case_table_names等关键配置一致性，并通过show slave status等确认同步状态。

不能真正“在线”升级 MySQL 进程本身，所谓零停机，本质是靠主从切换把流量从旧版本实例切到已同步好的新版本实例——切换窗口可压至秒级，但必须满足复制兼容性前提。

主从复制升级前必须验证 replication compatibility

MySQL 不支持反向或任意跨版本复制。例如：

• 5.7 → 8.0 可行，但需提前在 5.7 主库关闭 sql_mode 中已移除的项（如 NO_AUTO_CREATE_USER）
• 8.0 → 5.7 不可行：8.0 的 binlog event 类型（如 ANONYMOUS_GTID_LOG_EVENT）5.7 无法解析，启动从库即报错 Unknown binlog event type
• 5.6 → 8.0 不被官方支持：中间缺失 5.7 兼容层，GTID、密码认证插件、数据字典结构差异都会导致同步中断或数据损坏

验证方式：在目标从库上启动 mysqld 后执行 SHOW SLAVE STATUS\G，重点观察 Seconds_Behind_Master 是否持续为 0，以及 Slave_SQL_Running_State 是否稳定为 Slave has read all relay log。

搭建新版本从库时的关键配置差异

新版本（如 8.0）从库不能直接复用旧版（如 5.7）的配置模板，以下几项必须显式校准：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• binlog_format 必须设为 ROW：5.7 默认是 STATEMENT，而 8.0 对 STATEMENT 复制支持更弱，易出现函数/UUID/时间相关不一致
• enforce_gtid_consistency=ON 和 gtid_mode=ON 强烈建议启用：避免切换时因 binlog position 漂移导致数据丢失；若原主库未开 GTID，需先升级主库开 GTID（需全量锁表一次），再配从库
• default_authentication_plugin=mysql_native_password（8.0.4+ 默认是 caching_sha2_password）：否则应用连接旧账号会报 Client does not support authentication protocol
• lower_case_table_names=1 必须与主库严格一致：否则表名大小写敏感差异会导致 Table doesn't exist 错误，尤其在 Windows→Linux 迁移时极易踩坑

切换流量时最容易被忽略的三个动作

主从角色切换不是只执行 STOP SLAVE; CHANGE MASTER TO ...; START SLAVE; 就完事。真实生产中失败多发生在收尾环节：

• 切主前，必须在旧主库上执行 FLUSH TABLES WITH READ LOCK; 并记录 SHOW MASTER STATUS 输出——这是确保从库追平最后一条事务的唯一可靠依据，仅靠 Seconds_Behind_Master = 0 不够（可能 SQL 线程卡在锁等待）
• 新主库启动后，立刻执行 SELECT @@read_only; 确认值为 OFF；若仍为 ON，写请求会被拒绝，现象是应用报 The MySQL server is running with the --read-only option
• 切流后，必须验证新主库的 gtid_executed 是否包含旧主库最后的 GTID（SELECT @@gtid_executed; 对比），否则后续再加从库会因 GTID gap 导致同步失败

为什么 pt-online-schema-change 或 gh-ost 不能替代主从升级

这两款工具只解决 DDL 锁表问题，和 MySQL 服务进程升级完全无关：

• 它们不替换 mysqld 二进制文件，也不触碰 mysql 系统库表结构（如 mysql.user、mysql.role_edges）
• 若在 5.7 主库用 gh-ost 迁移完一张业务表，再直接把该实例升级到 8.0 —— 启动时会因 mysql.user 表字段缺失（如 password_last_changed）而崩溃，报错 Table 'mysql.user' doesn't have column 'password_last_changed'
• 跳过 mysql_upgrade 直接启动 8.0 读取 5.7 数据目录，必然失败，错误信息是 Table 'mysql.role_edges' doesn't exist（该表 8.0 新增，5.7 无对应结构）

真正的零停机升级，核心不在工具多炫酷，而在对版本边界、系统表演进、复制机制的理解是否扎实——漏掉任一隐性约束，切换瞬间就可能变成故障现场。