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_full5 指标值域
”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 阻塞了多久。
- B 如果 repl_connect_status 处于 syncing_full，说明主从正在进行全量同步，这一阶段的时间取决于各种因素（DB 大小，网络带宽等），关于这个阶段的停留时间可以酌情考量
7 总结
repl_connect_status 指标可以帮助用户或其他系统实时了解 Pika 主从数据同步的状态，对于运维监控和告警策略的制定有重要意义。
