必须先查清集群类型和节点角色再升级：mgr查replication_group_members，主从查master/slave status，pxc查wsrep状态；大版本需兼容性预检，滚动升级须从节点开始并保持主从链路可用，且提前验证故障转移。
先查清集群类型和节点角色，再动手
MySQL集群不是统一架构，MGR、InnoDB Cluster、Percona XtraDB Cluster、主从+Proxy方案的升级路径完全不同——直接套用别人步骤，大概率卡在第一步。必须登录每个节点执行：SELECT VERSION(), @@hostname, @@server_id;，再根据集群类型补查关键状态：
- MGR 集群：运行
SELECT * FROM performance_schema.replication_group_members;，确认MEMBER_STATE是ONLINE还是UNREACHABLE，VIEW_ID是否一致 - 主从复制集群：主库跑
SHOW MASTER STATUS;，从库跑SHOW SLAVE STATUS\G，重点看Seconds_Behind_Master是否为 0、SQL_THREAD_STATE是否是Slave has read all relay log - Percona XtraDB Cluster：查
SHOW STATUS LIKE 'wsrep_cluster_size';和wsrep_local_state_comment，确保不是Joiner或Donor状态才可升级
漏掉这步，可能把正在做 IST 同步的节点当普通从库停掉，触发 SST 导致数小时不可用。
大版本升级必须走兼容性预检，别信“一键升级”
MySQL 5.7 → 8.0 不支持跳过 5.7 中间态；8.0.16+ 已弃用 mysql_upgrade，但升级前仍要人工验证兼容性，否则启动失败或数据字典损坏。
- 用新版本二进制启动旧数据目录时加参数：
mysqld --datadir=/var/lib/mysql --basedir=/usr/local/mysql-8.0 --upgrade=NONE --skip-networking，观察错误日志是否报Data Dictionary upgrade required或插件加载失败 - 禁用已移除功能：如配置里还留着
sql_mode=NO_AUTO_CREATE_USER，8.0 启动直接拒绝；密码插件从mysql_native_password切到caching_sha2_password，应用连接字符串没加?allowPublicKeyRetrieval=true&useSSL=false就会连不上 - 字符集默认变为
utf8mb4_0900_ai_ci，若业务依赖旧排序规则（比如用utf8mb4_unicode_ci做唯一索引），升级后可能因 collation 变更导致重复键冲突
滚动升级顺序不能错：从节点→主节点，且每次只动一个
核心原则就一条：永远保证至少一个完整可用的主从链路在线。升级顺序错了，服务就断了。
- 主从架构：先停一个从库的复制（
STOP SLAVE;），等Relay_Master_Log_File和Exec_Master_Log_Pos追平主库File/Position后再关 mysqld；替换二进制、改配置（注意plugin_dir路径）、启动；成功后再START SLAVE;并验证Seconds_Behind_Master = 0 - MGR 单主模式：先对所有
SECONDARY节点执行STOP GROUP_REPLICATION;→ 替换 → 启动 →START GROUP_REPLICATION;；全部 SECONDARY ONLINE 后，再在原 PRIMARY 上执行SET GLOBAL group_replication_bootstrap_group=ON;临时引导，然后STOP GROUP_REPLICATION;再升级它 - Percona XtraDB Cluster：直接
systemctl restart mysql即可，节点会自动尝试 IST；但如果gcache.size太小或重启间隔太久，会降级为 SST——务必提前调大gcache.size（建议 ≥ 1GB）并控制单节点重启窗口在 5 分钟内
故障转移不是自动发生的，得提前验证切换链路
升级过程中最怕主节点崩在半路，结果备用节点因为配置没对齐、GTID 不一致或权限缺失，根本升不起来。升级前必须实测一次手动故障转移。
- MGR：在非主节点上执行
SELECT group_replication_set_as_primary('xxx-uuid');（需先SET SQL_LOG_BIN=0;），确认能秒级切主且写入正常 - MHA：用
masterha_check_repl检查复制延迟，再用masterha_stop+masterha_manager模拟一次 failover，看日志里有没有All other slaves should start replication from here - 主从+ProxySQL：检查
mysql_servers表中status字段是否随SELECT * FROM monitor.mysql_server_ping_log ORDER BY time_start_us DESC LIMIT 5;实时更新，避免 ProxySQL 还把流量发给已宕机节点
很多团队卡在最后一步——以为升级完就稳了，结果真实故障时发现从库的 read_only=0 没开、或者监控脚本里写的还是旧端口，切换过去没人能连。
