作者： gary 原文来源：https://tidb.net/blog/17cdb883

一、前言

  TiDB分布式数据库采用多副本机制，数据副本通过 Multi-Raft 协议同步事务日志，确保数据强一致性且少数副本发生故障时不影响数据的可用性。但在三副本情况下，单副本损坏集群性能还是会有一定影响的。本文介绍在TiKV在不同情况下故障会给集群带来什么影响和如何去处理这些问题。

二、计划内停机，单台服务器不可用时

    一般我们需要调整max-store-down-time参数，PD 认为失联 store 无法恢复的时间，当超过指定的时间没有收到 store 的心跳后，PD 会在其他节点补充副本，默认值：30m。
   如果计划内停机，比如更换机器内存，机架位置等操作，建议max-store-down-time调大一些，防止region进行重新补副本操作，消耗集群资源，影响在线业务。

待 Tiup 正常启动该 TiKV 实例后，我们需要观察 grafana PD 相关监控 Grafana PD–>PD Dashboard–>Region healthy1）PD_miss_peer_region_countRegion 的副本数小于 max-replicas 配置的值。

处理方法：1. 查看是否有 TiKV 宕机或在做下线操作，尝试定位问题产生的原因。2. 观察 region health 面板，查看 miss-peer-region-count 是否在不断减少。

2）PD_pending_peer_region_countRaft log 落后的 Region 过多。由于调度产生少量的 pending peer 是正常的，但是如果持续很高，就可能有问题

处理方法：1. 观察 region health 面板，检查 pending_peer_region_count 是否在不断减少。2. 检查 TiKV 之间的网络状况，特别是带宽是否足够。

3）PD_down_peer_region_numsRaft leader 上报有不响应 peer 的 Region 数量。

处理方法：1. 检查是否有 TiKV 宕机，或刚发生重启，或者繁忙。2. 观察 region health 面板，检查 down_peer_region_count 是否在不断减少。3. 检查是否有 TiKV 之间网络不通。

Grafana PD–>Operator–>Schedule Operator Createpd 发现 region 异常，比如 region 不均衡，region 缺副本，Operator 的创建情况。

Grafana PD–>Operator–>Operator finish durationRegion 在补副本时，主要看 pd 是否繁忙，Operator 执行耗时的情况

三、计划内停机，两台及以上服务器不可用

   查看计划停机的两台store是否同时计划内停机是否满足Raft协议，如果满足可以同时处理，如果不满足则需要逐一停机或者提前进行驱逐leader的操作

 pd-ctl -u <endpoint> -d region --jq='.regions[]|{id: .id, peer_stores: [.peers[].store_id]| select(length as $total | map(if .==(3,4) then . elseempty end) | length>=$total-length)}'

1. 如果上面命令输出为空，则满足 raft 协议，可以两台服务器同时进行停机处理。

2. 如果上面命令输出为非空，则有部分 region 不满足 raft 协议，需要逐一进行停机处理。

四、计划外停机，满足 raft 多数派

计划外停机满足 raft 多数派，节点如果可以正常拉起，是不需要人工干预的

但是我们需要留意 max-store-down-time 参数，PD 认为失联 store 无法恢复的时间，当超过指定的时间没有收到 store 的心跳后，PD 会在其他节点补充副本，默认值：30m。

计划外停机满足 raft 多数派，节点如果不可以正常拉起，我们快速处理的方法就是缩容掉异常节点，重新扩容一个新节点以保证集群正常运行

1.Rocks DB Apply Snapshot

日志里面可看到 sst file size mismatch 错误，这种只能通过扩缩容来解决

2.Raft 状态机损坏

日志里面可看到 last index 错误，找到所有损坏的副本，跳过问题 region 拉起

tikv-ctl –db /path/to/tikv-data/db bad-regions

Tikv-ctl -db /path/to/tikv-data/db tombstone -r  <region-id> –force

五、计划外停机，不满足 raft 多数派

计划外停机不满足 raft 多数派的影响 1. 无法选举新 Leader 以及宕机超过 max-store-down-time 也无法进行补副本操作 2. 前端业务访问部分出现报错 3. 仅访问到异常 Region 的应用会出现报错

多副本损坏的有损恢复处理方法可参考：https://tidb.net/blog/b1ae4ee7

两副本丢失处理

#region数量较少情况tikv-ctl --db /path/to/tikv-data/db unsafe-recover remove-fail-stores -s <31,s4,s6>-r<1,r2,r3>-s︰表示发生异常的TiKV 节点的store lD-r:表示副本数量超过一半及以上的副本丢失的 Region的ID
#region数量较多情况tikv-ctl --db /path/to/tikv-data/db unsafe-recover remove-fail-stores -s <31,s2,s4,s6> --all-regions-s︰表示未发生服务器异常的TiKV节点的store lD

三副本丢失处理

#统计副本数丢失一半以上的region.pd-ctl -u http:/ip:port region -jq='.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as$total | map(if .==(693842,694019,694073) then . else empty end) | length>=$total-length)}'#查当前集群中存在没有leader的region,预期结果位空pd-ctl -u http:/ip:port region -jq '.regions[]select(has("leader")|not)|（id: .id, peer_stores: [.peers[].store_id]'#创建空regiontikv-ctl --db /path/to/tikv-data/db recreate-region -p <endpoint -r region_id>

数据校验

保证数据与索引一致

admin check index tbl_name idx_name

六、总结

   TiKV存储节点需要预期内停机或意外停机，我们可根据不同的情况进行不同的处理。因TiDB分布式数据库采用多副本机制，只有不满足raft多数派时候，我们需要人工去干预。日常运维管理，对于重要的业务系统操作前，最好进行全备，避免再不必要情况可以进行恢复。