MyCAT 不支持 MySQL 节点透明升级,必须人工分步操作:升级前需注释 schema.xml 中对应节点、重启 MyCAT;主库升级要处理认证插件兼容性(如改用 mysql_native_password);从库滚动升级需设 weight=0 并验证复制延迟;升级后须检查 show @@datasource 状态及直连验证复制一致性。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 默认不校验协议/语法兼容性:caching_sha2_password 插件,而 MyCAT 1.6.x 及更早版本仅支持 mysql_native_password;必须在升级后执行:ALTER USER 'mycat'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx';
druidparser,若升级后出现 ERROR 1000 (HY000): Unknown system variable 'transaction_isolation',说明 MySQL 8.0 的系统变量名变了,需在 server.xml 中显式配置:<property name="sqlExecuteTimeout">300</property> 并重启writeHost 上的写入,得靠运维提前切走流量或封禁应用写权限从库升级可滚动,但要注意复制延迟与 readHost 权重
滚动升级从库相对安全,但 MyCAT 不感知复制位点或延迟:readHost,升级前先在 schema.xml 中将其 weight 设为 0(如:<readHost host="slave1" url="..." weight="0"/>),再重启 MyCAT 生效show slave statusG 中 Seconds_Behind_Master 是否归零;MyCAT 不会等这个值,它只管连接通不通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
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