引入数学概率问题：之前上学时都学过，把几组小球放几个盒子，然后计算概率的问题，那么我有10组小球(每组3个)，放5个盒子里(每个盒子不能空着)，会有多大的概率在2个盒子损坏的情况下，保证每组小球至少保留1个？
Tikv可用性图
下面对上图简单解释下：
（1）以上都是在region默认3副本的情况下的讨论。
(2) 以上的可用性都是在大量region的情况下，无论有多少个tikv节点，一个region的3个副本肯定会调度到KV集群的3个tikv上，3个副本的多数副本不可用，该region就不可用了，大量region的情况下，有很大的概率同一个raft group的2个peer正好调度在宕机的2个tikv上，这也是为啥文章开头说概率的意义。
（3）集群可用是指：就算DBA不介入，整个集群也会正常提供服务。比如拿5个节点的tikv cluster来讲，每次只能宕机1台，tikv宕机后，在该tikv上的leader region会根据raft-group来找follwer region来提升为新leader，并且等30分钟后其他tikv节点补副本，最终完成3个副本的raft-group；另外对于该tikv节点上的follwer region，在其他tikv节点的leader region也会在另外的tikv节点补follwer region节点(3个节点的tikv集群在宕机1台的情况下，没有多余的kv节点可以补副本，这时需要扩容tikv来补)。
（4）不丢数据是指：在3副本的情况下，如果多数副本(2个副本)不可用的情况下，但是还保留着一份副本（数据没有丢），SQL读写的表现就是：该region就不可用。
所以聊了3副本的可用性问题后，咱们就通过5个tikv节点的宕机测试来验证可用性以及数据恢复方案。
实验模拟5节点集群宕机可用性
测试环境：
使用sysbench导入10张50万数据的table，然后sysbench读流量模拟请求。
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=10.xxxx.160 --mysql-port=4000 --mysql-db=test --mysql-user=root --mysql-password='xxx' --table_size=500000 --tables=10 --threads=30 --time=220 --report-interval=10 --db-driver=mysql prepare
sysbench /usr/share/sysbench/oltp_read_only.lua --mysql-host=10.xxxx.160 --mysql-port=4000 --mysql-db=test --mysql-user=root --mysql-password='xxx' --table_size=500000 --tables=10 --threads=30 --time=2000 --report-interval=10 --db-driver=mysql run
宕机1台
一般宕机1台不用太担心，因为如上所说，region的多数副本存活，该重新选leader的重新选，该补follwer副本的也会在其他节点补充。
在宕机1台，leader还没有选举成功或者follwer副本还没有补充完毕时，又宕机1台，其实跟下面要讲的同时宕机2台的问题分析和处理方式一样。
通过sysbench的压测任务可以看出，上图中红框位置出现20s左右的QPS抖动(QPS由之前的平均1.2万降低到4千左右)，因为SQL正在访问的leader region节点发生故障，导致raft重新选举新leader后恢复正常，下面是tiup pd ctl命令来查看宕机tikv的store信息。
tiup ctl:v5.1.1 pd -u http://10.xxxxx.173:2379 store|grep -B 10 'Disconnected'
Starting component `ctl`: /home/tidb/.tiup/components/ctl/v5.1.1/ctl /home/tidb/.tiup/components/ctl/v5.1.1/ctl pd -u http://10.xxxxx.173:2379 store
{
"store": {
"id": 5,
"address": "10.xxxx.155:20160",
"version": "5.1.1",
"status_address": "10.xxxx.155:20180",
"git_hash": "4705d7c6e9c42d129d3309e05911ec6b08a25a38",
"start_timestamp": 1628479214,
"deploy_path": "/data6/deploy/tikv-20180/bin",
"last_heartbeat": 1646640368489894705,
"state_name": "Disconnected"
通过以上可以看到tikv状态为disconnected，在这里简单提下tikv的状态，正常启动就是UP状态，当tikv节点跟PD断开超过20s后转变为Disconnected状态，默认超过30分钟(max-store-down-time设定)后tikv转变为down状态，只有变为down状态，其他存活的tikv才会补该tikv节点的region副本。对于down的tikv我们scale-in后出现offline状态，一旦所有的region都正常后最终变为tombstone状态。
同时宕机2台
我们下面通过 rm -rf tikv-data 来暴力模拟故障，同时删除 2 个 tikv 的 data 来模拟5个tikv集群2个tikv宕机处理，看下集群当前情况：
再看下sysbench压测请求的QPS情况，从打印的日志明显看到有 tikv server timeout 和 region is unavailable 的报错,sysbench报错后续的QPS已经变0。
下面开始进行tikv集群的恢复，操作步骤如下：
（1）使用tiup ctl pd(同之前的pd-ctl命令)来查看下 Tikv 哪些store id不可用了，发现是store 1和6。
tiup ctl:v5.1.1 pd -u http://xxxx:2379 store|grep -B 10 'Disconnected'
{
"store": {
"id": 6,
"address": "10.xxxx.201:20160",
"version": "5.1.1",
"state_name": "Disconnected"
--
{
"store": {
"id": 1,
"address": "10.xxxx.218:20160",
"version": "5.1.1",
"state_name": "Disconnected"
（2）PD调度关闭，避免恢复过程中产生的各种异常情况，对了，在将下面的参数调整为0之前，建议先tiup ctl pd config show看下之前的参数值为多少，另外使用tiup ctl时需要选择跟tidb集群版本一致的ctl version。
$ tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 config set region-schedule-limit 0
$ tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 config set replica-schedule-limit 0
$ tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 config set leader-schedule-limit 0
$ tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 config set merge-schedule-limit 0
$ tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 operator show
[]
通过上面的命令可以看到调度已经关闭。
（3）停止其他UP状态的tikv,目的避免新的写入导致的region副本之间的元信息不一致，另外就是释放文件锁。
tiup cluster stop BA-xxxx_bak -R tikv
如果上面命令停不掉，可以登录到tikv节点使用systemctl stop tikv-20160停掉tikv
（4）在刚才关闭的每个tikv节点，使用tikv-ctl强制region从多副本失效的状态恢复，unsafe-recover remove-fail-stores 命令可以将故障机器从指定 Region 的 peer 列表中移除。运行命令之前，需要目标 TiKV 先停掉服务以便释放文件锁（否则执行tikv-ctl恢复时有下面的报错）。
[2022/03/14 17:51:54.215 +08:00] [ERROR] [main.rs:78] ["error while open kvdb: Storage Engine IO error: While lock file: /data6/tikv-20180/db/LOCK: Resource temporarily unavailable"]
[2022/03/14 17:51:54.215 +08:00] [ERROR] [main.rs:81] ["LOCK file conflict indicates TiKV process is running. Do NOT delete the LOCK file and force the command to run. Doing so could cause data corruption."]
tikv-ctl的-s 选项是指宕机的多个以逗号分隔的 store_id (本次实验为1和6)，可以使用 -r 后面跟多个逗号分隔的Region id来指定要移除的peer，如果集群过大，需要移除的region id太多了，可简单指定 --all-regions 来对存活 store 上的全部 Region 都执行这个操作。
将跟集群版本适配的tikv-ctl拷贝到存活tikv节点
scp /home/tidb/.tiup/components/ctl/v5.1.1/tikv-ctl tidb@10.xxxx.155:/home/tidb
scp /home/tidb/.tiup/components/ctl/v5.1.1/tikv-ctl tidb@10.xxxx.208:/home/tidb
scp /home/tidb/.tiup/components/ctl/v5.1.1/tikv-ctl tidb@10.xxxx.238:/home/tidb
在每个存活tikv节点都执行下面的tikv-ctl命令(注意要在tikv stop的情况下)
$ ./tikv-ctl --data-dir /data6/tikv-20180 unsafe-recover remove-fail-stores -s 6,1 --all-regions
[2022/03/10 16:20:40.987 +08:00] [INFO] [mod.rs:118] ["encryption: none of key dictionary and file dictionary are found."]
[2022/03/10 16:20:40.987 +08:00] [INFO] [mod.rs:479] ["encryption is disabled."]
[2022/03/10 16:20:41.032 +08:00] [WARN] [config.rs:581] ["compaction guard is disabled due to region info provider not available"]
[2022/03/10 16:20:41.032 +08:00] [WARN] [config.rs:675] ["compaction guard is disabled due to region info provider not available"]
removing stores [6, 1] from configurations...
[2022/03/10 16:20:41.236 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 1722 store_id: 5]"] [old_peers="[id: 1722 store_id: 5, id: 2111 store_id: 6, id: 2117 store_id: 1]"] [region_id=18]
[2022/03/10 16:20:41.236 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 1982 store_id: 5]"] [old_peers="[id: 1944 store_id: 1, id: 1982 store_id: 5, id: 2119 store_id: 6]"] [region_id=26]
[2022/03/10 16:20:41.236 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 1858 store_id: 5]"] [old_peers="[id: 1858 store_id: 5, id: 2108 store_id: 6, id: 2113 store_id: 1]"] [region_id=38]
[2022/03/10 16:20:41.236 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 1717 store_id: 5]"] [old_peers="[id: 1717 store_id: 5, id: 2110 store_id: 6, id: 2115 store_id: 1]"] [region_id=46]
[2022/03/10 16:20:41.236 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 1859 store_id: 5]"] [old_peers="[id: 1859 store_id: 5, id: 2112 store_id: 6, id: 2114 store_id: 1]"] [region_id=1009]
.....此处省略N行
[2022/03/10 16:20:41.237 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 1880 store_id: 7, id: 1881 store_id: 5]"] [old_peers="[id: 1880 store_id: 7, id: 1881 store_id: 5, id: 1887 store_id: 1]"] [region_id=1879]
[2022/03/10 16:20:41.237 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 1884 store_id: 7, id: 1886 store_id: 5, id: 2107 store_id: 4]"] [old_peers="[id: 1884 store_id: 7, id: 1886 store_id: 5, id: 2107 store_id: 4]"] [region_id=1883]
success
注意：--all-regions是需要在所有store节点上执行的。另外就是使用了remove-fail-store参数后，已经被移除的节点(故障tikv节点)一定不能再加入集群，否则会导致PD元信息不一致。
(5)恢复pd调度配置
$ tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 config set region-schedule-limit 2048
$ tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 config set replica-schedule-limit 64
$ tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 config set leader-schedule-limit 4
$ tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 config set merge-schedule-limit 8
(6) 启动tikv集群，我这里是通过-R指定所有tikv重启，其实建议-N 指定之前状态正常的3个tikv节点启动。
tiup cluster start BA-analyse-tidb_shyc_bak -R tikv
启动过程出现报错，因为无论是我模拟的tikv data目录被删，亦或是硬盘故障，主机宕机等，还是之前的store id为1和6的tikv启动失败，通过tiup cluster display 查看还是有3个tikv节点启动成功的，不影响业务正常使用，通过继续跑sysbench和count全表，没有出现读写和表数据丢失问题。下图是随便找了2张table查看数据量也是50w，跟之前sysbench导入的数据量一致。
mysql> select count(1) from sbtest10;
+----------+
| count(1) |
+----------+
| 500000 |
+----------+
1 row in set (0.41 sec)
mysql> select count(1) from sbtest3;
+----------+
| count(1) |
+----------+
| 500000 |
+----------+
1 row in set (0.41 sec)
集群现状：
（7）后续处理：本次的事故模拟是通过rm -rf tikv-data目录来实现的，并且没有从PD的store信息里删除已经down的store id：1和6，所以上面的tikv重启操作默认会在“误操作”的tikv节点重新创建目录和启动tikv，但是启动不成功，提示duplicated store address，“新的tikv”跟老的tikv都是同一个ip和端口，自然启动不成功，报错如下：
[2022/03/10 17:00:21.320 +08:00] [ERROR] [util.rs:460] ["request failed"] [err_code=KV:PD:gRPC] [err="Grpc(RpcFailure(RpcStatus { code: 2-UNKNOWN, message: \"duplicated store address: id:1194100 address:\\\"10.218.93.201:20160\\\" version:\\\"5.1.1\\\" status_address:\\\"10.218.93.201:20180\\\" git_hash:\\\"4705d7c6e9c42d129d3309e05911ec6b08a25a38\\\" start_timestamp:1646902817 deploy_path:\\\"/data6/deploy/tikv-20180/bin\\\" , already registered by id:6 address:\\\"10.218.93.201:20160\\\" version:\\\"5.1.1\\\" status_address:\\\"10.218.93.201:20180\\\" git_hash:\\\"4705d7c6e9c42d129d3309e05911ec6b08a25a38\\\" start_timestamp:1628479259 deploy_path:\\\"/data6/deploy/tikv-20180/bin\\\" last_heartbeat:1646897290357034075 \", details: [] }))
解决方案：pd元信息删除原来的store id，然后再重启下2个被rm又重新加入集群的“新节点”
$ tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 store delete 1
$ tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 store delete 6
$ tiup cluster start BA-analyse-tidb_shyc_bak -N 10.xxxx.218:20160
$ tiup cluster start BA-analyse-tidb_shyc_bak -N 10.xxxx.201:20160
到目前，整个集群又恢复到5个tikv完全可用的情况了，本次模拟了5个tikv节点中2个tikv数据被删除的情况下，如何恢复数据的方式和方法。
宕机3台
这次玩大的，5台机器，直接shutdown 3个tikv节点的服务器，模拟硬件故障启动不起来。
处理步骤还是跟上面2KV宕机的步骤类似(但还是有不同)
（1）pd ctl查看宕机的store id，发现是1，2，8
tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 store|grep -B 10 'Disconnected'
（2）PD调度关闭，避免恢复过程中产生的各种异常情况。
（3）检查大于等于一半副本数在故障节点上的region
tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 region --jq='.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total | map(if .==(2,8,1) then . else empty end) | length>=$total-length)}'
{"id":199,"peer_stores":[8,2,5]}
{"id":677,"peer_stores":[11,1,8]}
{"id":736,"peer_stores":[2,1,5]}
{"id":14,"peer_stores":[8,2,1]}
{"id":48,"peer_stores":[1,2,5]}
{"id":52,"peer_stores":[8,2,1]}
{"id":756,"peer_stores":[1,8,11]}
{"id":46,"peer_stores":[8,2,1]}
.....此处省略N行
{"id":175,"peer_stores":[2,1,8]}
{"id":203,"peer_stores":[1,8,2]}
{"id":211,"peer_stores":[8,5,2]}
{"id":22,"peer_stores":[2,1,11]}
{"id":36,"peer_stores":[8,2,5]}
{"id":730,"peer_stores":[5,8,1]}
{"id":611,"peer_stores":[8,11,1]}
{"id":58,"peer_stores":[8,2,1]}
{"id":131,"peer_stores":[2,1,11]}
{"id":18,"peer_stores":[8,5,2]}
{"id":30,"peer_stores":[2,1,11]}
大家可以看到region id 为 52、46、175、58的3个副本都丢失了(leader和2个follower都在宕机的3个tikv节点，如果3个tikv都无法启动或者恢复，那这4个region的数据就丢了)。另外还有不少只剩下1个peer的region id，比如199、677、736等只丢了2个副本(还剩1个peer，数据可以找回)。
（4）使用tiup cluster stop -N 来关闭存活的2个tikv
(5) 在所有未宕机的tikv节点,对所有region移除故障节点的peer。
./tikv-ctl --data-dir /data6/tikv-20180/ unsafe-recover remove-fail-stores -s 2,8,1 --all-regions
[2022/03/14 20:16:22.059 +08:00] [INFO] [mod.rs:118] ["encryption: none of key dictionary and file dictionary are found."]
[2022/03/14 20:16:22.060 +08:00] [INFO] [mod.rs:479] ["encryption is disabled."]
[2022/03/14 20:16:22.104 +08:00] [WARN] [config.rs:581] ["compaction guard is disabled due to region info provider not available"]
[2022/03/14 20:16:22.104 +08:00] [WARN] [config.rs:675] ["compaction guard is disabled due to region info provider not available"]
removing stores [2, 8, 1] from configurations...
[2022/03/14 20:16:25.909 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 298 store_id: 5]"] [old_peers="[id: 298 store_id: 5, id: 460 store_id: 8, id: 838 store_id: 2]"] [region_id=3]
[2022/03/14 20:16:25.909 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 795 store_id: 5]"] [old_peers="[id: 13 store_id: 1, id: 755 store_id: 2, id: 795 store_id: 5]"] [region_id=12]
[2022/03/14 20:16:25.909 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 829 store_id: 5]"] [old_peers="[id: 83 store_id: 8, id: 686 store_id: 2, id: 829 store_id: 5]"] [region_id=16]
[2022/03/14 20:16:25.909 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 789 store_id: 5, id: 940 store_id: 11 role: Learner]"] [old_peers="[id: 715 store_id: 8, id: 789 store_id: 5, id: 836 store_id: 2, id: 940 store_id: 11 role: Learner]"] [region_id=18]
........此处省略N行
[2022/03/14 20:16:25.910 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 447 store_id: 11, id: 688 store_id: 5]"] [old_peers="[id: 445 store_id: 2, id: 447 store_id: 11, id: 688 store_id: 5]"] [region_id=444]
[2022/03/14 20:16:25.910 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 633 store_id: 5]"] [old_peers="[id: 633 store_id: 5, id: 778 store_id: 1, id: 827 store_id: 2]"] [region_id=632]
[2022/03/14 20:16:25.910 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 731 store_id: 5]"] [old_peers="[id: 731 store_id: 5, id: 732 store_id: 8, id: 825 store_id: 1]"] [region_id=730]
[2022/03/14 20:16:25.910 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 818 store_id: 5]"] [old_peers="[id: 737 store_id: 2, id: 745 store_id: 1, id: 818 store_id: 5]"] [region_id=736]
[2022/03/14 20:16:25.910 +08:00] [INFO] [debug.rs:586] ["peers changed"] [new_peers="[id: 750 store_id: 11, id: 751 store_id: 5]"] [old_peers="[id: 750 store_id: 11, id: 751 store_id: 5, id: 773 store_id: 8]"] [region_id=749]
success
注意：因为是5个KV宕机3台，需要在stop tikv server的剩余2台tikv都执行。
(6)重启2个存活的tikv
(7)再次查看多数副本在宕机的3台tikv上的region，发现就剩下这些3个副本都丢失的region了
tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 region --jq='.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total | map(if .==(2,8,1) then . else empty end) | length>=$total-length)}'
Starting component `ctl`: /home/tidb/.tiup/components/ctl/v5.1.1/ctl /home/tidb/.tiup/components/ctl/v5.1.1/ctl pd -u http://10.xxxxx:2379 region --jq=.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total | map(if .==(2,8,1) then . else empty end) | length>=$total-length)}
{"id":52,"peer_stores":[8,2,1]}
{"id":46,"peer_stores":[8,2,1]}
{"id":28,"peer_stores":[8,2,1]}
{"id":203,"peer_stores":[1,8,2]}
{"id":175,"peer_stores":[2,1,8]}
{"id":58,"peer_stores":[8,2,1]}
{"id":14,"peer_stores":[8,2,1]}
（8）查看这些region id所属的table，下面拿203这个region id来查看，发现是属于test库的sbtest5表，需要查看下所有3个副本都丢失的region都属于哪些表，有时候涉及的region过多，可以搞个小脚本批量执行，执行结果都汇总到一个文本中，以便后续补数和业务沟通，这种情况是：反正数据已经丢了，避免业务访问到这些reigon的报错，需要跟业务沟通是否用空region代替，后续通过业务或者其他方式找回。
curl http://10.xxxx.160:10086/regions/203
{
"start_key": "dIAAAAAAAAA9X3KAAAAAAARH7A==",
"end_key": "dIAAAAAAAABF",
"start_key_hex": "74800000000000003d5f7280000000000447ec",
"end_key_hex": "748000000000000045",
"region_id": 203,
"frames": [
{
"db_name": "test",
"table_name": "sbtest5",
"table_id": 61,
"is_record": true,
"record_id": 280556
}
]
}
(9)再次关停存活的2个tikv并且在这2个tikv上补这种3个副本都丢了的region，用空region补充这些peer副本。
./tikv-ctl --data-dir /data6/tikv-20180/ recreate-region -p 10.xxxxx:2379 -r 52
./tikv-ctl --data-dir /data6/tikv-20180/ recreate-region -p 10.xxxxx:2379 -r 46
注意：补空region时 -r 命令后不能带多个逗号分隔的region id，只能一个region一个region的补，如果region id过多，可以考虑搞个脚本来跑。
(10)恢复pd调度配置
（11）重启2个tikv，再次查看region情况，发现所有的region的多数副本都已经正常。
tiup ctl:v5.1.1 pd -u http://10.xxxxx:2379 region --jq='.regions[] | {id: .id, peerstores: [.peers[].storeid] | select(length as $total | map(if .==(2,8,1) then . else empty end) | length>=$total-length)}'
(12) 登录查看数据，通过上面的第5步骤的region丢失来看查看，统计发现sbtest5/sbtest6表丢失了近1半的记录，其他数据表有完整数据的。
mysql> select count(1),count(c) from sbtest5;
+----------+----------+
| count(1) | count(c) |
+----------+----------+
| 280555 | 280555 |
+----------+----------+
1 row in set (0.35 sec)
mysql> select count(1),count(c) from sbtest6;
+----------+----------+
| count(1) | count(c) |
+----------+----------+
| 247312 | 247312 |
+----------+----------+
1 row in set (0.27 sec)
mysql> select count(1),count(c) from sbtest1;
+----------+----------+
| count(1) | count(c) |
+----------+----------+
| 500000 | 500000 |
+----------+----------+
1 row in set (0.38 sec)
目前集群状态：
总结和思考
总结
本篇文章主要讲了tikv节点宕机时的现象以及如何恢复的方案，tikv 3副本的 raft group能保证在宕机一台KV时不用DBA立刻介入的能力；在上面宕机 2 台 KV 时，因为根据PD的调度规则，一个raft group的peer肯定会调度到3个KV节点，所以2个KV宕机，肯定还有一个peer在，需要DBA介入，并且使用“快刀斩乱麻”的tikv-ctl尽快的恢复了集群；但是在集群宕机 3 台 KV 时就有大概率的数据丢失，这时候就需要考虑业务恢复重要还是数据保护重要了，另外在3个kv宕机的章节，我还重启了2次tikv，其实如果定好了预案，清理region中故障store的peer跟 recreate 空region可以一起做，本次只是突出region丢失数据的严重性。
另外以上是基于5个KV的集群做的多次验证，每次都出了不少的“状况”，可以根据文章的大概处理流程自己模拟验证，其实我遇到一个“严重”的“状况”是：5副本的KV当挂了3个时，可能一些mysql系统表(比如user权限表)的region也“丢失”了，导致无法进入到集群验证数据，后来通过：跟mysql类似的skip-grant-table才进入，如果用户权限都没有了，业务肯定都无法连接tidb了，这种情景就是要强调：在我没有BR备份的情况下，5个节点(3kv宕机)能给我恢复出2个kv数据的重要性了。
还有一个就是补完空region，还遇到了一些诡异的“数据准确性”问题，比如sbtest5表的默认索引k5索引被补了空region时，idxk是我重新建立的索引。通过2个索引的查询结果是不一样的，也就是说补region影响了数据的正确性，不过对于上面的集群多数KV不可用的情况下，还是建议新建集群然后将2个KV的数据恢复到新集群。
mysql> show create table sbtest5\G
*************************** 1. row ***************************
Table: sbtest5
Create Table: CREATE TABLE `sbtest5` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`k` int(11) NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */,
KEY `k_5` (`k`),
KEY `idx_k` (`k`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=633209
1 row in set (0.00 sec)
mysql> select * from sbtest5 use index(k_5) where k=249602;
ERROR 1105 (HY000): inconsistent index k_5 handle count 99 isn't equal to value count 66
mysql>
mysql> select count(1) from sbtest5 use index(idx_k) where k=249602;
+----------+
| count(1) |
+----------+
| 66 |
+----------+
1 row in set (0.00 sec)
mysql> select count(1) from sbtest5 use index(idx_k);
+----------+
| count(1) |
+----------+
| 280555 |
+----------+
1 row in set (0.20 sec)
mysql> select count(1) from sbtest5 use index(k_5);
+----------+
| count(1) |
+----------+
| 500000 |
+----------+
1 row in set (0.27 sec)
思考：
（1） 在集群多tikv(>=3)不可用的时候，需要根据业务情况做好降级准备，最好在sql接入层（HAproxy/lvs）先把vip下线，避免新流量写入，毕竟后面tikv-ctl操作涉及到tikv所有节点的shutdown。
（2）以上的测试都是基于默认的 3 副本来分析的，对于多 KV 的核心集群，其实可以设定 5 副本来增加集群的可用性。
（3）关闭PD调度和避免宕机tikv重启的重要性，避免元信息异常引发的region不可用
（4）tikv真的不可以恢复后的补region的决定，需要根据实际情况来定，另外一定要看下补的region都是哪些业务的什么table or index，注意观察下“修复”后数据的准确性。
（5）做好TiDB的备份，如果真的线上集群不可用，至少还有备份可以恢复，就看备份的频度（容忍丢失的数据量），一旦集群多数KV不可用，需要”2条腿“走路，1个方案是BR恢复备份到新集群，另外就是在原有集群进行tikv-ctl的恢复。
（6）“多活”方案的重要性，比如基于ticdc的主备同城双机房，备机房可以做一些准实时的读请求(读写分离)；另外就是 tidb 5.4 版本提供的同城双中心自适应同步模式；其他同城3中心或者异地3中心的方案可以参考官方文档。
（7）同一个集群同时3个tikv宕机的概率还是比较低的，除非就是部署时没有考虑机架或者交换机部署，由于机架掉电或者交换机故障导致的多KV的不可用，这是就要看业务是否能扛或者IDC换件的应急速度了。
本文到此就结束了，最后想说的是，每次都是靠人工模拟故障，是不是太low了，要不要用下chaos mash？OK，下一篇分享就又有的写了。哈哈