还是一样的
./tikv-ctl --db /data/tidb-data/tikv-20160/db unsafe-recover remove-fail-stores -s 8009881,8009882,1,6 -r 9783357
removing stores [8009881, 8009882, 1, 6] from configurations…
Debugger::remove_fail_stores: “Store 8009882 in the failed list”
最后都remove_fail_stores: “Store 8009882 in the failed list”
8009882 这个先去掉 看看执行结果
执行是成功的，但是pt-ctl还是可以看到region的信息
./tikv-ctl --db /data/tidb-data/tikv-20160/db unsafe-recover remove-fail-stores -s 8009881,1,6 -r 9783357
removing stores [8009881, 1, 6] from configurations…
success
pd-ctl region 是啥结果，tikv起来了吗
还是和之前一样
» region 9783357
{
“id”: 9783357,
“start_key”: “7480000000000000FF375F698000000000FF0000040380000000FF0D2F659003800000FF0000000002038000FF00009043FDAD0000FD”,
“end_key”: “7480000000000008FF875F72FC00000019FF18E0020000000000FA”,
“epoch”: {
“conf_ver”: 8028,
“version”: 15791
},
“peers”: [
{
“id”: 9783358,
“store_id”: 8009882,
“role_name”: “Voter”
},
{
“id”: 9783359,
“store_id”: 6,
“role_name”: “Voter”
},
{
“id”: 9783360,
“store_id”: 8009881,
“role_name”: “Voter”
},
{
“id”: 10117142,
“store_id”: 1,
“role”: 1,
“role_name”: “Learner”,
“is_learner”: true
}
],
“leader”: {
“id”: 9783359,
“store_id”: 6,
“role_name”: “Voter”
},
“down_peers”: [
{
“down_seconds”: 1561,
“peer”: {
“id”: 9783360,
“store_id”: 8009881,
“role_name”: “Voter”
}
},
{
“down_seconds”: 334,
“peer”: {
“id”: 10117142,
“store_id”: 1,
“role”: 1,
“role_name”: “Learner”,
“is_learner”: true
}
}
],
“pending_peers”: [
{
“id”: 9783360,
“store_id”: 8009881,
“role_name”: “Voter”
},
{
“id”: 10117142,
“store_id”: 1,
“role”: 1,
“role_name”: “Learner”,
“is_learner”: true
}
],
“written_bytes”: 0,
“read_bytes”: 0,
“written_keys”: 0,
“read_keys”: 0,
“approximate_size”: 1,
“approximate_keys”: 0
}
pd-ctl store 8009882 看看这个
» store 8009882
{
“store”: {
“id”: 8009882,
“address”: “10.30.xx.xx:20160”,
“state”: 1,
“version”: “5.0.3”,
“status_address”: “10.30.xx.xx:20180”,
“git_hash”: “63b63edfbb9bbf8aeb875aad28c59f082eeb55d4”,
“start_timestamp”: 1678953424,
“deploy_path”: “/data/tidb-deploy/tikv-20160/bin”,
“last_heartbeat”: 1678958635970367203,
“state_name”: “Offline”
},
“status”: {
“capacity”: “992GiB”,
“available”: “922.1GiB”,
“used_size”: “88.44MiB”,
“leader_count”: 0,
“leader_weight”: 1,
“leader_score”: 0,
“leader_size”: 0,
“region_count”: 1,
“region_weight”: 1,
“region_score”: 1.6359387716434908,
“region_size”: 1,
“start_ts”: “2023-03-16T15:57:04+08:00”,
“last_heartbeat_ts”: “2023-03-16T17:23:55.970367203+08:00”,
“uptime”: “1h26m51.970367203s”
}
}
你看下8009882这个节点上的tikv进程是不是还在呢 。 再试试4个store都停了的 unsafe-recover , 这个估计已经是比较终极的手段了
8009881这个节点就是强制下线其中一个tikv节点，tiup cluster scale-in xxxx -N 10.30.xx.xx:20160 --force后的，
8009882这个节点上的tikv进程是没有的，状态是Pending Offline
1和6是两个在线的tikv节点
我下午就是全部停止了（实际上只有8009882和1,6这是哪个节点，8009881这个已经强制删除了），unsafe-recover没有效果的
tiup --force只是处理下集群拓扑信息 清理下tikv的bin目录，对于实际的集群下线没有任何帮助，tiup --force≠实际的集群缩容。 缩容的tikv再完成region转移后会变成tombstone状态，之后就可以remove-tombstone清理了，只要还有region信息再上面那么就会一直是offline状态。
能处理的命令基本就上面这些了 : region有leader就 add remove-peer，remove-peer不好使或者没有leader 就recreate region 或tombstone region 。 unsafe-recover 绝大多数情况都好使。
还有个命令： curl -X DELETE http://${HostIP}:2379/pd/api/v1/admin/cache/region/{region_id} 。这个是清理pd 侧的region信息，你这个场景估计不大管用。
上面这些命令你在都试几次吧
好的，多谢，我在试试吧，之前缩容过好几次，也没遇到过这种清不掉的情况
试试store 1 remove-peer 能成功不
这个问题已经解决了，最终的方法是，清理掉了pd中的region信息之后，pd中不存在了，tikv节点的状态就变成Tombstone了；多谢大佬辛苦指导
之前这个是通过什么方式看的？8009882 8009881 哪个是0的？
通过pd-clt和监控看的，8009882 8009881 这两个缩容的节点上，都是leader=0，region=1
pd-ctl region 看下现在region的状态
现在region 9783357已经查不到了
» region 9783357
null
» region store 8009881
{
“count”: 0,
“regions”: []
}
» region store 8009882
{
“count”: 0,
“regions”: []
}
请问是通过什么方式,清理掉了 pd 中的 region?
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。