升级到 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 TO	CHANGE REPLICATION SOURCE TO
START SLAVE / STOP SLAVE	START REPLICA / STOP REPLICA
SHOW SLAVE STATUS	SHOW REPLICA STATUS
SHOW MASTER STATUS	SHOW BINARY LOG STATUS
SHOW SLAVE HOSTS	SHOW REPLICAS
RESET MASTER	RESET BINARY LOGS AND GTIDS

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