codis dashboard failover 方案

[chengyu-l]

Pika 3.5.2 版本 Codis Sentinel 工作原理

pika 同样采用 codis 实现了集群功能，但是 Pika Codis 在解决 Failover 问题采用了不同的方案。Pika Codis 将 Sentinel 能力集成到了 codis-dashboard 中，当 codis-dashboard 发现 pika 节点异常后，会自动发起选举新主，将旧主降级为从节点，并将变更的 Group 信息持久化到 etcd 中，然后通知 codis-proxy 更新 Group 信息。

接下来重点介绍一下 codis-dashboard 中的 sentinel 模块是如何工作的。

codis-dashboard 启动时，会有两个协程用于周期性查询所有 pika server 的状态。CheckMastersAndSlavesState 会每 5 秒执行一次 info replication 命令，用于检查所有 GroupServer（即 pika server，包含 Master 和 Slave）的状态。CheckMastersAndSlavesState 发现有节点异常，会将该节点对应的 GroupServer 中的 State 状态设置为预离线（GroupServerStateSubjectiveOffline）状态。 CheckPreOffineMastersState 会每 1 秒执行执行一次 info replication 命令，针对所有 Group 的 Master 节点，并且 Master 处于异常状态（State异常状态有 GroupServerStateSubjectiveOffline 或 GroupServerStateOffline，GroupServerStateNormal 为正常状态）的节点再进行存活检测，如果再次检测 5 次，仍为异常状态，则将 GroupServer 的状态置为离线（GroupServerStateOffline）状态 。

经过多次 info 检查，确认 Group 的 Master 离线后，将会发起自动主从切换。选取新主的策略为优先选择状态正常，pika server 中 repl_offset （Master 节点取 master_repl_offset，Slave 节点取 slave_repl_offset）最大的作为新的 Master 节点。Codis 是如何区分主从节点的？在 Codis Group 中有个 GroupServer 数组，默认将第 0 个位置的 GroupServer 作为 Master 节点。Codis 主从切换是将新主与第 0 个位置的 GroupServer 进行替换，从而实现主从切换。

完成主从切换后，会将最新的 Group 视图持久化存储到 etcd 中，最后再通知所有 codis-proxy 组件。

如何解决主从切换后，旧主重新恢复服务，并将流程自动化

目前存在的主要问题是 旧节点恢复服务后主从关系有可能仍停留在以前的旧配置，没有更新成最新的配置。现在的解决方法是 需要运维人员手工操作，运维复杂，操作复杂（多个操作步骤），因此，运维人员希望可以将恢复流程自动化。

下面介绍一下如何在 codis-dashboard 中将故障恢复流程自动化。

根据 codis-dashboard 现有逻辑，新增一个CheckOfflineMastersAndSlavesState 协程，由该协程周期性（每2秒执行1次）检查所有已经客观下线节点的状态信息，流程如上图，向已客观下线的节点发送 info replication 命令，探测服务是否恢复。如果命令执行成功，则认为服务恢复。服务恢复后，先检查节点最新的 info replication 命令中记录的，与 codis-dashboard 记录的主从复制关系是否一致。如果不一致，就需要对该 GroupServer 执行 slaveof 命令，建立新的主从关系。新的主从关系建立后，更新 GroupServer 的 state 和 role (有可能是旧的Master节点，需要将其改为 Slave) ，然后持久化新的 Group 信息，并重置 codis-dashboard 的 Group 缓存信息，最后通知所有 codis-proxy 更新信息。

[chengyu-l]

所以处在db_repl_state:(db0:Error)状态的从库，大约每一分钟都会重置状态，将ERR状态重置为PIKA_REPL_SHOULD_META_SYNC，开始进行trysync。

如下从库日志：

I20240217 14:20:39.486991  1055 client_thread.cc:222] Do cron task del fd 67
I20240217 14:21:51.549265  1055 client_thread.cc:222] Do cron task del fd 67
I20240217 14:23:03.615336  1055 client_thread.cc:222] Do cron task del fd 67
I20240217 14:25:27.755411  1055 client_thread.cc:222] Do cron task del fd 67
I20240217 14:26:39.827195  1055 client_thread.cc:222] Do cron task del fd 67


