MyCAT分库分表中间件MySQL节点透明升级指南
MyCAT不提供MySQL节点透明升级能力,需人工干预分步操作。升级前必须停流量、修改schema xml并重启MyCAT。主库升级需处理认证插件与系统变量兼容性并阻断写请求;从库滚动升级需调整权重并确认复制延迟归零。升级后需检查心跳、复制状态及TLS握手配置。
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(例如:),再重启 MyCAT 生效。 - 升级后检查
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。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
自增主键值从何而来?深入理解原理,告别只会auto_increment
KingbaseES推荐使用serial、bigserial、显式sequence或identity列实现自增主键。serial创建integer并关联序列,bigserial对应bigint;显式sequence可自定义起始值等参数;identity有generatedbydefault(允许指定值)与always(禁止)两种模式。
Linux下瀚高数据库授权文件过期及替换解决方案
在银河麒麟系统下,瀚高数据库hgdb-4 5试用授权20天到期后需替换正式授权文件。正确操作:停止服务,备份旧文件,将授权文件复制到 opt highgo hgdb-4 5 etc lic 并命名为hgdb lic,设置权限600和属主highgo:highgo,再启动服务。禁止直接修改data目录下的license info文件。
Oracle BLOB实时同步的5大技术挑战与难点解析
OracleBLOB实时同步面临分片组装、多列隔离、长事务跨窗口、事务回滚及大对象资源控制等技术挑战,必须在日志中精确还原完整字段值,才能保证源端与目标端数据完全一致,这对同步系统的稳健性提出了高要求。
MySQL禁用redo日志导致全备失败
MySQL全量备份失败是由于数据定义语言操作触发排序索引构建,禁用重做日志导致XtraBackup无法获取一致性备份。测试验证表明,优化表语句即使无数据也会触发该问题。根本原因在于排序索引构建过程跳过了重做日志记录,破坏了备份的一致性。
Kafka架构图优化与改进的全面详细步骤与实践指南
Kafka作为实时数据流处理的核心中间件,其底层架构虽已相当成熟,但在实际生产环境中,要充分发挥其性能潜力,仍需落实到具体的调优与架构改造上。核心目标可归纳为三点:如何承载更高的吞吐量、如何保障数据不丢失、以及故障发生时如何快速恢复。本文将从这几个关键方向出发,深入探讨如何真正榨干Kafka集群的性
- 热门数据榜
相关攻略
2026-07-25 22:22
2026-07-25 22:22
2026-07-25 22:22
2026-07-25 20:35
2026-07-25 20:35
2026-07-25 20:35
2026-07-25 20:35
2026-07-25 19:38
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程

