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

2022 年 7 月 11 日
本文字数：2549 字
阅读完需：约 8 分钟

作者：代晓磊 _Mars 原文来源：https://tidb.net/blog/b815da66

（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 ⁹⁰⁹³⁄₉₀₉₄ 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 ²³⁷⁹⁄₂₃₈₀ linux/x86_64 Healthy /data/deploy/data.pd /data/deploy

172.10.44.145:2379 pd 172.10.44.145 ²³⁷⁹⁄₂₃₈₀ linux/x86_64 Healthy|L /data/deploy/data.pd /data/deploy

172.10.44.173:2379 pd 172.10.44.173 ²³⁷⁹⁄₂₃₈₀ 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 ⁴⁰⁰⁰⁄₁₀₀₈₀ linux/x86_64 Up - /data/deploy

172.10.44.145:4000 tidb 172.10.44.145 ⁴⁰⁰⁰⁄₁₀₀₈₀ linux/x86_64 Up - /data/deploy

172.10.44.173:4000 tidb 172.10.44.173 ⁴⁰⁰⁰⁄₁₀₀₈₀ linux/x86_64 Up - /data/deploy

172.10.164.164:20160 tikv 172.10.164.164 ²⁰¹⁶⁰⁄₂₀₁₈₀ linux/x86_64 Up /data/deploy/data /data/deploy

172.10.164.99:20160 tikv 172.10.164.99 ²⁰¹⁶⁰⁄₂₀₁₈₀ linux/x86_64 Up /data/deploy/data /data/deploy

172.10.178.139:20160 tikv 172.10.178.139 ²⁰¹⁶⁰⁄₂₀₁₈₀ linux/x86_64 Up /data/deploy/data /data/deploy

172.10.178.141:20160 tikv 172.10.178.141 ²⁰¹⁶⁰⁄₂₀₁₈₀ linux/x86_64 Up /data/deploy/data /data/deploy

172.10.179.76:20160 tikv 172.10.179.76 ²⁰¹⁶⁰⁄₂₀₁₈₀ 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