my-010020错误本质是升级中断导致的数据字典不一致状态，非单纯损坏；需先停全部实例，保留grastate.dat和auto.cnf，清理mysql_upgrade_info等临时文件，再核对shell、router与server版本及集群参数一致性。
升级失败不是“集群坏了”，而是版本、配置、状态三者没对齐——直接重启或重跑 cluster.upgrade() 通常会让问题更隐蔽。
查日志前先确认 MySQL Router 和 MySQL Shell 版本是否匹配
Cluster 升级依赖 MySQL Shell 控制流程，而 MySQL Router 负责客户端路由。如果三者版本错位（比如用 8.0.33 的 Shell 升级 8.0.35 的 Server），cluster.upgrade() 可能卡在“等待实例就绪”却无报错。
- 必须用
mysqlsh --version和mysqlrouter --version核对：二者主版本号（如 8.0）需与目标 Server 版本一致，次版本号建议 ≥ Server（Router 8.0.34 可管 Server 8.0.33，反之不行） - Shell 连接集群后执行
cluster.status()，重点看"status": "OK"是否全为 true；若有实例显示"status": "UNREACHABLE"或"mode": "ERROR"，说明底层通信已中断，此时 upgrade 必失败 - Router 若未重启或未重 bootstrap，仍指向旧拓扑，会导致新 Primary 不被识别——哪怕 Server 升级成功，应用也连不到正确节点
MY-010020 Data Dictionary initialization failed 是典型信号
这个错误不是数据字典损坏，而是升级流程中途断开后残留的不一致状态。InnoDB Cluster 的元数据升级和单实例不同，它要求所有实例在 upgrade 前达成一致快照，任一节点卡住就会触发全局回滚并留下半初始化痕迹。
- 不要手动删
ibdata1或ib_logfile*——Cluster 实例的 data 目录受 Group Replication 日志保护，硬删会破坏 GTID 一致性 - 先停掉全部实例：用
mysqlsh连上任意节点，执行cluster.dissolve({force:true})（仅当集群已不可恢复时），再逐个停止 mysqld 进程 - 检查每个实例的
mysqld.log，定位最早出现MY-010020的那台——它通常是第一个尝试升级但失败的 Primary，其datadir下可能残留mysql_upgrade_info文件或未完成的dd_upgrade_*.sql临时脚本 - 清理方式：保留
grastate.dat和auto.cnf（确保 UUID 不变），删除mysql_upgrade_info、ibtmp1、所有#sql-*.ibd临时表文件，清空tmp目录
升级后 cluster.status() 显示部分实例 offline
这往往不是网络问题，而是新版本默认启用了 stricter 的安全策略，比如 require_row_format 或强制校验 group_replication_ssl_mode，导致旧配置的实例拒绝加入。
- 登录离线实例，执行
SELECT * FROM performance_schema.replication_group_members;，若MEMBER_STATE是OFFLINE或RECOVERING，说明 Group Replication 插件未启动或参数不兼容 - 检查该实例的
my.cnf，确认以下三项必须显式设置且值匹配：-
group_replication_ssl_mode = REQUIRED（8.0.27+ 默认值，旧版常为DISABLED） -
binlog_checksum = CRC32（必须与集群其他节点一致，否则同步中断） -
enforce_gtid_consistency = ON和gtid_mode = ON（升级后强制启用，旧配置若为 OFF 会拒绝启动）
-
- 若实例仍无法上线，临时加
--skip-slave-start启动，然后在 mysqlsh 中执行cluster.rejoinInstance("user@host:port")，比直接 restart 更可靠
升级完成但应用连接超时或写入失败
Router 没自动刷新路由缓存是最常见原因。它不会感知到 upgrade 后 Primary 角色变更，仍把流量发给旧地址。
- 执行
mysqlrouter --bootstrap user@primary-host:3306 --force强制重生成配置，注意primary-host必须是 upgrade 后真正的 Primary（查cluster.status().defaultReplicaSet.primary） - 检查生成的
mysqlrouter.conf中[routing]段的destinations是否包含全部实例 IP 和端口，且routing_strategy设为first-available或round-robin-with-fallback - Router 日志里若出现
Failed to connect to 'xxx' (Connection refused)，说明它还在尝试连已下线的旧实例——必须删掉旧.mysqlrouter目录再 bootstrap，不能只改 conf
真正麻烦的从来不是命令输错，而是 upgrade 过程中某台实例悄悄进入了 RECOVERING 状态却没报错，等你发现时 GTID 已跳变、Binlog 位置错位——这种问题只能靠 SHOW BINLOG EVENTS 对比各节点 first_event_timestamp，没有捷径。
