最初的时候，是单独一个tikv节点呢，数据量比较大，4.5T。可能考虑节省成本。

这么大的量级的region恢复，应该怎么操作呢？ [image]

收到，我试试大佬的这个方法

tidb-server启动后，只有进程，没有监听端口。 [image] 说明没有启动成功。从日志报错，也可以看到报错误[error=“[tikv:9005]Region is unavailable”]，说明要读取的这个region恰好分布在有问题的那个tikv节点上。

2个kv节点，是2副本模式。pd节点状态正常。 [image]

故障节点tikv的最新日志： [2025/10/13 15:43:20.789 +08:00] [WARN] [peer.rs:6093] ["leader missing longer than abnormal_leader_missing_duration"] [expect=10m] [peer_id=328718087] [region_id=3495887] [2025/10/13 15:43:20.789 +08:00] [WARN] [peer.rs:6093] ["leader missing longer than abnormal_leader_missing_dura…

缩容的话，还是要耐心等待收缩成功为好。

region调度迁移确实快了，但是，压力给到的store层。哈哈 磁盘空间显示已经从原来的300G增加到390G+ [image]

region-score-formula-version 用于设置 Region 算分公式的版本，支持的值有 ["v1", "v2"]。v2 版本公式有助于减少上下线等场景下冗余的 balance Region 调度。开启 v2 版本 Region 算分公式： config set region-score-formula-version v2

总结一下，共计调整的核心参数如下： #调整如下参数配置： tiup ctl:v7.5.4 pd -u http://10.3.8.227:2379 config set max-pending-peer-count 1024 tiup ctl:v7.5.4 pd -u http://10.3.8.227:2379 config set max-snapshot-count 1024 tiup ctl:v7.5.4 pd -u http://10.3.8.227:2379 config set replica-schedule-limit 1024 tiup ctl:v7.5.4 pd -u …

[image] 这个配置参数生效的前提条件为：region-score-formula-version = v1 进行如下配置修改： tiup ctl:v7.5.4 pd -u http://10.3.8.227:2379 config set region-score-formula-version v1 再次刷新查看进度，明显加快： [image]

目前，是有进度，但是，非常慢。 [image] 会不会跟新增的3个tikv节点的磁盘大小和原集群中的3个Tikv节点的磁盘大小不一致有关系呢？

region_weight值越大的tikv节点，优先分配给此tikv节点？

没有单独调整过 reserve-space参数： reserve-space TiKV 启动时会预留一块空间用于保护磁盘空间。当磁盘剩余空间小于该预留空间时，TiKV 会限制部分写操作。预留空间形式上分为两个部分：预留空间的 80% 用作磁盘空间不足时的运维操作所需要的额外磁盘空间，剩余的 20% 为磁盘临时文件。在回收空间的过程中，如果额外使用的磁盘空间过多，导致存储耗尽时，该临时文件会成为恢复服务的最后一道防御。 临时文件名为 space_placeholder_file，位于 storage.data-dir 目录下。当 TiKV 因磁盘空间耗尽而下线时，重启 TiKV 会自动删除该…

[image] tikv的目录大小分布如下： 1.没有扩容前的3个tikv节点，tikv目录占用的磁盘空间大小一致 2.新扩容的2个tikv节点，tikv目录占用的磁盘空间大小一致