MyCAT 本身并不具备对 MySQL 节点进行“透明升级”的能力——所谓透明升级，通常指应用连接 MyCAT 的地址保持不变，而底层 MySQL 实例的升级过程必须由人工介入、分步验证，否则极易引发连接中断、路由错乱、事务回滚失败等严重故障。简而言之，如果你期望 MyCAT 能自动感知后端 MySQL 的版本变化并实现平滑切换，大概率会遭遇问题。
MySQL 节点升级前，必须先停掉 MyCAT 对该节点的流量
MyCAT 不会自动感知后端 MySQL 的版本变更或健康状态突变。升级前必须手动干预，并严格按照以下步骤操作：
- 在
schema.xml中临时注释或移除待升级节点的readHost或writeHost声明——注意，仅修改 IP 或端口无效，必须彻底摘除节点配置。 - 执行
mycat reload不会生效：MyCAT 的热加载仅支持部分rule.xml变更，修改schema.xml后必须执行mycat restart才能生效。 - 如果使用了
switchType="-1"（关闭自动切换），MyCAT 不会尝试重连失败节点，但也不会主动剔除它；需要人工确认连接池已清空，否则旧连接仍会残留在池中。 - 升级完成后，使用
mysql -h127.0.0.1 -P8066 -uroot -p连接 MyCAT，再执行show @@datasource查看节点状态是否为idle或ok，而非init或error。
主库升级要特别处理事务与 binlog 兼容性
从 MySQL 5.7 升级到 8.0 是常见场景，但 MyCAT 默认不校验协议和语法兼容性，许多潜在问题隐藏在细节中：
- 8.0 默认启用
caching_sha2_password认证插件，而 MyCAT 1.6.x 及更早版本仅支持mysql_native_password。升级后必须执行：ALTER USER 'mycat'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; - MyCAT 解析 SQL 依赖
druidparser，如果升级后出现ERROR 1000 (HY000): Unknown system variable 'transaction_isolation'，说明 MySQL 8.0 的系统变量名已变更，需在server.xml中显式配置：300 - 主库升级期间，所有写请求必须阻断。MyCAT 不会自动暂停
writeHost上的写入，运维人员必须提前切换流量或封禁应用写权限，否则升级过程中写请求会直接报错或丢失。
从库升级可滚动，但要注意复制延迟与 readHost 权重
从库滚动升级相对安全，但 MyCAT 不感知复制位点或延迟，需要手动控制节奏：
- 每次只升级一个
readHost，升级前先在schema.xml中将其weight设为0（例如： - 升级后检查
show sla ve status\G中Seconds_Behind_Master是否归零；MyCAT 不会等待该值，只关心连接是否通畅——延迟未消除就对外提供读服务，会导致数据不一致。 - 如果从库启用了 GTID，而主库未开启，MyCAT 路由层无法识别 GTID 模式差异，可能导致
SELECT被错误发送到新从库并报错ERROR 1236 (HY000): Could not open log file。 - 多个
readHost权重总和不为 100 也没有影响，MyCAT 按数值比例分配请求；但权重设为负数或非数字会导致启动失败，需避免手误。
升级后最易被忽略的三件事
MyCAT 启动时一次性加载 schema.xml，升级完 MySQL 实例后，很多人以为“能连上就万事大吉”，实际上并非如此：
show @@heartbeat显示心跳成功 ≠ 复制正常。必须单独直连每个从库执行SELECT @@hostname, @@server_id并比对show sla ve status，确认复制链路完整。- MyCAT 日志中
WrapperSimpleApp报ja va.net.ConnectException: Connection refused往往是 MySQL 服务未启动，而非端口冲突——不要急于修改配置，先执行systemctl status mysqld查看服务状态。 - 升级后首次连接可能卡在
handshake阶段：JDK 版本（如 JDK 17）与 MySQL 8.0+ 的 TLS 握手不兼容，需在mycat/conf/wrapper.conf中添加：wrapper.ja va.additional.10=-Djdk.tls.client.protocols=TLSv1.2。
