多源复制：多个主节点，一个副本

多源复制允许单个副本服务器同时从多个主节点接收数据。每个主节点连接都是一个独立的通道（channel），拥有自己的 IO 线程、SQL 线程和独立的复制状态。

这是一种强大的架构模式，适用于：

数据整合：将多个业务数据库聚合到一个分析副本上
迁移：在过渡期间同时从旧系统和新系统接收数据
数据仓库：从多个 MariaDB / MySQL 数据源向数据仓库供数

在我们之前关于 MySQL 8.4 多源复制的文章中，我们介绍了配置方法。本文我们将聚焦于监控：PmaControl 如何检测、展示和监控这些多通道复制。

快速配置（回顾）

MariaDB

MariaDB 从 10.0 版本起原生支持多源复制：

-- 通道 1：客户数据库
CHANGE MASTER 'channel_clients' TO
  MASTER_HOST = '10.0.1.1',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'secret',
  MASTER_USE_GTID = slave_pos;
START SLAVE 'channel_clients';

-- 通道 2：订单数据库
CHANGE MASTER 'channel_orders' TO
  MASTER_HOST = '10.0.2.1',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'secret',
  MASTER_USE_GTID = slave_pos;
START SLAVE 'channel_orders';

MySQL 8.0+

MySQL 使用 FOR CHANNEL 子句：

-- 通道 1
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '10.0.1.1',
  SOURCE_USER = 'repl',
  SOURCE_PASSWORD = 'secret',
  SOURCE_AUTO_POSITION = 1
  FOR CHANNEL 'channel_clients';
START REPLICA FOR CHANNEL 'channel_clients';

-- 通道 2
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '10.0.2.1',
  SOURCE_USER = 'repl',
  SOURCE_PASSWORD = 'secret',
  SOURCE_AUTO_POSITION = 1
  FOR CHANNEL 'channel_orders';
START REPLICA FOR CHANNEL 'channel_orders';

PmaControl 如何检测多源复制

检测查询

当 Aspirateur（采集器）收集复制数据时，它会执行：

SHOW SLAVE STATUS;
-- 或在 MySQL 8.0+ 中：
SHOW REPLICA STATUS;

在经典的单主复制中，此查询返回一行数据。在多源复制中，它返回每个通道一行数据。

当 SHOW SLAVE STATUS 返回多行时，PmaControl 会自动检测多源复制。PmaControl 端无需任何特殊配置。

内部存储

每个通道作为独立的复制条目存储在时间序列表中。通道名称被保留并用作区分标识：

ts_value_general_json:
  server_id = 42
  variable  = slave_status
  channel   = 'channel_clients'
  value     = { "Slave_IO_Running": "Yes", "Seconds_Behind_Master": 3, ... }

  server_id = 42
  variable  = slave_status
  channel   = 'channel_orders'
  value     = { "Slave_IO_Running": "Yes", "Seconds_Behind_Master": 0, ... }

多源复制下的从库页面

当 PmaControl 在某台服务器上检测到多个通道时，从库页面会独立显示每个通道。具体来说：

每个通道一个区块

每个通道有自己独立的区块，包含：

通道名称：显示在区块标题中（例如：channel_clients）
IO/SQL 状态：该通道专属的 Slave_IO_Running 和 Slave_SQL_Running 指标
延迟：该通道特定的 Seconds_Behind_Master
GTID：该通道专属的 GTID 状态
最近错误：该通道的 Last_SQL_Error

每个通道独立的延迟图表

每个通道都有自己独立的 Chart.js 图表，展示 5 天内的延迟历史。图表在页面上垂直排列。

这使得直观对比成为可能：如果 channel_clients 的延迟稳定在 0 秒，而 channel_orders 显示反复出现的延迟峰值，那么问题显然定位在订单主节点上。

每个通道的健康状态条

每个通道有自己独立的健康状态条。一个通道显示绿色而另一个显示红色，即可立即传达信息：问题出在某个特定通道上，而不是副本服务器本身。

每个通道的操作

操作（START、STOP、SKIP）可以按通道执行：

-- 停止单个通道
STOP SLAVE 'channel_orders';

-- 跳过某个通道的错误
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE 'channel_orders';

-- MariaDB：停止特定通道
STOP SLAVE 'channel_clients';

按通道配置 REPLICATE_REWRITE_DB

在多源复制中，使用 REPLICATE_REWRITE_DB 重新映射数据库名称是很常见的做法：

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '10.0.1.1',
  ...
  FOR CHANNEL 'channel_clients';

-- 将副本上的 'clients' 重映射为 'dw_clients'
CHANGE REPLICATION FILTER
  REPLICATE_REWRITE_DB = ((clients, dw_clients))
  FOR CHANNEL 'channel_clients';

PmaControl 会检测并在通道详情中显示这些过滤器。这对于调试非常重要：如果某张表没有出现在副本上，检查重写过滤器应该是第一反应。

当前限制

PmaControl 在每个通道层面上对多源复制的管理表现良好。然而，要实现真正统一的监控，仍缺少一些功能。

没有"所有通道健康"视图

目前，没有一个汇总页面能够一目了然地展示某个副本所有通道的健康状态。你需要滚动从库页面来逐个检查每个通道。

缺少的功能是：页面顶部的摘要表格，每个通道带有绿/红指示器，例如：

