节点已缩容下掉，为啥日志中显示还向缩容过的节点写数据？["Store is not ready"] ["store address"=172.17.4.250:3930] ["err message"="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp 172.17.4.250:3930: i/o timeout\""]

🪐 TiDB 技术问题 TiFlash
1

节点已缩容下掉，为啥日志中显示还向缩容过的节点写数据？[“Store is not ready”] [“store address”=172.17.4.250:3930] ["err

message"="rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 172.17.4.250:3930:

i/o timeout""]

2

缩容没有清理干净
之前旧版本的目录没有清理

3

缩容的节点的服务器已经下掉了，应该不存在该节点的目录文件了吧？

4 
确认节点是否真的从集群中移除了。你可以使用 pd-ctl 工具来检查集群的成员和状态。
确认 TiUP 缩容操作是否成功完成，没有错误信息。
检查 PD 的日志，看是否有关于节点状态变化的记录。
如果问题持续存在，可以考虑重启 TiDB 集群中的其他服务，以确保它们使用了最新的集群配置。
5

已经下掉是什么意思？现在display里没有那个节点了么？

6

是的，查询集群状态，已经没有这个节点了，而是上周周五下掉的

7

上周周五执行的缩容操作，提示成功没有报错，pd-ctl 检查没有之前缩容的节点信息。tidb.log的日志中一直有下掉节点的日志信息的

8

请问缩容的具体命令是什么，是不是用到了 强制删除的操作（ --force）？

9

先缩容，数据同步完后，最后执行 --force

10

问题可能出在这里。
–force * 在某些情况下，有可能被缩容的节点宿主机已经宕机，导致无法通过 SSH 连接到节点进行操作，这个时候可以通过 --force 选项强制将其从集群中移除。

使用该选项强制移除正在服务和下线中的 TiKV / TiFlash 节点时，这些节点会被直接删除，不等待数据调度完成，因此这个场景下，数据丢失风险非常大。不建议对未宕机的节点使用该选项。如果元数据所在的 Region 发生数据丢失，整个集群将不可用且无法恢复。

11

缩容的是tikv节点吧，当初是怎么确认数据已经同步完成的？

当前集群还有几台可以使用的机器？

12

之前有两个列存节点，上周五下掉一个。通过region_count的数据为：0，确认数据同步完成

13

"state_name"为 Tombstone 和region_count为：0 后，才执行的 --force操作

14

–force 生产坏境还是谨慎使用

15

建议按标准操作进行
执行 tiup cluster prune 命令清理 Tombstone 节点

image
image1055×458 29.3 KB

16

:call_me_hand:向大佬学习

17

这个是标准流程