升级到 GreatSQL 8.4 后，主从复制管理脚本可以放心续命

一个让 DBA 头疼的升级难题

从 MySQL/GreatSQL 8.4 起，复制术语全面切换到Source/Replica标准命名，老一套Master/Slave语法被整体废弃——CHANGE MASTER TO、SHOW SLAVE STATUS、Slave_*状态变量……统统不再识别。这个改动也产生了一系列麻烦事：

  • 存量运维脚本直接报错,自动化复制管理流程集体失效;
  • 监控采集断数据,读不到复制延迟、IO/SQL 线程状态,监控面板一片空白;
  • 灾备切换、批量变更、数据同步脚本要大规模重构,改造成本极高;
  • 客户自研运维平台、中间件适配工作量巨大,直接拉长整个升级周期。

难道升级就只能把脚本全部推倒重写?

GreatSQL 8.4.4-5 的答案：新旧语法并行共存

GreatSQL 在8.4.4-5版本恢复了Master/Slave旧版复制兼容接口。核心一句话：

新旧两套语法完全并行、互不干扰,存量运维代码无需任何改造即可继续用。

它不改动底层复制同步逻辑,只在 SQL 解析、结果输出、错误提示这一层做双向映射适配:

  • 高频使用的Master/Slave复制管理语法完整恢复，新旧语法都能正常执行；
  • SHOW SLAVE STATUS、SHOW MASTER STATUS输出结果兼容旧字段名和字段顺序；
  • Slave_*系列全局状态变量保留，与新版Replica_*变量实时双向同步，数值完全一致；
  • 旧语法报错时，返回历史兼容错误码和Master/Slave风格提示文本；
  • 底层复用同一套复制执行逻辑，性能无损耗、数据一致性不受影响。

常用语法都能对上号

旧版 Master/Slave 语法新版 Source/Replica 语法
CHANGE MASTER TOCHANGE REPLICATION SOURCE TO
START SLAVE/STOP SLAVESTART REPLICA/STOP REPLICA
SHOW SLAVE STATUSSHOW REPLICA STATUS
SHOW MASTER STATUSSHOW BINARY LOG STATUS
SHOW SLAVE HOSTSSHOW REPLICAS
RESET MASTERRESET BINARY LOGS AND GTIDS

CHANGE MASTER TO里的MASTER_HOST、MASTER_PORT、MASTER_AUTO_POSITION、SSL/压缩/心跳等全套参数,也会自动映射到内部SOURCE_*参数,一个不落。

实际用起来什么样?

存量脚本原封不动,继续跑:

CHANGE MASTERTOMASTER_HOST='127.0.0.1',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='xxx',MASTER_AUTO_POSITION=1;STARTSLAVE;SHOWSLAVESTATUS\G

返回结果依然是Slave_IO_State、Master_Host这些老字段名,旧采集逻辑无缝衔接。

新写的脚本用标准Source/Replica语法照样不受影响,两套语法可以在同一个实例上交替使用。

落地价值

  • 升级成本大幅降低：跨大版本升级时，存量监控、自动化、灾备脚本无需重构；
  • 平滑过渡：升级后可长期并行使用，运维团队按自己的节奏分阶段迁移，没有强制改造窗口期；
  • 降低中断风险：复制监控不断流、自动化切换不失败；
  • 兼容第三方工具：自研平台、开源备份/同步工具、DTS 组件无需二次适配；
  • 多架构支持：普通多源复制、MGR 组复制、异步延迟复制均支持新旧语法混用。

小提示

  • 新旧语法底层是同一套配置，不能分别配置不同复制参数，以最后一条执行的语句为准；
  • 该兼容能力内核默认永久启用，无需额外开关；
  • 仅恢复主流高频复制接口,极小众的废弃内部接口不在恢复范围内。

想平滑升级到 GreatSQL 8.4 又不想重写一堆运维脚本?这个特性就是为你准备的。

特性详情见 GreatSQL 8.4.4-5 官方文档:
https://greatsql.cn/docs/8.4.4-5/5-enhance/5-2-ha-repl-interface-cmd.html