tikv 一节点磁盘损坏，无法在使用，如何完整下线这个tikv 节点？

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】
【附件：截图/日志/监控】

昨天晚上线上一个V5.4.0 版本的 tidb 集群一个 tikv 节点(总共4个tikv 节点) 磁盘损坏，盘无法在挂载了，无法在使用，今天下午才发现这个tikv 节点已处于down 状态，初步排查： 业务正常，另外3个tikv 节点磁盘使用率增加（估计是数据已平衡过来）。 首先我执行了 stop 这个损坏tikv 节点，，正常success。 然后scale-in ，提示pending offline, 查了资料，执行scale-in --force ， display 是看不到这个损坏节点了，但是pd store 还是显示，状态为offline，执行了pd store delete xxx 这个tikv 节点id，但是还存在，请问要如何操作从pd 里面去除这个损坏的tikv 节点？

1 个赞
2

执行完force以后，pd store显示的是不是有个physical destroyed = true
如果这样的话，那没问题啊。直接新建就行了。

3

pdctl> store remove-tombstone
试试

4

现在这个损坏tikv 在pd 显示如下，没看到 physical destroyed = true

{
“store”: {
“id”: 226195121,
“address”: “xxxx:20160”,
“state”: 1,
“version”: “5.4.0”,
“status_address”: “xxxx:20180”,
“git_hash”: “b5262299604df88711d9ed4b84d43e9c507749a2”,
“start_timestamp”: 1673589464,
“deploy_path”: “/data1/tidb-deploy/tikv-20160/bin”,
“last_heartbeat”: 1680086231611976151,
“state_name”: “Offline”
},
“status”: {
“capacity”: “2.865TiB”,
“available”: “1.149TiB”,
“used_size”: “1.367TiB”,
“leader_count”: 0,
“leader_weight”: 1,
“leader_score”: 0,
“leader_size”: 0,
“region_count”: 43366,
“region_weight”: 1,
“region_score”: 3227273,
“region_size”: 3227273,
“slow_score”: 1,
“start_ts”: “2023-01-13T00:57:44-05:00”,
“last_heartbeat_ts”: “2023-03-29T05:37:11.611976151-05:00”,
“uptime”: “1804h39m27.611976151s”
}
}

5

这是正对状态为 tombstone的，你看我上面显示目前还在offline 状态

6

这里未归零，等集群无异常region再看看，可能其他节点的region3副本还没补完。

7

把offline的store的强制更新成tomestone,然后再remove-tombstone试试
curl -X POST http://{pd_ip}:2379/pd/api/v1/store/${store_id}/state?state=Tombstone

8

观察 “region_count”: 是否有减小的趋势，直到归 0 变为 tomestone 状态

可修改如下参数进行加速，x根据负载自行根据现在的数值调整：

config set region-schedule-limit x
config set replica-schedule-limit x
config set leader-schedule-limit x
config set max-pending-peer-count x
config set max-snapshot-count x
config set merge-schedule-limit x
1 个赞
9

ok，现在在慢慢变少，我等明天在观察下

10

ok，现在在慢慢变少，我等明天在观察下

11

估计是还没有下线完毕，region 要迁移，可以看下监控面板，等完全下线之后会变成tombstone

12

你说的这个curl -X POST http://{pd_ip}:2379/pd/api/v1/store/${store_id}/state?state=Tombstone
楼主可以试试，但我印象中这个操作不怎么可行，以前用过(原因是那版本的pd api已经不支持修改tombstone了，只能修改为up和offline)：

此类强制scale-in的操作造成的这种异象还是比较多的，我已经忘记是怎么处理了，汗。。。

13
  • Offline：当对某个 TiKV Store 通过 PD Control 进行手动下线操作，该 Store 会变为 Offline 状态。该状态只是 Store 下线的中间状态，处于该状态的 Store 会将其上的所有 Region 搬离至其它满足搬迁条件的 Up 状态 Store。当该 Store 的 leadercount 和 regioncount (在 PD Control 中获取) 均显示为 0 后，该 Store 会由 Offline 状态变为 Tombstone 状态。在 Offline 状态下，禁止关闭该 Store 服务以及其所在的物理服务器。下线过程中，如果集群里不存在满足搬迁条件的其它目标 Store（例如没有足够的 Store 能够继续满足集群的副本数量要求），该 Store 将一直处于 Offline 状态

我遇到过一个节点磁盘坏掉了，最后也变成了Tombstone

14

你操作了啥变成Tombstone的？

15

这个API已经不能用了

16

夜里坏的，白天数据已经平衡完毕了，自己变成Tombstone

17

是的，刚看了经过1天，状态也变成了Tombstone，然后我执行了remove-tombstone就从pd 完全移除了

18

经过你我这两次遭遇，可以看出tikv单点损坏不必着急，tidb 内部是会自我修复的

19

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。