I20240218 16:56:56.386368  1055 client_thread.cc:222] Do cron task del fd 67
I20240218 16:58:08.454473  1055 client_thread.cc:222] Do cron task del fd 67

I20240218 16:58:08.454530  1055 pika_repl_client_thread.cc:36] ReplClient Timeout conn, fd=67, ip_port=10.146.75.161:10691 
W20240218 16:58:08.454557  1055 pika_repl_client_thread.cc:46] Master conn timeout : 10.146.75.161:10691 try reconnect
I20240218 16:58:13.161530   855 pika_server.cc:1838] hit rate:0
I20240218 16:58:18.022200  1109 pika_repl_client.cc:138] Try Send Meta Sync Request to Master (10.146.75.161:8691)
I20240218 16:58:18.022612  1056 pika_server.cc:447] Mark try connect finish
I20240218 16:58:18.022661  1056 pika_repl_client_conn.cc:151] Finish to handle meta sync response
I20240218 16:58:18.161660   855 pika_server.cc:1838] hit rate:0
W20240218 16:58:18.162467  1057 pika_repl_client_conn.cc:231] DB: db0 TrySync Error, Because the invalid filenum and offset

I20240218 16:59:20.523458  1055 client_thread.cc:222] Do cron task del fd 67
I20240218 17:00:32.590663  1055 client_thread.cc:222] Do cron task del fd 67

如下从库连续info replication变化:

# Replication(SLAVE)
role:slave
ReplicationID: 3ee35392bfb2f356effe8059d083e461b17614b1315f3c5b82
master_host:10.146.75.161
master_port:8691
master_link_status:down
slave_priority:100
slave_read_only:1
db_repl_state:(db0:Error)
db0 binlog_offset=472 30929325,safety_purge=write2file462

# Replication(SLAVE)
role:slave
ReplicationID: 3ee35392bfb2f356effe8059d083e461b17614b1315f3c5b82
master_host:10.146.75.161
master_port:8691
master_link_status:down
slave_priority:100
slave_read_only:1
db_repl_state:(db0:NoConnect)
db0 binlog_offset=472 30929325,safety_purge=write2file462

# Replication(SLAVE)
role:slave
ReplicationID: 3ee35392bfb2f356effe8059d083e461b17614b1315f3c5b82
master_host:10.146.75.161
master_port:8691
master_link_status:down
slave_priority:100
slave_read_only:1
db_repl_state:(db0:kTryConnect)
db0 binlog_offset=472 30929325,safety_purge=write2file462

# Replication(SLAVE)
role:slave
ReplicationID: 3ee35392bfb2f356effe8059d083e461b17614b1315f3c5b82
master_host:10.146.75.161
master_port:8691
master_link_status:down
slave_priority:100
slave_read_only:1
db_repl_state:(db0:Error)
db0 binlog_offset=472 30929325,safety_purge=write2file462

所以在两分钟之内，确认db_repl_state:(db0:Error)，那么sentinel就可以直接进行slaveof force。

slave 节点执行 slaveof 命令后，可能会出现 pika 执行命令失败，db_repl_state 状态为 Error。这时需要运维人员手动再次执行 slaveof -f 命令，强制执行全量同步，运维工作相对复杂。

为了简化运维工作，与 @baixin01 沟通讨论后，在 codis 中增加以下代码逻辑，以简化运维人员工作：
（1）在第一次执行完 slaveof 命令后，新启动一个协程。新协程逻辑如下：
（2-1）第一次sleep 5 秒，检查 db_repl_state 状态，为 Error。然后 sleep 2 分钟，再次检查 db_repl_state 状态，是否为 Error，是Error，执行 slaveof force，然后退出协程； 如果不是 Error，则直接退出协程。
（2-2）第一次sleep 5 秒，检查 db_repl_state 状态，为 NoConnect，kTryConnect，sleep 2 秒，再次检查 db_repl_state 状态，是否为 Error，是Error，然后 sleep 2 分钟，再次检查 db_repl_state 状态，是否为 Error，是Error，执行 slaveof force，然后退出协程；如果不是 Error，则退出协程。