在 PmaControl 中部署主从复制并监控复制状态

2026 年的复制：依然是基石

主从复制仍然是任何生产环境 MariaDB / MySQL 基础架构的基本构建模块。高可用性、读负载分发、热备份——一切都依赖于它。然而，大多数严重的数据库事故都涉及复制中断或未被检测到的延迟。

本文涵盖复制的两个方面：如何正确配置复制，以及如何在 PmaControl 中进行监控，确保您永远不会措手不及。

配置复制

主库先决条件

主库必须启用 binlog 并拥有唯一的 server-id：

[mysqld]
server-id = 1
log-bin = /var/log/mysql/mysql-bin
binlog-format = ROW
gtid_strict_mode = ON          # MariaDB
# enforce_gtid_consistency = ON  # MySQL
# gtid_mode = ON                 # MySQL

创建复制用户：

CREATE USER 'repl'@'10.0.1.%' IDENTIFIED BY 'secret_replication_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.1.%';

从库先决条件

从库需要自己的 server-id 和中继日志：

[mysqld]
server-id = 2
relay-log = /var/log/mysql/relay-bin
read-only = ON
log-slave-updates = ON

log-slave-updates 在您计划链式从库（从库的从库）或使用 Galera 时是必不可少的。

启动复制

使用 GTID（推荐）

在 MariaDB 上：

CHANGE MASTER TO
  MASTER_HOST = '10.0.1.1',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'secret_replication_password',
  MASTER_USE_GTID = slave_pos;

START SLAVE;

在 MySQL 8.0+ 上：

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '10.0.1.1',
  SOURCE_USER = 'repl',
  SOURCE_PASSWORD = 'secret_replication_password',
  SOURCE_AUTO_POSITION = 1;

START REPLICA;

不使用 GTID（经典模式）

如果未启用 GTID，您需要记录主库的 binlog 位置：

-- 在主库上
SHOW MASTER STATUS;
-- File: mysql-bin.000042, Position: 154

-- 在从库上
CHANGE MASTER TO
  MASTER_HOST = '10.0.1.1',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'secret_replication_password',
  MASTER_LOG_FILE = 'mysql-bin.000042',
  MASTER_LOG_POS = 154;

START SLAVE;

验证是否正常运行

SHOW SLAVE STATUS\G

两个关键指标：

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0

如果 Slave_IO_Running 为 No，表示从库无法连接到主库（网络、凭据、防火墙问题）。如果 Slave_SQL_Running 为 No，表示从库无法应用事件（SQL 错误、约束冲突）。

在 PmaControl 中添加服务器

通过 Web 界面

1. 进入 服务器 -> 添加服务器
2. 输入 IP、端口（3306）、SSH 和 MySQL 凭据
3. PmaControl 在第一个采集周期后自动检测角色（主库或从库）

通过 REST API

# 添加主库
curl -X POST -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ip": "10.0.1.1", "port": 3306, "name": "db-prod-master", "ssh_key_id": 1}' \
  https://pmacontrol.example.com/api/v1/servers

# 添加从库
curl -X POST -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ip": "10.0.1.2", "port": 3306, "name": "db-prod-slave-01", "ssh_key_id": 1}' \
  https://pmacontrol.example.com/api/v1/servers

PmaControl 在一分钟内启动采集周期。从库随后会在仪表板中显示"Slave"标签。

PmaControl 中的从库页面

复制监控可通过以下路由访问：

/{lang}/slave/show/{id}/{name}/

例如：/en/slave/show/42/db-prod-slave-01/

Slave.php 控制器提供两个主要操作：

• show()：主页面，包含当前状态和延迟图表
• showGraphDay()：AJAX 数据，用于加载额外一天的图表数据

监控变量

PmaControl 采集 SHOW SLAVE STATUS 的所有变量并将其存储在时间序列表中。最关键的变量：

对于 MySQL 8.0+，PmaControl 也处理重命名后的等效变量：

PmaControl 在内部自动规范化两种名称。

延迟图表

延迟图表是从库页面的核心。它以 Chart.js 曲线显示最近 5 天的 Seconds_Behind_Master 数据。

功能特点：

• 分辨率：每分钟一个数据点（每天 1440 个点）
• 渐进加载：当天数据立即加载，前几天通过 AJAX "加载前一天"按钮加载
• 自动缩放：Y 轴适应观察到的最大延迟
• 绿色区域：< 10 秒，正常运行
• 琥珀色区域：10-60 秒，中等延迟
• 红色区域：> 60 秒，严重延迟

健康状态条

