Binbin
(Binbin)
1
为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
- 【TiDB 版本】：v4.0.6
- 【问题描述】：tikv扩容失败
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
今天有个tikv节点tombstone了，然后使用stores remove-tombstone 去掉了这个节点
查看集群信息：
然后我使用scale-out来扩容tikv节点，依旧使用原来tombstone的这台机器来扩容：
root@mater-db:~/.tiup# cat scale-out.yaml
tikv_servers:
- host: 192.168.188.121
ssh_port: 22
port: 20160
status_port: 20180
deploy_dir: /home/tidb-deploy/tikv-20160
data_dir: /home/tidb-data/tikv-20160
但是扩容时报错了，请问这个要怎么解决呢？
查看日志 cat /root/.tiup/logs/tiup-cluster-debug-2020-10-27-11-28-56.log | tail -n 200
查看tiup的启动文件，里面依旧存在这个节点信息
想编辑删掉192.168.188.121节点，tiup cluster edit-config tidb-cluster，好像删不掉
先通过 tiup cluster scale-in tidb-cluster -N 192.168.188.121:20160 --force 缩容 tikv 节点
查看 tiup cluster display tidb-cluster 这个节点消失之后再进行扩容操作。
有个 tikv 节点 tombstone 了，这个是通过 tiup cluster display 看到状态是 Tombstone 吗？之前这个节点有没有做过缩容操作？
Binbin
(Binbin)
3
感谢！根据您的回复来执行，扩容成功了。
之前tombstone 这个tikv节点，昨天tidb用户遭到攻击，所以先使用 tiup cluster scale-in tidb-cluster --node 192.168.188.121:20160 命令来下线，但是下线了一晚上都是pending offline，后来看到有个帖子说 强制将pending offline 改成 tombstone 。
试完之后使用 tiup cluster display tidb-cluster查看是没有这个节点的了，但是用扩容命令tiup cluster scale-out tidb-cluster scale-out.yaml 执行时，最后报错了，（不知道是不是与我没有删除之前tikv的tidb-data和tidb-deploy目录有关）报错信息没有截图。
之后我就去执行了stores remove-tombstone 去掉了这个节点，再把tikv节点的tidb-data和tidb-deploy目录删除，再执行扩容，就出现了这个报错
所以以后tikv节点缩容都要强制缩容吗？
我还有一个问题想请问，tidb用户遭到攻击，可能是我密码设得太简单了（已更改密码），而且这个节点的机器有映射到一个公网，visudo添加了tidb ALL=(ALL) NOPASSWD:ALL，这样会不会更容易遭到入侵？但是我不添加这个，其他节点的pd组件啥的ssh不了。
tiup cluster scale-in 缩容 TiKV 节点之后，状态是会变成 offline 的，在 offline 的状态下，TiKV 会将 reigon 调度到别的正常节点上。你这边一直处于 penging offline 的状态，大概率是因为看你集群只有 3 个 tikv 节点，region 调度中不会将同一个 region 的 2 个副本调度到同一个 tikv 实例上，所以当 3 个 tikv 节点缩容一个节点时，region 一直无法在别的节点上补副本成功。
正常缩容都是等待 offline 状态自动变为 tombstone ，不建议强制将状态置为 tombstone。
强制改为 tombstone 之后扩容失败应该是与目录没有清理有关系，还存在之前的数据。
不过你说 tiup cluster display 的时候查看是没有缩容掉的节点的，但是看你给的截图中这个节点还是存在的，只是状态是 N/A
可以部署的时候先自己做好机器之间免密，通过 tiup 部署时可以跳过免密用户的创建过程