channel_clients  ✅ IO: Yes  SQL: Yes  Lag: 0s
channel_orders   ⚠️ IO: Yes  SQL: Yes  Lag: 45s
channel_logs     ❌ IO: No   SQL: No   Error: 1062

没有聚合延迟

PmaControl 分别监控每个通道的延迟，但不计算聚合指标。例如：

所有通道中的最大延迟
平均延迟
出错通道数占总数的比例

这些聚合指标对告警非常有用："至少有一个通道延迟超过 60 秒"比逐通道告警更有意义，尤其是当你有 10 个通道时。

没有通道间依赖关系图

在多源复制中，通道之间是独立的。但在某些架构中，存在逻辑上的依赖关系：通道 A 必须在通道 B 之前应用（例如，参考表必须在事务表之前）。

PmaControl 不对这些依赖关系建模。如有需要，DBA 必须手动管理应用顺序。

没有按通道告警

当前的告警是服务器级别的，而非通道级别。如果通道 channel_clients 停止了但 channel_orders 仍在运行，告警仅显示"服务器 X 上复制出错"，而不会指明具体通道。

实际案例

分析整合

典型架构：

Master A (clients)  ─── channel_clients ──→
                                              分析副本
Master B (orders)   ─── channel_orders  ──→  (MariaDB / MySQL)

Master C (logs)     ─── channel_logs    ──→

副本整合了三个数据库。PmaControl 监控三个通道。如果主节点 C（日志）速度较慢，channel_logs 通道的延迟会增加，但不会影响另外两个通道。

在 PmaControl 中，你将在副本的从库页面上看到三个区块，配有三个独立的延迟图表。channel_logs 通道会有自己的健康状态条显示为琥珀色或红色，而另外两个通道保持绿色。

按通道迁移

在迁移过程中，你可以临时配置：

旧主节点     ─── channel_legacy  ──→
                                      新副本
新主节点     ─── channel_new     ──→

迁移完成后，channel_legacy 通道将被移除。在过渡期间，PmaControl 监控两个通道，允许你验证新通道已追上进度后再切断旧通道。

按数据库过滤

使用 REPLICATE_DO_DB 或 REPLICATE_REWRITE_DB，每个通道可以被过滤为只复制特定数据库：

CHANGE REPLICATION FILTER
  REPLICATE_DO_DB = (clients, clients_archive)
  FOR CHANNEL 'channel_clients';

CHANGE REPLICATION FILTER
  REPLICATE_DO_DB = (orders, order_items)
  FOR CHANNEL 'channel_orders';

PmaControl 显示每个通道的活跃过滤器，当预期的表没有出现在副本上时，这有助于快速诊断问题。

路线图

PmaControl 多源复制支持的计划改进：

统一的多源仪表板

专门用于多源复制的仪表板，包含：

矩阵视图：行为副本，列为通道
全局健康指标（所有通道正常为绿色，至少一个异常为红色）
聚合延迟（最大值、平均值、错误数量）

通道健康矩阵

紧凑的"热力图"可视化：

               周一  周二  周三  周四  周五  周六  周日
ch_clients     🟢   🟢   🟢   🟢   🟢   🟢   🟢
ch_orders      🟢   🟢   🟡   🟢   🟢   🟢   🟢
ch_logs        🟢   🟡   🔴   🟡   🟢   🟢   🟢

按通道告警

针对特定通道的 Telegram 告警：

⚠️ Replication Warning
Server: replica-analytics (10.0.3.1:3306)
Channel: channel_orders
Lag: 120s (threshold: 60s)
Status: IO=Yes, SQL=Yes

自动依赖检测

分析跨通道的外键以检测潜在的依赖关系，并在依赖通道出现延迟时发出告警。

多源复制最佳实践

1. 清晰命名通道

使用描述性名称：channel_clients、channel_orders，而不是 ch1、ch2。PmaControl 原样显示通道名称 -- 清晰的名称有助于快速诊断问题。

2. 一个通道 = 一个数据库（或一个逻辑分组）

避免在同一个通道中混合不相关的数据库。如果一个通道因错误而停止，它包含的所有内容都会被阻塞。

3. 监控中继日志空间

多个通道时，中继日志的磁盘空间可能会急剧增长。每个通道有自己独立的中继日志。在 PmaControl 中按通道监控 Relay_Log_Space。

4. 测试单个通道的停止

确保停止一个通道不会影响其他通道。PmaControl 允许你独立地 STOP/START 每个通道 -- 利用此功能来验证通道隔离性。

5. 记录架构文档

多源复制增加了复杂性。记录每个通道承载哪个数据库、来自哪个主节点、使用了哪些过滤器。PmaControl 会显示这些信息，但外部文档对于新成员入职培训仍然很有价值。

结论

多源复制是 MariaDB / MySQL 数据整合的强大工具。PmaControl 自动检测多个通道，并通过延迟图表、健康状态条和按通道的纠正操作对每个通道进行独立监控。

当前的限制 -- 缺少统一视图、没有按通道告警、没有聚合延迟 -- 已被识别并纳入路线图。在此期间，按通道的监控涵盖了核心需求：了解哪个通道有延迟、哪个通道出错，以及能够对其进行单独操作。

对于在生产环境中管理多源架构的 DBA 来说，PmaControl 仍然是最合适的工具 -- 即使尚不完美 -- 因为没有任何竞品能够开箱即用地提供这种按通道的可视化能力。

使用 PmaControl 监控多源复制