一、前言
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 healthy 1）PD_miss_peer_region_count Region 的副本数小于 max-replicas 配置的值。
处理方法： 1.查看是否有 TiKV 宕机或在做下线操作，尝试定位问题产生的原因。 2.观察 region health 面板，查看 miss-peer-region-count 是否在不断减少。
2）PD_pending_peer_region_count Raft log 落后的 Region 过多。由于调度产生少量的 pending peer 是正常的，但是如果持续很高，就可能有问题
处理方法： 1.观察 region health 面板，检查 pending_peer_region_count 是否在不断减少。 2.检查 TiKV 之间的网络状况，特别是带宽是否足够。
3）PD_down_peer_region_nums Raft leader 上报有不响应 peer 的 Region 数量。
处理方法： 1.检查是否有 TiKV 宕机，或刚发生重启，或者繁忙。 2.观察 region health 面板，检查 down_peer_region_count 是否在不断减少。 3.检查是否有 TiKV 之间网络不通。
Grafana PD-->Operator-->Schedule Operator Create pd发现region异常，比如region不均衡，region缺副本，Operator 的创建情况。
Grafana PD-->Operator-->Operator finish duration Region在补副本时，主要看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]'
#创建空region
tikv-ctl --db /path/to/tikv-data/db recreate-region -p <endpoint -r region_id>
数据校验
保证数据与索引一致
admin check index tbl_name idx_name
六、总结
TiKV存储节点需要预期内停机或意外停机，我们可根据不同的情况进行不同的处理。因TiDB分布式数据库采用多副本机制，只有不满足raft多数派时候，我们需要人工去干预。日常运维管理，对于重要的业务系统操作前，最好进行全备，避免再不必要情况可以进行恢复。