MySQL 8.0 复制：Source/Replica 与 Master/Slave 的桥接

重命名

MySQL 8.0.22 引入了一个重大的术语变更：复制命令和输出列中的 Master 和 Slave 术语被替换为 Source 和 Replica。

这不仅仅是一个外观上的改变。具体来说：

• SHOW SLAVE STATUS 变为 SHOW REPLICA STATUS
• CHANGE MASTER TO 变为 CHANGE REPLICATION SOURCE TO
• 输出中的 Master_Host 列变为 Source_Host
• Slave_IO_Running 变为 Replica_IO_Running
• Slave_SQL_Running 变为 Replica_SQL_Running
• Seconds_Behind_Master 变为 Seconds_Behind_Source

大约三十个列都是如此。

MySQL 8.0 保持了向后兼容性：旧命令仍然有效（带弃用警告）。但 MySQL 8.4 开始移除旧别名。而 MariaDB 方面则保持了历史术语。

监控工具面临的问题

任何解析 SHOW SLAVE STATUS / SHOW REPLICA STATUS 输出的工具现在必须根据服务器版本处理两套列名：

问题是双重的：

1. 现有代码 到处使用旧列名。数百处引用 $row['Master_Host'] 或 $row['Slave_IO_Running']。
2. 基础设施是混合的：MariaDB 10.6 和 10.11、即将终止生命周期的 MySQL 5.7、MySQL 8.0、新部署的 MySQL 8.4。全部在同一个 PmaControl 中。

简单方案（以及为什么它行不通）

第一个想法：检测版本并使用正确的列名。

// 不要这样做
if ($version >= '8.0.22') {
    $host = $row['Source_Host'];
    $io_running = $row['Replica_IO_Running'];
} else {
    $host = $row['Master_Host'];
    $io_running = $row['Slave_IO_Running'];
}

这种模式在维护上是灾难性的。代码中每个读取复制字段的地方都必须重复。有 30 个列和数十个代码位置，你最终会有数百个条件判断。

而当 MySQL 9.0 添加新的别名时呢？代码再翻三倍？

Glial 的方法：驱动层的双向别名

在 Glial 框架（提供 PmaControl 的 MySQL 访问层）中实现的解决方案更加优雅：在驱动层进行双向别名。

当 Glial 驱动执行 SHOW REPLICA STATUS（或 SHOW SLAVE STATUS）时，它通过为每一列添加两个名称来丰富结果：

// 在 Glial 的 MySQL 驱动中
$replication_aliases = [
    'Master_Host'          => 'Source_Host',
    'Master_User'          => 'Source_User',
    'Master_Port'          => 'Source_Port',
    'Master_Log_File'      => 'Source_Log_File',
    'Read_Master_Log_Pos'  => 'Read_Source_Log_Pos',
    'Slave_IO_Running'     => 'Replica_IO_Running',
    'Slave_SQL_Running'    => 'Replica_SQL_Running',
    'Slave_IO_State'       => 'Replica_IO_State',
    'Seconds_Behind_Master'=> 'Seconds_Behind_Source',
    'Exec_Master_Log_Pos'  => 'Exec_Source_Log_Pos',
    // ... 所有配对
];

// 获取结果后
foreach ($replication_aliases as $old => $new) {
    if (isset($row[$old]) && !isset($row[$new])) {
        $row[$new] = $row[$old];
    }
    if (isset($row[$new]) && !isset($row[$old])) {
        $row[$old] = $row[$new];
    }
}

结果：消费代码可以互换使用旧名称或新名称。无论服务器是 MariaDB 10.6、MySQL 5.7、MySQL 8.0 还是 MySQL 8.4，两个名称在结果中始终存在。

这种方法的优势

1. 现有代码零修改

PmaControl 中数百处对 $row['Master_Host'] 的引用继续工作。不需要代码迁移。

2. 新代码可以使用新术语

编写新代码的开发者现在就可以使用 $row['Source_Host']。当旧代码逐步重构时，过渡将是透明的。

3. 单一维护点

别名只定义一次，在驱动中。如果 MySQL 9.0 添加新字段或重命名其他列，你只需要扩展别名数组。

4. 兼容两种 SHOW 命令

驱动首先尝试 SHOW REPLICA STATUS。如果命令失败（MySQL 5.7、MariaDB），它回退到 SHOW SLAVE STATUS。在两种情况下，结果都包含两套名称。

try {
    $result = $db->query('SHOW REPLICA STATUS');
} catch (Exception $e) {
    $result = $db->query('SHOW SLAVE STATUS');
}
// 在所有情况下，$result 都包含 Master_Host 和 Source_Host

多源情况

MySQL 8.0 支持多源复制（多个通道）。SHOW REPLICA STATUS 命令会返回多行，每个通道一行。别名逐行应用。

MariaDB 也支持多源复制，但语法不同（SHOW SLAVE 'channel_name' STATUS 或 SHOW ALL SLAVES STATUS）。Glial 驱动规范化了这些差异，使 PmaControl 接收到统一的格式。

对 PmaControl 的影响

得益于 Glial 驱动中的别名，PmaControl 透明地处理：

• MariaDB 10.6 / 10.11：Master/Slave 术语，SHOW SLAVE STATUS
• MySQL 5.7：Master/Slave 术语，SHOW SLAVE STATUS
• MySQL 8.0：Source/Replica 术语，SHOW REPLICA STATUS（带旧版回退）
• MySQL 8.4：仅 Source/Replica 术语，SHOW REPLICA STATUS

PmaControl 界面统一显示复制信息，无论服务器版本如何。复制仪表盘在列中显示 Source_Host，但内部查询同时使用两套名称。

命令也是如此

重命名不仅影响输出列。SQL 命令本身也被重命名了：

PmaControl 使用相同的方法：尝试新命令，回退到旧命令。

对你自己工具的建议

如果你维护着解析复制输出的脚本或工具：

1. 不要使用基于版本的条件判断 ——它们脆弱且不可扩展
2. 在尽可能低的层级实现双向别名（驱动、抽象层）
3. 用新术语编写新代码 —— Source/Replica
4. 在所有 4 个主要版本上测试：MariaDB 10.x、MySQL 5.7、MySQL 8.0、MySQL 8.4
5. 为 MySQL 9.x 做准备 ——旧别名可能完全消失

结论

MySQL 8.0 中从 Master/Slave 到 Source/Replica 的重命名是一个看似简单的变更，但它可能破坏任何解析复制输出的监控、备份或编排工具。

干净的解决方案是在驱动层进行双向别名：一次实现，消费代码零修改，从 MariaDB 10.x 到 MySQL 8.4 完全兼容。

这就是 Glial 框架所做的，也是 PmaControl 能够在不需要特定版本配置的情况下监控混合 MariaDB / MySQL 基础设施的原因。