写点什么

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

作者:apache/dubbo-go
  • 2024-06-05
    北京
  • 本文字数:1098 字

    阅读完需:约 4 分钟

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

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_fulldb1:syncing_fulldb2:try_to_incr_syncdb3:try_to_incr_syncdb4:try_to_incr_syncdb5:try_to_incr_syncdb6:try_to_incr_syncdb7:syncing_full
复制代码

5 指标值域

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


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 阻塞了多久。

  • B 如果 repl_connect_status 处于 syncing_full,说明主从正在进行全量同步,这一阶段的时间取决于各种因素(DB 大小,网络带宽等),关于这个阶段的停留时间可以酌情考量

7 总结

repl_connect_status 指标可以帮助用户或其他系统实时了解 Pika 主从数据同步的状态,对于运维监控和告警策略的制定有重要意义。

发布于: 刚刚阅读数: 4
用户头像

dubbogo社区 2019-08-25 加入

dubbogo社区官方账号,发布 github.com/apache/dubbo-go 各种最新技术趋势、项目实战和最新版本特性等技术干货。

评论

发布
暂无评论
Pika 主从数据同步状态指标 “repl_connect_status” 简介_redis_apache/dubbo-go_InfoQ写作社区