Pika 主从数据同步状态指标 “repl_connect_status” 简介

原创

dubbogo社区 2024-06-05 22:49:57 ©著作权

文章标签 ci 数据同步旁路 Redis 文章分类 C/C++ 后端开发

©著作权归作者所有：来自51CTO博客作者dubbogo社区的原创作品，请联系作者获取转载授权，否则将追究法律责任

1 背景

PR #2638 合并后，Slave 超时后重新与 Master 建连，可能会有更长的时间处于 "connecting" 状态。此时主从已经建连成功，但若用户欲获取主从数据同步状态，只能查看日志，很不方便。

2 新增指标 "repl_connect_status"

为了方便用户或其他旁路系统实时获取 Pika 的数据同步状态，我们在 PR #2656 中新增了主从数据同步 info 命令指标 ”repl_connect_status“。

3 指标获取方式

向 Slave 端发送 info/info replication 命令进行获取，该值也会出现在 Slave 实例上，对 Master 发送 info 命令是取不到该指标的

4 指标格式

每个 db 均有自己的 repl_connect_status 值，以 \n 分隔，示例如下：

repl_connect_status:
db0:syncing_full
db1:syncing_full
db2:try_to_incr_sync
db3:try_to_incr_sync
db4:try_to_incr_sync
db5:try_to_incr_sync
db6:try_to_incr_sync
db7:syncing_full

5 指标值域

”repl_connect_status“ 各个指标解释如下列表：

指标	解释
no_connect	主从断联 / 无主从连接
try_to_incr_sync	瞬时状态：从节点处于 TrySync 状态，即将发出 TrySync 请求来建立主从连接
try_to_full_sync	瞬时状态：从节点处于 TryDBSync 状态，即将发出 TryDBSync 请求来进行全量同步
syncing_full	主从节点正在进行全量同步
connecting	大部分情况下是瞬时状态，但在极端情况下，该状态可能持续几十秒到几分钟：从节点发出建联请求 (TrySync Req) 后，在收到并处理主节点回复的 TrySync Resp 前，从节点都处于这一状态中
error	从节点状态错误，需介入排查

6 运维监控建议

旁路监控告警系统可以向 Slave 端发送 info or info replication 命令，实时获取 Slave 数据同步状态。当 master_status_link 为 down 时，可以使用 repl_connnect_status 判断是否进行告警。

有如下一些告警策略建议：

6.1 repl_connect_status 与 master_link_status 的关联

只有当所有 DB 的 repl_connect_status 都为 connected 时，master_status_link 才会为 up，只要有任何一个 db 不处于该状态，master_status_link 均为 down

6.2 告警策略的建议

A 允许 repl_connect_status 在 connecting 状态停留一段时间，但不应该超过 5 分钟：

PR 2638 将 Slave 对 TrySync Resp 的处理由异步改成了同步，如果 Slave 被某个 Binlog 任务阻塞住，就会延迟对 TrySync Resp 的处理，在此期间，Slave 的 repl_connect_status 将一直处于 connecting 状态。
只有等到 Slave 的阻塞解除，TrySync Resp 才会得到 Slave 的处理，完成主从连接的建立（Slave 也会从 connecting 转为 connected 状态）。
所以，Slave 会在 connecting 状态持续多久，取决于 Slave 在建联时是否处于阻塞状态，在绝大部分情况下 Slave 都是不阻塞的，connecting 也是一个瞬时状态，但如果发生了极端情况导致 Slave 阻塞，那 Slave 可能会在 connecting 状态上停留较长时间，此时 connecting 状态持续多久，就取决于 slave 阻塞了多久。