Galera IST：PMM 显示的与实际存在的差异

关于 Galera IST 的 PMM 仪表板迷思

如果您使用 Percona Monitoring and Management (PMM) 来监控 MariaDB 上的 Galera 集群，您可能注意到了一个名为"IST Progress"或"IST Receive"的面板。它显示的是...什么都没有。空行、N/A 值、平坦的图表。

这不是显示错误。PMM 查询的变量在 MariaDB 10.6 上根本不存在。

复习：IST 与 SST

当一个 Galera 节点在断开连接后重新加入集群时，有两种同步机制可用：

• SST（State Snapshot Transfer，状态快照传输）：捐赠节点发送数据集的完整副本。速度慢、开销大，可能会阻塞捐赠节点。根据数据量，可能需要几分钟到几小时。
• IST（Incremental State Transfer，增量状态传输）：捐赠节点仅从 GCache 发送缺失的写入集。速度快、轻量级，只需几秒到几分钟。

这种差异在生产环境中至关重要。20 秒的 IST 对用户来说是无感的。45 分钟的 SST 可能导致故障。

测试：MariaDB 10.6.23 + sysbench

为了记录真实行为，我们搭建了一个 3 节点的 MariaDB 10.6.23 Galera 集群，并运行了持续的 sysbench 工作负载：

sysbench oltp_read_write --tables=10 --table-size=100000 \
  --threads=16 --time=600 --db-driver=mysql run

在工作负载运行期间，我们停止了节点 3 持续 30 秒，然后重新启动它。结果：

• 捐赠节点的 GCache 中累积了 188,516 个写入集
• 节点 3 通过 IST 在 20-25 秒内重新加入集群
• 节点 1 和节点 2 没有服务中断

节点 3 上的 MariaDB 日志确认：

[Note] WSREP: Receiving IST: 188516 writesets, seqnos 1045632-1234148
[Note] WSREP: IST received: 85a4c3e2-xxxx
[Note] WSREP: 3.0 (node3): State transfer from 0.0 (node1) complete.

IST 完美运行。现在来看看 PMM 对此的说法。

PMM 试图读取什么

PMM v2 的 Galera 仪表板查询以下变量来绘制 IST 进度图：

SHOW GLOBAL STATUS LIKE 'wsrep_ist_receive_seqno_start';
SHOW GLOBAL STATUS LIKE 'wsrep_ist_receive_seqno_current';
SHOW GLOBAL STATUS LIKE 'wsrep_ist_receive_seqno_end';

在 MariaDB 10.6.23 上，这三个查询都返回空结果集。这些变量不存在。

MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep_ist%';
Empty set (0.001 sec)

这不是配置疏忽。这些变量是 Percona XtraDB Cluster (PXC) 特有的，从未在 MariaDB Galera 提供程序中实现。

SST 封装脚本陷阱

还有一个额外的细节造成了混淆：即使在 IST 期间，MariaDB 也会调用 SST 封装脚本（wsrep_sst_mariabackup 或 wsrep_sst_rsync）。因此日志中包含如下行：

WSREP: Running: 'wsrep_sst_mariabackup --role donor ...'

阅读这些日志的运维人员可能会得出正在进行完整 SST 的结论。实际上，封装脚本初始化后检测到追赶将通过 IST 进行。实际的传输是增量的。

如何在 MariaDB 上检测 IST

由于 PMM 变量不存在，需要替代方法。三种方法：

1. 解析 MariaDB 日志

日志中的 IST 签名是明确的：

[Note] WSREP: Receiving IST: <N> writesets, seqnos <start>-<end>

对错误日志进行简单的 grep 即可立即得到答案。这是最可靠的方法。

2. 观察 wsrep_local_state_comment

在 IST 期间，重新加入节点上的 wsrep_local_state_comment 变量经历以下转换：

Joining -> Joined -> Synced

如果在活跃集群上此转换不到 30 秒，很可能是 IST。在数十 GB 数据集上的 SST 会花费更长时间。

3. 检查 GCache

捐赠节点上的 wsrep_local_cached_downto 变量指示 GCache 中仍可用的最旧 seqno。如果断开连接节点的 seqno 高于此值，IST 就是可能的：

-- 在捐赠节点上
SHOW GLOBAL STATUS LIKE 'wsrep_local_cached_downto';
-- 结果：1045000

-- 如果断开连接的节点处于 seqno 1045632 -> IST 可行
-- 如果断开连接的节点处于 seqno 800000 -> 需要 SST

PmaControl 的做法

PmaControl 结合了以上三种方法来自动检测和分类 Galera 传输：

1. 持续监控 wsrep_local_state_comment — 检测转换到 Joining 状态
2. MariaDB 日志解析 — 提取包含写入集数量的 Receiving IST 行
3. 时间关联 — 测量 Joining 和 Synced 之间的时间

结果以清晰的区分显示在 PmaControl 仪表板中：IST（绿色标签，以秒为单位的持续时间）与 SST（橙色标签，以分钟为单位的预估持续时间）。

与 PMM 不同，PmaControl 不依赖于仅在 PXC 上存在的变量。日志解析方法适用于自 10.1 以来的所有版本的 MariaDB Galera。

关键数据

建议

1. 如果您运行 MariaDB，不要依赖 PMM Galera 仪表板进行 IST 跟踪——面板将始终为空
2. 慷慨地分配 GCache 大小（最少 gcache.size=2G），以最大化短暂断开后的 IST 机会
3. 集中管理 MariaDB 日志——它们是 Galera 传输的真实来源
4. 使用 PmaControl 进行在 MariaDB 上真正有效的 Galera 监控，而不仅仅是在 PXC 上

总结

PMM 的 Galera IST 仪表板是为 Percona XtraDB Cluster 设计的。在 MariaDB Galera 上，它什么都不显示——不是因为 IST 不工作，而是因为它查询的变量不存在。

IST 在 MariaDB 10.6 上运行得很好。您只需要知道在哪里查看：在日志中，而不是在幻影变量中。