不能直接yum update mysql-server升级主库，因该包名已废弃且yum默认禁止跨主版本升级；必须显式切换仓库源、停从库复制、备份数据目录、替换二进制、调整参数并运行mysql_upgrade，再验证复制状态、gtid和binlog格式兼容性，最后处理sql_mode与系统表变更引发的权限及sql兼容问题。
为什么不能直接 yum update mysql-server 升级主库
CentOS 7 的 yum update mysql-server 会静默失败或跳过，因为该包名在 MySQL 官方仓库中已废弃，实际对应的是 mysql-community-server；更重要的是，Yum 默认只允许同源小版本更新（如 5.7.33 → 5.7.39），跨主版本（5.6 → 5.7）必须显式切换仓库源。若未禁用 mysql56-community、启用 mysql57-community，yum repolist enabled | grep mysql 输出为空或含多个源，升级后 mysqld 启动会报错 Table 'mysql.plugin' doesn't exist 或权限表损坏。
从库先行升级的关键操作顺序
主从混合版本运行（主 5.6 + 从 5.7）是可行的，但必须严格控制参数和流程，否则复制中断或数据不一致：
- 先停从库复制：
STOP SLAVE;，再执行SET GLOBAL read_only = ON;防止误写 - 备份从库数据目录：
tar -czf mysql56-slave-backup-$(date +%F).tar.gz /var/lib/mysql，不是仅 dump 数据——in-place 升级依赖原始文件结构 - 替换二进制：软链接指向新版本（如
ln -sf /usr/local/mysql-5.7.39-linux-glibc2.12-x86_64 /usr/local/mysql），并更新my.cnf中的basedir和plugin-dir - 启动前清理兼容性风险：注释或删除 5.6 特有参数（如
log-bin-trust-function-creators=1），添加 5.7 必需项（如sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION） - 以安全模式启动：
mysqld --defaults-file=/etc/my.cnf --skip-grant-tables --skip-networking &，再运行mysql_upgrade -u root -S /var/lib/mysql/mysql.sock，最后正常重启
主库切换前必须验证的三项复制状态
从库升级成功且同步无滞后后，切主前务必确认以下三点，否则切换瞬间可能丢事务或主键冲突：
-
SHOW SLAVE STATUS\G中Seconds_Behind_Master: 0且Slave_SQL_Running: Yes、Slave_IO_Running: Yes - 检查 GTID 是否启用一致：主库
SELECT @@gtid_mode;必须为ON，从库升级后默认开启 GTID，若主库未开，需先在主库执行SET GLOBAL gtid_mode = ON_PERMISSIVE;等步骤补全（否则CHANGE MASTER TO会失败） - 验证 binlog 格式兼容：
SELECT @@binlog_format;主从都必须为ROW，5.7 对MIXED支持减弱，混合格式下某些函数（如UUID()）可能导致复制中断
切主后最容易被忽略的权限与 SQL mode 兼容问题
主库升级完成、业务切流后，立刻出现“Field 'password_last_changed' doesn't have a default value”或“Expression #1 of ORDER BY clause is not in GROUP BY clause”这类报错，根本原因不是数据损坏，而是 5.7 默认启用的强约束未适配旧应用：
-
sql_mode变更：5.6 默认为空，5.7 默认含ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES等。不要全局清空，应在应用连接串中加?sessionVariables=sql_mode=''临时绕过，再逐条修复有问题的 SQL - 密码字段变更：5.7 新增
password_last_changed字段，若应用使用INSERT INTO mysql.user直写权限表，会因缺失该字段失败。改用CREATE USER或ALTER USER语句 - 系统表权限：升级后
mysql.db表结构变化，旧版客户端（如 MySQL 5.6 client）连接 5.7 server 执行SHOW GRANTS可能报错，需同步升级客户端工具或驱动
真正麻烦的不是升级动作本身，而是那些没写在日志里的隐式行为：比如 innodb_strict_mode 默认开启后，CREATE TABLE 中缺失 NOT NULL 的字段会被拒绝；又比如 show_compatibility_56=OFF 导致监控脚本里取不到 Slave_IO_State ——这些细节不会阻断启动，但会让业务在某个深夜突然报错。
