对tikv一节点scale-in, 剩余最后几十个region很多天后region都没有迁移完，请问是什么原因？

【 TiDB 使用环境】生产环境
【 TiDB 版本】v5.1.1
【遇到的问题：问题现象及影响】
对tikv一节点scale-in, 剩余最后几十个很多天后region都没有迁移完，请问是什么原因？该如何处理？

【附件：截图/日志/监控】
pd leader节点，每10分钟会输出这样的日志：
[2023/12/14 09:54:07.883 +08:00] [WARN] [cluster.go:1232] [“store may not turn into Tombstone, there are no extra up store has enough space to accommodate the extra replica”] [store="id:3363993 address:"10.10.10.10:29120" state:Offline labels:<key:"host" value:"tikv8" > version:"5.1.1" status_address:"10.10.10.10:29130" git_hash:"4705d7c6e9c42d129d3309e05911ec6b08a25a38" start_timestamp:1702458741 deploy_path:"/work/tidb29100/deploy/tikv-29120/bin" last_heartbeat:1702518842815183571 "]

各tikv节点存储空间使用情况如下：

商店可能不会变成墓碑，没有额外的商店有足够的空间来容纳额外的副本
空间不够 ↑

region迁移的规则是怎样？是如何判断空间不够的呢？

这里看每个节点有大几百GB的可用空间呢

理论上leader都没了就能下了

10.10.10.10 这个服务器磁盘满了？

没有，这个是scale-in tikv的ip

找2个region pd-ctl region 看看状态

其他节点的空间使用率超过80%了没？

各节点tikv的磁盘占用情况如下图，有超过80%

/dev/sdb 3.7T 625G 3.1T 17% /work
/dev/dfa 3.0T 2.2T 754G 75% /work
/dev/nvme0n1 3.5T 2.2T 1.4T 62% /work
/dev/nvme0n1 7.0T 6.1T 1002G 86% /work
/dev/nvme0n1 7.0T 6.1T 1002G 86% /work
/dev/nvme0n1 7.0T 6.1T 1002G 86% /work

为何是80%呢？这里与region调度的关系是什么呢？有没有关于region调度策略相关的文档

pd-ctl config set 把space-ratio调高

清理了86%的space_placeholder_file文件，然后执行了config set low-space-ratio 0.85后，剩下的15个region很快就迁移完了

/dev/sdb 3.7T 625G 3.1T 17% /work
/dev/dfa 3.0T 2.2T 746G 75% /work
/dev/nvme0n1 3.5T 2.2T 1.4T 62% /work
/dev/nvme0n1 7.0T 5.7T 1.4T 81% /work
/dev/nvme0n1 7.0T 5.7T 1.4T 81% /work
/dev/nvme0n1 7.0T 5.7T 1.4T 81% /work

store may not turn into Tombstone, there are no extra up store has enough space to accommodate the extra replica

这里说的很清楚，这个问题的原因是你要下线一个节点，这个节点的数据要搬迁出去到别的节点上，但是别的节点空间不够了，才导致的。

判断别的节点空间够不够，集群是根据low-space-ratio参数来决定的，所以你提高它，集群就又认为空间够了，这样前面的调度操作就得以执行。

这个是临时办法，根本解决之道还是要扩容存储或者及时清理不要的数据释放空间。

有疑问的一点是：有2个tikv的磁盘使用率是在80%以下的,但是scale-in的tikv节点剩下的几十个region还是不迁移，low-space-ratio代表是有任何1个tikv的磁盘使用率是在80%以上就停止region迁移吗？

/dev/dfa 3.0T 2.2T 746G 75% /work
/dev/nvme0n1 3.5T 2.2T 1.4T 62% /work (新扩容的tikv）

不会，没到这个阈值的节点，按理是还可以接收来自其他节点的数据，不过也不能只看这一方面，迁移还有很多其他内容要考虑。
集群数据迁移调度的具体执行，其实还涉及到Leader或Region的数据分布、访问热点情况、空间剩余情况、调度策略等各方面内容，是它们这些因素的综合结果

是的 集群应该是综合考量 在剔除无法迁移的store后 在可用的store上还有许多限制因素 如label 、数据分布 调度限制等

是的，没到这个阈值的节点(1个是新扩容tikv，一个是75%使用率的tikv)region数量都在增加的，只不过scale-in节点的region没有迁移，猜测可能这2个没到阈值的tikv再均衡的话，scale-in节点的region会再次迁移的。不过已经通过config set low-space-ratio 0.85将scale-in节点的region迁移完了，不能复现了

磁盘使用是不是到水位线了

调整space-ratio参数

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。