如何在集群中完全清除一台离线的tikv服务

🪐 TiDB 技术问题 部署&运维管理
1

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【TiDB 版本】
v4.0.0

【问题描述】
在tidb集群中，使用tiup强制把其中一台tikv服务器下线后，请问如何在tidb集群中把该tikv服务器配置信息清除？如果不清除，无法加入新的tikv服务器到该集群中。

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

2

不会产生你说的问题的，建议你把现象描述一下

3

Starting component cluster: /home/tidb/.tiup/components/cluster/v1.2.5/tiup-cluster display hxgk-tidb
Cluster type: tidb
Cluster name: hxgk-tidb
Cluster version: v4.0.0
SSH type: builtin
ID Role Host Ports OS/Arch Status Data Dir Deploy Dir

172.16.21.162:9093 alertmanager 172.16.21.162 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093
172.16.21.162:3000 grafana 172.16.21.162 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000
172.16.21.159:2379 pd 172.16.21.159 2379/2380 linux/x86_64 Up|L|UI /tidb-data/pd-2379 /tidb-deploy/pd-2379
172.16.21.160:2379 pd 172.16.21.160 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379
172.16.21.161:2379 pd 172.16.21.161 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379
172.16.21.162:9090 prometheus 172.16.21.162 9090 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090
172.16.21.159:4000 tidb 172.16.21.159 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000
172.16.21.160:4000 tidb 172.16.21.160 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000
172.16.21.161:4000 tidb 172.16.21.161 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000
172.16.21.159:9000 tiflash 172.16.21.159 9000/8123/3930/20170/20292/8234 linux/x86_64 Up /tidb-data/tiflash-9000 /tidb-deploy/tiflash-9000
172.16.21.156:20160 tikv 172.16.21.156 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
172.16.21.157:20160 tikv 172.16.21.157 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160
172.16.21.158:20160 tikv 172.16.21.158 20160/20180 linux/x86_64 Offline /data/deploy/install/data/tikv-20160 /data/deploy/install/deploy/tikv-20160
Total nodes: 13

在这个集群中，如何把172.16.21.158 这台tikv server 从集群中清除掉？

4
  1. 是指缩容一个 TiKV 吗？ 这个 TiKV 已经离线，无法正常缩容？ 那么使用 --force 参数，强制删除。
  2. 如果以后这个节点恢复了，需要重新添加 TiKV 节点，需要手工清理目录。
5

嗯，请问如何清理目录？ 现在172.16.21.158 这台tikv系统重装了、数据都删除了，但加入hxgk-tidb时，使用tiup命令，提示连接超时。我查询资料有人说因为集群中 这台tikv的信息还在集群中没有清除造成的。请问该如何清除？谢谢！

6

参考文档命令 tiup cluster scale-in --node 10.0.1.5:20160 --force 加上 force 参数.
如果不清楚基础的命令，可以先看下官方文档.
https://docs.pingcap.com/zh/tidb/stable/scale-tidb-using-tiup#2-执行缩容操作

7

已经缩容了，现在是想再把服务器加入到集群中

8

172.16.21.158:20160 tikv 172.16.21.158 20160/20180 linux/x86_64 Offline /data/deploy/install/data/tikv-20160 /data/deploy/install/deploy/tikv-20160
看你显示的不是 offline 吗？ 没有缩容吧？

9

这是缩容后，再添加 出现的

11

缩容后，在dashboard中看状态还是 下线中，但通过tiup确看不到该服务器了。
然后把172.16.21.158这台服务器里面的数据目录都已清空，再通过tiup 加入该集群，提示连接超时。

image
image1347×737 41.9 KB

12

当您缩容以后，可以使用 pd-ctl 查看一下 store 的信息。如果这个 store 还是存在的话，可以使用 store delete 命令删除已经缩容的 store。删除之后重新扩容试一下。

13

image
image709×538 5.71 KB

通过store 命令删除提示成功，通过store命令查看，还存在，是什么原因呢？

14

目前这个 store = 5 的 region 数量在减少还是一直不变。

15

这台服务器系统重新安装过了，请问在哪里可以看到该服务器的region 数量？

16

一小时前的：
{
“store”: {
“id”: 5,
“address”: “172.16.21.158:20160”,
“state”: 1,
“version”: “4.0.0”,
“status_address”: “0.0.0.0:20180”,
“git_hash”: “198a2cea01734ce8f46d55a29708f123f9133944”,
“start_timestamp”: 1613893772,
“deploy_path”: “/tidb-deploy/tikv-20160/bin”,
“last_heartbeat”: 1621088012726278043,
“state_name”: “Offline”
},
“status”: {
“capacity”: “0B”,
“available”: “0B”,
“used_size”: “0B”,
“leader_count”: 0,
“leader_weight”: 1,
“leader_score”: 0,
“leader_size”: 0,
“region_count”: 38515,
“region_weight”: 1,
“region_score”: 2565926,
“region_size”: 2565926,
“start_ts”: “2021-02-21T15:49:32+08:00”,
“last_heartbeat_ts”: “2021-05-15T22:13:32.726278043+08:00”,
“uptime”: “1998h24m0.726278043s”
}
}
]
}

现在的：
“store”: {
“id”: 5,
“address”: “172.16.21.158:20160”,
“state”: 1,
“version”: “4.0.0”,
“status_address”: “0.0.0.0:20180”,
“git_hash”: “198a2cea01734ce8f46d55a29708f123f9133944”,
“start_timestamp”: 1613893772,
“deploy_path”: “/tidb-deploy/tikv-20160/bin”,
“last_heartbeat”: 1621088012726278043,
“state_name”: “Offline”
},
“status”: {
“capacity”: “0B”,
“available”: “0B”,
“used_size”: “0B”,
“leader_count”: 0,
“leader_weight”: 1,
“leader_score”: 0,
“leader_size”: 0,
“region_count”: 38525,
“region_weight”: 1,
“region_score”: 2566689,
“region_size”: 2566689,
“start_ts”: “2021-02-21T15:49:32+08:00”,
“last_heartbeat_ts”: “2021-05-15T22:13:32.726278043+08:00”,
“uptime”: “1998h24m0.726278043s”
}
},

17

你好，你这个问题我测试了一下，现在可以用以下方式操作下

  • 1.把 offline 状态的节点修改成 Tombstone 状态，curl -X POST http://{pd_ip}:2379/pd/api/v1/store/${store_id}/state?state=Tombstone

  • 2.再次查看 store 信息，看下是否还存在 offline 的这个节点？

另外 3 个 tikv 缩容 1 个，offline 状态是不会变成 tombstone 的。这个可以在 asktug 上搜索一下。

18

问题已解决，非常感谢！

19

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