大哥，我已经把pd一个节点缩容移除了，为什么启动的时候你还要去找它？

🪐 TiDB 技术问题
1

tiup cluster scale-in tidb-cluster --node 192.168.1.184:2379 --force
tiup cluster prune tidb-cluster
执行完上面步骤后，查看集群已经没有pd2节点了，但是集群启动的时候为什么还要去检查184这个PD节点，难道tidb集群必须至少需要有2个PD节点才能启动吗？

[tidb@monitor ~]$ tiup cluster display tidb-cluster

A new version of cluster is available: v1.16.1 -> v1.16.5

    To update this component:   tiup update cluster
    To update all components:   tiup update --all

Cluster type:       tidb
Cluster name:       tidb-cluster
Cluster version:    v8.3.0
Deploy user:        tidb
SSH type:           builtin
ID                   Role               Host           Ports        OS/Arch       Status  Data Dir                           Deploy Dir
--                   ----               ----           -----        -------       ------  --------                           ----------
192.168.1.180:9093   alertmanager       192.168.1.180  9093/9094    linux/x86_64  Up      /tidb/tidb-data/alertmanager-9093  /tidb/tidb-deploy/alertmanager-9093
192.168.1.180:3000   grafana (patched)  192.168.1.180  3000         linux/x86_64  Up      -                                  /tidb/tidb-deploy/grafana-3000
192.168.1.183:2379   pd                 192.168.1.183  2379/2380    linux/x86_64  Down    /tidb/tidb-data/pd-2379            /tidb/tidb-deploy/pd-2379
192.168.1.180:9090   prometheus         192.168.1.180  9090/12020   linux/x86_64  Up      /tidb/tidb-data/prometheus-9090    /tidb/tidb-deploy/prometheus-9090
192.168.1.181:4000   tidb               192.168.1.181  4000/10080   linux/x86_64  Down    -                                  /tidb/tidb-deploy/tidb-4000
192.168.1.182:4000   tidb               192.168.1.182  4000/10080   linux/x86_64  Down    -                                  /tidb/tidb-deploy/tidb-4000
192.168.1.188:20160  tikv               192.168.1.188  20160/20180  linux/x86_64  N/A     /tidb/tidb-data/tikv-20160         /tidb/tidb-deploy/tikv-20160
192.168.1.189:20160  tikv               192.168.1.189  20160/20180  linux/x86_64  N/A     /tidb/tidb-data/tikv-20160         /tidb/tidb-deploy/tikv-20160
192.168.1.190:20160  tikv               192.168.1.190  20160/20180  linux/x86_64  N/A     /tidb/tidb-data/tikv-20160         /tidb/tidb-deploy/tikv-20160
Total nodes: 9

感觉tidb scale in加–force有问题，之前缩容tiflash节点加–force(tiflash节点宕机无法进入系统)，最后3个tikv节点都不能启动了，整个群集挂了。

1 个赞
2

你操作的步骤是怎么样的？缩容后，接着重启集群了？

3

执行reload试试

4

应该是集群没有启动，所以无法扩容缩容。
之前加–force参数后，整个集群就挂了，最后重装了。

5

这个问题常见。PD缩容后启动时仍然检查旧节点，通常是因为集群元数据里还残留着那个PD的member信息。

1 个赞
6

虚心学习

7

应该是要保证多数派，默认就不允许单节点把。

8

TiDB 集群不要求必须 2 个 PD 才能起，单 PD 也可运行（生产建议奇数 3 节点）。scale-in 后仍连旧地址，多半是元数据未清干净：1）各节点 pd/tikv/tidb 的 --initial-cluster、–join 或 topology 里仍含 192.168.1.184；2）tiup 元数据/cluster.yaml 或 systemd 启动脚本残留；3）monitor/prometheus 仍 scrape 该 target。建议 tiup cluster edit-config 核对 pd_servers，grep 全集群配置与 prometheus rules，确认 prune 后 reload；必要时在存活 PD 上 pd-ctl member 看成员列表是否还有 184。

9

仅节点失联时才用 --force，且必须补充手动 member remove

10

请问手动member remove是不是执行prune会自动清理呢？文档里只写prune清理

11

执行 prune 会清理掉一些元信息，你可以发一下具体的报错，看看是哪里有残留信息

12

配置项没清理掉旧的ip吧

14

技术上单 PD 节点完全可以正常运行、启动集群，PD 底层基于 etcd，单节点 etcd 天然满足自身 leader 选举，不需要最少 2 个 PD。

  • 生产规范：PD 推荐奇数节点（1/3/5），3 个用于容灾；测试环境单 PD 毫无问题。
  • 你现在启动仍旧去连旧 192.168.1.184:2379，不是集群需要 2 个 PD，是各类配置文件、TiKV 本地持久化元数据残留了旧 PD 地址。
15

虚心学习

16

单节点是可以的

17

学习了

18

curl http://192.168.1.183:2379/pd/api/v1/members
如果返回的 JSON 结果中依然包含 192.168.1.184 ，说明 PD 内部并没有真正剔除它。
正确的手动剔除方法 是使用 pd-ctl 工具连接到存活的 PD

19

虚心学习

20

单 PD 技术上是可以运行的，只是生产环境官方建议至少部署 3 个 PD，并且使用奇数节点。你原来如果只有 183、184 两个 PD，本身就没有单节点故障容忍能力，掉一个以后剩下一个无法形成 Raft 多数派。
还有scale-in 正常缩容 PD 时，TiUP 会先通过 API 删除 PD member，再停止服务和清理文件，prune 主要是清理 Tombstone 状态的 TiKV/TiFlash，对 PD 缩容没有实际作用。
可以先看下启动时到底是谁还在访问 .184：如果 .183 的 PD 日志一直访问 .184:2380，要查 PD member/etcd 状态；如果是 TiKV 访问 .184:2379，则还可能只是 PD Client 缓存了旧的 PD 地址，官方也说明 TiKV 会缓存 PD 节点列表并定期刷新。可以暂时不用 --force，先不要继续强制操作，把 .183 的 PD 启动日志以及访问 .184 的具体日志贴出来再判断。