图表上方有一条水平状态条，用颜色编码总结过去 24 小时内每分钟的状态：

这是一个即时的视觉指标：一眼就能判断过去 24 小时是稳定的还是混乱的。

PmaControl 中的纠正措施

从库页面不仅限于观察。PmaControl 允许您直接对复制进行操作。

START / STOP SLAVE

两个按钮用于启动或停止复制。STOP SLAVE 在以下场景中非常有用：

• 在从库上执行维护（重型 ALTER TABLE）
• 获取一致性备份（停止复制后的快照）
• 诊断延迟问题（停止以检查 binlog）

跳过错误

当复制因 SQL 错误停止时（重复约束、缺少表），PmaControl 提供跳过事件的选项：

SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;

警告：此操作需要明确确认。跳过事件意味着接受主从之间的数据差异。PmaControl 会记录操作人、日期和被跳过的错误以便追溯。

并行工作线程

PmaControl 提供一个滑块来调整并行复制工作线程的数量：

• 最小值：1（经典顺序复制）
• 最大值：50 或 CPU x 2（取较小值）

STOP SLAVE;
SET GLOBAL slave_parallel_workers = 8;
START SLAVE;

增加工作线程可以更快地追赶延迟，因为多个事务可以并行应用。但请注意：这仅在使用 LOGICAL_CLOCK（MariaDB）或 WRITESET（MySQL 8.0+）的并行复制模式下效果良好。

追赶预计时间算法

当从库存在延迟时，最直接的问题是：需要多长时间才能追赶上？

PmaControl 基于以下因素计算预估时间（ETA）：

1. 当前延迟秒数
2. 观察到的追赶速度（最近 10 分钟的延迟变化）
3. 线性外推

如果延迟从 3600 秒降至 3000 秒，耗时 10 分钟：
  速度 = 追赶 600 秒 / 10 分钟 = 60 秒/分钟
  ETA = 3000 秒 / 60 秒/分钟 = 50 分钟

ETA 显示在从库页面顶部，配有进度条。如果追赶速度为零或为负（延迟在增加），PmaControl 会以红色显示"ETA: 发散"——这表明需要人工干预。

GTID 支持

PmaControl 自动检测 GTID 模式：

• MariaDB：从 SHOW SLAVE STATUS 中读取 Using_Gtid。可能的值：No、Slave_Pos、Current_Pos
• MySQL：从 SHOW SLAVE STATUS 中读取 Auto_Position。可能的值：0、1

当 GTID 处于活跃状态时，PmaControl 显示额外信息：

• 主库的 GTID 集合（Gtid_Slave_Pos 或 Executed_Gtid_Set）
• 从库的 GTID 集合
• 两者之间的差值（落后的事务数量）

GTID 差值通常比 Seconds_Behind_Master 更有意义：它给出了需要追赶的确切事务数量，而不受每个事务持续时间的影响。

最佳实践

1. 始终使用 GTID

Binlog 位置模式（文件 + 位置）是脆弱的：一个过早清除的文件、一次故障转移，复制就会中断。GTID 是幂等的，能够在故障转移后继续工作。

2. 在从库上启用 read_only

SET GLOBAL read_only = ON;
SET GLOBAL super_read_only = ON;  -- MySQL 5.7.8+ / MariaDB 10.3.16+

没有 read_only，从库上的意外写入会导致静默的数据差异。

3. 监控延迟，而不仅仅是状态

Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 还不够。一个从库可以是"运行中"状态但有 2 小时的延迟。PmaControl 同时监控两者：状态和延迟。

4. 配置告警

在 PmaControl 中设置告警阈值：

• 警告：延迟超过 60 秒持续 5 分钟
• 严重：延迟超过 300 秒或 IO/SQL 已停止

告警通过 Telegram 发送，包含服务器名称、当前延迟和直达从库页面的链接。

5. 规划重型操作

大表的 ALTER TABLE 会产生临时的延迟峰值。在生产环境中使用 pt-online-schema-change 或 gh-ost 进行 DDL 操作，并在 PmaControl 中将从库置于维护模式以避免误报。

总结

MariaDB / MySQL 复制配置简单，但长期维护困难。PmaControl 弥合了"复制正在运行"和"复制运行健康"之间的差距，提供：

• 具有 5 天历史记录的实时延迟视图
• 集成的纠正措施（启动/停止、跳过、并行工作线程）
• 用于预判的追赶预估时间（ETA）
• 自动 GTID 检测
• 主动 Telegram 告警

目标不是取代 DBA——而是为他们提供工具，让他们能在几分钟内而不是几小时内做出响应。