[Err] 9005 - Region is unavailable、[Err] 9001 - PD server timeout-加急

[普罗米修斯]

【 TiDB 使用环境】生产环境
【 TiDB 版本】TiDB v3.0.3
【遇到的问题】使用sql语句时集群访问异常，报[Err] 9005 - Region is unavailable、[Err] 9001 - PD server timeout”
【复现路径】
1.下线两块kv节点，下线了1周到最后使用tikv-ctl将其改为墓碑状态，但是里面还有56个region-count无法正常移除；
2.集群里面还有两个kv节点处于down状态，一个tikv日志中报last index < Applied index ，另一个因为与这个kv节点接口相互依赖无法启动；
3.使用unsafe-recover remove-fail-stores移除两个down节点上tikv的bad-regions，移除了一部分，还有40个无法移除；因为region里面的副本有的包含了设置为墓碑模式kv节点上的peer；
【问题现象及影响】
1.数据库sql语句执行报错[Err] 9005 - Region is unavailable、[Err] 9001 - PD server timeout”

【附件】

“regions”: [
{
“id”: 24567918,
“start_key”: “7480000000000000FF6B5F698000000000FF0000010380000000FF0000006101484E30FF3732303533FF314DFF425232562626FF33FF30302D31303030FFFF5F56524D53000000FFFC03800000000000FF03450419A6B41547FF00000001484E3037FF32303533FF310000FF0000000000F80000FD”,
“end_key”: “7480000000000000FF6B5F698000000000FF0000010380000000FF0000006101484E30FF3732303533FF314EFF41434E554C48FF26FF26302D31303030FFFF5F4C460000000000FFFA03800000000000FF034A0419A6A93EEFFF00000001484E3037FF32303533FF310000FF0000000000F80000FD”,
“epoch”: {
“conf_ver”: 1261,
“version”: 73
},
“peers”: [
{
“id”: 61333959,
“store_id”: 39485340
},
{
“id”: 61831614,
"store_id": 13585107
},
{
“id”: 62153411,
"store_id": 61971239
}
]
},

例如这个region，61971239是down的节点，13585107是设置为墓碑模式的节点，39485340是正常up的store，麻烦问下怎么清除这种bad-region？

[普罗米修斯]

还有部分region情况更不容乐观
“regions”: [
{
“id”: 53858501,
“start_key”: “7480000000000000FF6B5F698000000000FF00000301484E3037FF32303533FF324D42FF5232480000FD0380FF0000014A28449400FE”,
“end_key”: “7480000000000000FF6B5F698000000000FF00000301484E3037FF32303533FF324D42FF5232480000FD0380FF0000033E22166900FE”,
“epoch”: {
“conf_ver”: 1387,
“version”: 72
},
“peers”: [
{
“id”: 60328806,
“store_id”: 22010754
},
{
“id”: 62116511,
“store_id”: 61971239
},
{
“id”: 62129903,
“store_id”: 62119544
}
]
}
这个region，61971239是down的节点，62119544是down的节点，22010754是设置为墓碑模式下线的节点；
1.这种region怎么清除？
2.还有已经设置为墓碑模式下线的节点，在pd层面使用pd-ctl还能看见它的region，怎么清除已经下线的kv的region？

[Aric (Jansu Dev)]

1.这种region怎么清除？ → 可以接受丢数据吗？如果可以,unsafe recover

1. 在 pd-ctl 中暂定如下调度
scheduler pause balance-leader-scheduler
scheduler pause balance-region-scheduler
scheduler pause balance-hot-region-scheduler
config set replica-schedule-limit 0

2. 使用 pd-ctl 检查大于等于一半副本数在故障节点上的 Region 
要求：PD 处于运行状态
假设故障节点为 15,22,43,45,46
pd-ctl -u <endpoint> -d region --jq=’.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total | map(if .==(15,22,43,45,46) then . else empty end) | length>=$total-length) }’


3. 在所有正常的 tikv 实例上，对所有 Region 移除掉所有位于故障节点上的 Peer
要求：在所有未发生故障的机器上运行，需要关闭 TiKV 节点
## tikv-ctl --db /path/to/tikv-data/db unsafe-recover remove-fail-stores -s <s1,s2,....> --all-regions
这里 store id 为 30725906
tikv-ctl --db /path/to/tikv-data/db unsafe-recover remove-fail-stores -s 30725906 --all-regions

4. 使用 pd-ctl 检查没有 Leader 的 Region  
要求：PD 处于运行状态
pd-ctl -u <endpoint> -d region --jq '.regions[]|select(has("leader")|not)|{id: .id, peer_stores: [.peers[].store_id]}'

5. 启动 tikv

6. 检查数据索引一致性
要求：PD、TiKV、TiDB 处于运行状态，例如：
select count(*) from table as c1;
select count(*) from table force index `idx_name` as c2;
select c1 = c2;

2. 还有已经设置为墓碑模式下线的节点，在pd层面使用pd-ctl还能看见它的region，怎么清除已经下线的kv的region？–> 在处理完 1 操作后，Tombstone ：表示该 TiKV Store 已处于完全下线状态，可以使用 remove-tombstone 接口安全地清理该状态的 TiKV。 from https://docs.pingcap.com/zh/tidb/stable/tidb-scheduling#信息收集 具体操作 → https://docs.pingcap.com/zh/tidb/stable/pd-control#store-delete--cancel-delete--label--weight--remove-tombstone--limit--store_id---jqquery-string
   
   

[普罗米修斯]

上周五已经处理完成了，基本也是按照上面的操作执行的，不一样的地方是store remove-tombstone执行后，某些region里面的peer还存在下线后的peer。
在所有kv节点上unsafe recover指定墓碑模式的region，重启kv后集群恢复正常了。

[Aric (Jansu Dev)]

ok！！！