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“ 各个指标解释如下列表：

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 主从数据同步的状态，对于运维监控和告警策略的制定有重要意义。