tiup目录冲突检测不健全导致的节点被destroy问题以及解决

(1)环境以及前提:
集群是有tidb-ansible-3.1.0 import到tiup(V1.0.0)管理,并且升级集群到V4.0GA版本。
3.1以及之前的tidb版本tidb server和PD都是共用同一部署目录。
(2)操作流程以及问题现象:
为了测试,使用tiup在一台tikv节点扩容了tidb server,扩容tidb时将部署目录跟tikv的目录设定一致,部署成功(其实如果tiup初始化集群,tidb跟tikv不可用共用目录的,会报错),测试完毕,执行缩容tidb server操作,发现同目录的tikv也一并被删除(tiup缩容的最后一步是删除目录)。
问题产生了:由于缩容tidb,竟然将同目录的tikv也一并干掉了。
(3)上面是一个问题,已经提交了issue,官方正在修改,详见:https://github.com/pingcap/tiup/pull/502 这个 pr

故事还没有结束,新的问题产生:
(4)在进行了缩容的情况下。又将之前被删除掉的tikv节点扩容到集群,但是由于tiup的元信息更新不及时(已经确认了该问题),在执行tiup cluster display查看集群信息时,将刚扩容OK的该tikv节点又干掉了。
注意:172.10.164.164这个tikv节点是up并且正常提供服务,然后后面触发了destroy,并且干掉了该tikv目录数据

$ tiup cluster display test-tidb
Starting component cluster: /home/tidb/.tiup/components/cluster/v1.0.0/cluster display BA-analyse-tidb
TiDB Cluster: BA-analyse-tidb
TiDB Version: v4.0.0
ID Role Host Ports OS/Arch Status Data Dir Deploy Dir


172.10.41.21:9093 alertmanager 172.10.41.21 9093/9094 linux/x86_64 Up /data/deploy/data.alertmanager /data/deploy
172.10.41.21:3000 grafana 172.10.41.21 3000 linux/x86_64 Up - /data/deploy
172.10.41.21:2379 pd 172.10.41.21 2379/2380 linux/x86_64 Healthy /data/deploy/data.pd /data/deploy
172.10.44.145:2379 pd 172.10.44.145 2379/2380 linux/x86_64 Healthy|L /data/deploy/data.pd /data/deploy
172.10.44.173:2379 pd 172.10.44.173 2379/2380 linux/x86_64 Healthy /data/deploy/data.pd /data/deploy
172.10.41.21:9090 prometheus 172.10.41.21 9090 linux/x86_64 Up /data/deploy/prometheus2.0.0.data.metrics /data/deploy
172.10.41.21:4000 tidb 172.10.41.21 4000/10080 linux/x86_64 Up - /data/deploy
172.10.44.145:4000 tidb 172.10.44.145 4000/10080 linux/x86_64 Up - /data/deploy
172.10.44.173:4000 tidb 172.10.44.173 4000/10080 linux/x86_64 Up - /data/deploy
172.10.164.164:20160 tikv 172.10.164.164 20160/20180 linux/x86_64 Up /data/deploy/data /data/deploy
172.10.164.99:20160 tikv 172.10.164.99 20160/20180 linux/x86_64 Up /data/deploy/data /data/deploy
172.10.178.139:20160 tikv 172.10.178.139 20160/20180 linux/x86_64 Up /data/deploy/data /data/deploy
172.10.178.141:20160 tikv 172.10.178.141 20160/20180 linux/x86_64 Up /data/deploy/data /data/deploy
172.10.179.76:20160 tikv 172.10.179.76 20160/20180 linux/x86_64 Up /data/deploy/data /data/deploy
Start destroy Tombstone nodes: [172.10.164.164:20160] …
Stopping component tikv
Stopping instance 172.10.164.164
Stop tikv 172.10.164.164:20160 success
Destroying component tikv
Destroying instance 172.10.164.164
Deleting paths on 172.10.164.164: /data/deploy/data /data/deploy /data/deploy/log /etc/systemd/system/tikv-20160.service
Destroy success

解决方案:

1、为了加快由于宕机导致的副本补充速度,在不影响业务的情况下,调整下面的参数,默认8,
./pd-ctl -u http://172.10.41.22:2379 config set replica-schedule-limit 16

2、及时查看被删除掉的tikv的状态,一般会经历offline->down->Tombstone(Tombstone状态代表节点下线完成)
/home/tidb/tidb-ansible-3.1.0/resources/bin/pd-ctl -u http://172.10.41.21:2379 -d store|grep -B 3 -A 10 ‘172.10.164.164’
{
“store”: {
“id”: 1149899,
“address”: “172.10.164.164:20160”,
“version”: “4.0.0”,
“status_address”: “172.10.164.164:20180”,
“git_hash”: “198a2cea01734ce8f46d55a29708f123f9133944”,
“start_timestamp”: 1592211025,
“deploy_path”: “/deploy/bin”,
“last_heartbeat”: 1592211102903808121,
“state_name”: “Down”
}

PS:也可以通过grafana的PD监控中region-healthy中的down-peer-region-count和offline-peer-region-count变为0就代表该tikv节点下线完成。

3、也可以通过接口来查看Tombstone状态的节点。
curl http://172.10.41.21:2379/pd/api/v1/stores?state=2
{
“count”: 1,
“stores”: [
{
“store”: {
“id”: 4,
“address”: “172.10.164.164:20160”,
“state”: 2,
“version”: “4.0.0”,
“status_address”: “172.10.164.164:20180”,
“git_hash”: “198a2cea01734ce8f46d55a29708f123f9133944”,
“start_timestamp”: 1591800801,
“last_heartbeat”: 1591931156459282772,
“state_name”: “Tombstone”
},

  ]
}

4、当tikv节点变成 tombstone 后,再次使用 tiup cluster display 看下这个节点,等这个节点 destroy ,并且 display 再也看不到这个节点后,再进行扩容操作


5、从PD信息中抹除tombstone的信息
/home/tidb/tidb-ansible-3.1.0/resources/bin/pd-ctl -u http://172.10.41.22:2379 store remove-tombstone

6、上面工作完毕后才可以再次用该节点扩容tikv,否则还可能有问题。

7、总结:
tiup 的元数据标记了这个节点要 destroy ,但是由于 tiup 的元数据没有更新,再次 display 的时候,触发了 destroy ,destroy 后 tiup 的元数据更新了,所以,后面再多次的 display 的时候,再也看不到这个节点信息,以及不再 destroy。后面扩容的时候:
(1)、缩容 scale-in tikv1
(2)、tiup cluster display,并且直到 display 不再显示这个被缩容的节点 tikv1
(3)、配合 pd-ctl store 以及 pd 监控面板 region health,来判断是否可以使用相同的 ip,port ,目录进行扩容
(4)、确认可扩容后,使用 tiup scale-out

4赞