作者：代晓磊
原文来源： 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
