【 TiDB 使用环境】生产
【 TiDB 版本】v6.5.0
【复现路径】
- tidb-a 和 tidb-b 的 pd 进程意外 Down 掉（display 显示）；
- 使用位于 tidb-a 机器上的 tiup 对 tidb-b 的 1个pd、3个tikv进程进行缩容（没有 --force），缩容失败；
- 关闭 tidb-b 机器，在 tidb-a 上增加缩容参数 --force 成功缩容（提示缩容成功）
- 目前集群只剩下 tidb-a 上的 1个pd和3个tikv进程；
- 在 tidb-a 上使用 tiup 重启集群，tikv 无法连接本地 pd，启动失败（pd进程2379端口无限卡死）；
- 启动 tidb-b 后，tidb-b 上的 pd 和 tikv 进程再度自动启动，此时 tidb-a 的集群能成功启动（但 tidb-a 上运行 tiup display 的集群信息里并没有包含任何 tidb-b 上的信息）
- 此时引入第三台物理机 tidb-c（配置相同），然后在 tidb-a 利用 tiup 单独进行 pd 扩容（提示扩容成功）
- 到此时，集群运行正常。
【遇到的问题：问题现象及影响】
- 如果希望对 tidb-b 物理机进行数据清空、下线维护，此时 tidb-b 上的 tikv 和 pd 进程如何能够安全关闭、卸载？（因为 tidb-a 上的 pd 似乎还在联络 tidb-b 的 pd 端口，即便集群信息里已经没有 tidb-b 的任何进程了）
- 在没有把 tikv 进程扩容到 tidb-c 机器上的情况下（只扩容了 pd），停掉 tidb-b 的 tikv 进程，是否会造成数据损失？
- 如何排查最开始 两台机器的 pd 进程 Down 掉的原因。
【资源配置】
当前集群共两台物理机（tidb-a、tidb-b两台）：
- 每台物理机有4个nvme磁盘（1为系统盘，3为tikv盘）
- 各1个pd进程、3个tikv进程
【附件：截图/日志/监控】
最新进展：
重新在 tidb-a 上对 tidb-b 的 pd 做单独扩容，然后再缩容。
目前 members 数据恢复正常，tidb-b 的 pd 彻底下线。
遗留问题：
tidb-b 的 tikv 进程还在运行，暂时不确定该如何操作。
最新进展（0710）：
将 tikv 扩容了 tidb-c 上之后，停机 tidb-b，还是遇到了问题。
在 tidb-a 上查看某个 tikv 进程日志，发现还在连 tidb-c 的 tikv：
[2023/07/10 15:01:41.922 +08:00] [ERROR] [raft_client.rs:821] [“wait connect timeout”] [addr=tidb-b:20160] [store_id=19]
在 tidb-c 上查看某个 tikv 进程日志，也还在连 tidb-c 的 tikv：
[2023/07/10 15:38:54.303 +08:00] [ERROR] [raft_client.rs:821] [“wait connect timeout”] [addr=tidb-b:20161] [store_id=18]
真是个令人费解的集群。
调用三台 pd 输出当前 members 均显示：
{"members": [
{
"name": "pd-100-9",
"member_id": 584547965617176002,
"peer_urls": [
"http://{tidb-b}:2380"
],
"client_urls": [
"http://{tidb-b}:2379"
],
"deploy_path": "/home/tidb-deploy/pd-2379/bin",
"binary_version": "v6.5.0",
"git_hash": "d1a4433c3126c77fb2d5bb5720eefa0f2e05c166"
},
{
"name": "pd-100-8",
"member_id": 7993749446034719644,
"peer_urls": [
"http://{tidb-a}:2380"
],
"client_urls": [
"http://{tidb-a}:2379"
],
"deploy_path": "/home/tidb-deploy/pd-2379/bin",
"binary_version": "v6.5.0",
"git_hash": "d1a4433c3126c77fb2d5bb5720eefa0f2e05c166"
},
{
"name": "pd-100-10",
"member_id": 16307004469217232564,
"peer_urls": [
"http://{tidb-c}:2380"
],
"client_urls": [
"http://{tidb-c}:2379"
],
"deploy_path": "/home/tidb-deploy/pd-2379/bin",
"binary_version": "v6.5.0",
"git_hash": "d1a4433c3126c77fb2d5bb5720eefa0f2e05c166"
}
]}
为什么明明在 tidb-a 上对 tidb-b 进行了强制缩容，但 tidb-b 还存在于 members 组里呢。
是没有缩容成功吗？但 display 的时候显示的结果里，已经没有 tidb-b 机器上的任何部件了：
ID Role Host Ports OS/Arch Status Data Dir Deploy Dir
-- ---- ---- ----- ------- ------ -------- ----------
{tidb-c}:2379 pd {tidb-c} 2379/2380 linux/x86_64 Up /home/tidb-data/pd-2379 /home/tidb-deploy/pd-2379
{tidb-a}:2379 pd {tidb-a} 2379/2380 linux/x86_64 Up|L /home/tidb-data/pd-2379 /home/tidb-deploy/pd-2379
{tidb-a}:20160 tikv {tidb-a} 20160/20180 linux/x86_64 Up /data1/tidb-data/tikv-20160 /data1/tidb-deploy/tikv-20160
{tidb-a}:20161 tikv {tidb-a} 20161/20181 linux/x86_64 Up /data2/tidb-data/tikv-20161 /data2/tidb-deploy/tikv-20161
{tidb-a}:20162 tikv {tidb-a} 20162/20182 linux/x86_64 Up /data3/tidb-data/tikv-20162 /data3/tidb-deploy/tikv-20162
Total nodes: 5
redgame
(Ti D Ber Pa Amoi Ul)
3
1.tiup cluster scale-in $cluster-name -N tidb-b
redgame
(Ti D Ber Pa Amoi Ul)
5
3.找
tail -f tikv.log
tail -f pd.log
当时pddown掉之后为啥要直接进行缩容操作呢？现在tidb-b节点上的节点已经无法重新加入集群了，只能进行有损恢复试试了。。
感谢回复：
因为，当时在a上做restart操作总是连不上b，缩容后a才可以单独继续（除了 pd 无法正常启动）。
b 被认为系统内核可能存在问题，需要进行下线维护。
所以在当时两个 pd 都 Down 的时候，应该如何操作呢，有建议吗？
你好，感谢回复。
我在当前 a 上的 tiup 进行这一步的时候并不会成功，因为：
当前的集群信息里并没有 b 的任何信息（只是不清楚为什么 a 服务器上的 pd 启动 仍然需要依赖 b 服务器上的 pd）
由于上面提到的“a 服务器的 pd 启动事实上还需要依赖 b 服务器的 pd”，所以我现在不知道目前集群对 b 服务器的 tikv 还有没有依赖
我现在不清楚该如何确保 “当前集群可以不需要 b 服务器的任何服务”
当时pddown掉之后为啥要直接进行缩容操作呢？现在tidb-b节点上的节点已经无法重新加入集群了，只能进行有损恢复试试了。。
我现在不想要 b 重新加入集群，而是想让集群彻底摆脱 b （因为之前 b 关机时，a 的 pd 也启动失败，导致 a 的 tikv 也启动失败）
这个会报错：
Error: failed to destroy: cannot find node id ‘tidb-b:2379’ in topology
目前进展：
重新在 tidb-a 上对 tidb-b 的 pd 做单独扩容，然后再缩容。
目前 members 数据恢复正常，tidb-b 的 pd 彻底下线。
遗留问题：
tidb-b 的 tikv 进程还在运行，暂时不确定该如何操作。