MyCAT 不支持 MySQL 节点透明升级，必须人工分步操作：升级前需注释 schema.xml 中对应节点、重启 MyCAT；主库升级要处理认证插件兼容性（如改用 mysql_native_password）；从库滚动升级需设 weight=0 并验证复制延迟；升级后须检查 show @@datasource 状态及直连验证复制一致性。
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中显式配置：<property name="sqlExecuteTimeout">300</property>并重启 - 主库升级期间，所有写请求必须阻断；MyCAT 不会自动暂停
writeHost上的写入，得靠运维提前切走流量或封禁应用写权限
从库升级可滚动，但要注意复制延迟与 readHost 权重
滚动升级从库相对安全，但 MyCAT 不感知复制位点或延迟：- 每次只升级一个
readHost，升级前先在schema.xml中将其weight设为0（如：<readHost host="slave1" url="..." weight="0"/>），再重启 MyCAT 生效 - 升级后检查
show slave 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 slave status - MyCAT 日志中
WrapperSimpleApp报java.net.ConnectException: Connection refused往往是 MySQL 服务没起来，不是端口冲突——别急着改配置，先systemctl status mysqld - 升级后首次连接可能卡在
handshake阶段：JDK 版本（如 JDK 17）与 MySQL 8.0+ 的 TLS 握手不兼容，需在mycat/conf/wrapper.conf中添加：wrapper.java.additional.10=-Djdk.tls.client.protocols=TLSv1.2
