mysql 8.4 小版本滚动升级最稳妥，需验证三件事：确认所有节点同属 8.4.x 系列；检查 seconds_behind_master=0 且复制协议兼容；确保 gtid_mode=on 且 enforce_gtid_consistency=on。
MySQL 8.4 小版本滚动升级（如从 8.4.0 到 8.4.3）是生产环境最稳妥的升级方式，**无需停机、不中断复制、可逐台灰度实施**——前提是你的拓扑是主从或 MGR 集群，且所有节点运行的是同一 LTS 系列（即都是 8.4.x）。
滚动升级前必须验证的三件事
跳过这步，后面大概率卡在启动或同步阶段：
- 确认所有节点当前版本属于同一
8.4小版本系列：执行SELECT VERSION();，确保没有混用8.4.0和8.3.2这类跨系列节点（后者不支持滚动升级） - 检查复制协议兼容性：MySQL 8.4 默认启用
sha256_password认证，但旧从库若仍用mysql_native_password，升级后主库发来的 binlog event 可能被拒绝解析；运行SHOW SLAVE STATUS\G查看Seconds_Behind_Master是否稳定为0，非零值说明复制延迟未收敛，不能开始升级 - 确认
gtid_mode=ON且enforce_gtid_consistency=ON已启用——这是滚动升级的硬性前提，否则START SLAVE会报错ERROR 3094 (HY000): The slave is not configured or failed to start
停止从库并替换二进制文件的实操要点
滚动升级的核心动作发生在从库，顺序不能乱：
- 先在目标从库执行
STOP SLAVE;，再检查SHOW PROCESSLIST;确认没有Slave_IO_Running或Slave_SQL_Running进程残留 - 关闭 mysqld 服务时，**必须使用 systemd 命令而非直接 kill**：
sudo systemctl stop mysqld（RPM/DEB 安装）或sudo kill -15 $(cat /var/run/mysqld/mysqld.pid)（二进制安装），避免 InnoDB 未 clean shutdown 导致后续启动卡在InnoDB: Starting crash recovery - 替换二进制文件前，先备份原
bin目录：cp -r /usr/bin/mysql* /tmp/mysql-bin-backup-8.4.0；下载新包后解压，仅覆盖mysqld、mysql、mysqladmin等核心二进制，**不要覆盖my.cnf或数据目录** - 特别注意
libmysqlclient.so版本：如果应用直连数据库（如 PHP 的 mysqlnd），需确认新版本的 so 文件与旧客户端 ABI 兼容；不兼容时会出现undefined symbol: mysql_real_connect错误
启动新版本从库并校验同步状态
启动后不是万事大吉，关键校验点藏在日志和 SQL 层：
- 启动后立刻查错误日志：
sudo tail -n 50 /var/log/mysqld.log，重点找三类信息：Server version:（确认已加载新版本）、GTID相关 warning（如GTID state is inconsistent）、InnoDBrecovery 结束标记（InnoDB: FTS optimize thread exiting） - 执行
START SLAVE;后，用SHOW SLAVE STATUS\G检查：Seconds_Behind_Master: 0、Retrieved_Gtid_Set和Executed_Gtid_Set是否持续增长且差值为 0；若出现SQL_Delay非零或Until_Log_Pos被意外设置，说明 GTID 自动定位失败，需手动CHANGE MASTER TO ... GET_MASTER_PUBLIC_KEY=1 - 运行一次轻量级一致性校验：
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema NOT IN ('mysql','performance_schema','sys');对比主库结果，数值一致才说明表结构和数据未因升级损坏
主库升级时机与风险控制
主库升级是滚动终点，也是最大风险点，它不像从库可以回退：
- 必须等所有从库完成升级并稳定运行 ≥24 小时，且业务监控（QPS、慢查询数、连接数）无异常波动后再操作主库
- 主库升级前，强制刷盘并禁用快速关机：
SET GLOBAL innodb_fast_shutdown = 0;，然后FLUSH LOGS;，再SERVICE mysqld stop——这一步省略会导致升级后首次启动极慢，甚至触发崩溃恢复 - 升级后首次连接主库时，客户端可能报错
Authentication plugin 'caching_sha2_password' cannot be loaded，这是老客户端（如 MySQL 5.7 的 libmysqlclient）不识别新默认插件所致，临时方案是执行ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'xxx';，长期应升级客户端驱动
小版本滚动升级真正的难点不在命令执行，而在于 GTID 状态的隐式漂移和客户端认证链的断裂。每次升级后，务必用真实业务 SQL（尤其是含 XA、存储过程、JSON 函数的语句）跑一轮 smoke test，而不是只依赖 SELECT 1。
