升级到 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 风格提示文本；
• 底层复用同一套复制执行逻辑，性能无损耗、数据一致性不受影响。

常用语法都能对上号

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

实际用起来什么样?

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

CHANGE MASTER TO
  MASTER_HOST='127.0.0.1',
  MASTER_PORT=3306,
  MASTER_USER='repl',
  MASTER_PASSWORD='xxx',
  MASTER_AUTO_POSITION=1;

START SLAVE;
SHOW SLAVE STATUS\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