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 分隔,示例如下:
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 主从数据同步的状态,对于运维监控和告警策略的制定有重要意义。
版权声明: 本文为 InfoQ 作者【apache/dubbo-go】的原创文章。
原文链接:【http://xie.infoq.cn/article/c5f517fee87112f1ff2ff576a】。未经作者许可,禁止转载。
评论