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

系统运维 2023-10-13 穿过生命散发芬芳手机阅读

作者：代晓磊

原文来源： tidb.net/blog/b815da…

（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，官方正在修改，详见： github.com/pingcap/tiu…这个 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