怎么解决刚起来的机器延迟高的问题？

[TiDBerrrrrrrr (Ti D Ber D Pp Hk C9 G)]

【TiDB 使用环境】生产环境 /测试/ Poc
生产环境
【TiDB 版本】
8.1/7.1
【操作系统】
内部OS
【问题复现路径】做过哪些操作出现的问题
起一台机器
【遇到的问题：问题现象及影响】
当加入一台新的机器，这台机器变成online，开始bootstrap。由于TiKV的raft实现没有"catch up所有的update才上线"的概念，刚起来的机器，由于这段时间的snapshot ingestion影响，write/read latency会比较高。
我们目前的解决办法是

1. 给新起来的机器加evict-leader-scheduler
2. 在这个机器上线之前的一些pre-start step里面，通过检查这个store的region count和leader count，并和整个cluster level avg去判断这个是不是一个即将ready的store（比如这个store的 region count 必须达到集群平均值的85% 等等）
3. 如果是的话，就remove evict-leader-scheduler, 这样leader可以很快起来减少高延迟的影响
4. 如果不是的话，就等着，开始反复轮询，直到满足要求为止。

但这个实现的问题在于不可靠。如果任意leader count或者region count没有达到要求，或者对特别小的集群，这种计算方式很容易出错，导致节点一直没办法完成所谓的“bootstrap”所以一直有evict-leader-scheduler。
请问大家有没有更好的办法去解决这个问题？

[TiDBerrrrrrrr (Ti D Ber D Pp Hk C9 G)]

我之前问过这个问题（链接），得到的答复是store-level catch up不存在。对此我表示同意。那我们该怎么缓解这个问题？ 难道就是拉大所有的limit，让它尽快完成bootstrap吗？

[xfworld (魔幻之翼)]

没看懂，能不能简单描述下你的场景和你问题？

如果有机会的话，请补充下集群的信息和一些关键日志，谢谢！

[lyndon879 (Ti D Ber Pm Jo N9z8)]

直接检查新节点上所有Region的副本状态，确保数据同步完成后再解除Leader驱逐。

1. 添加evict-leader-scheduler：

   pd-ctl -u http://<pd_ip>:<pd_port> scheduler add evict-leader-scheduler <store_id>```
   

2. 监控Region同步状态：

   • 使用PD API检查新节点上是否有未完成的副本（pending peers）或正在传输的快照：

   curl http://<pd_ip>:<pd_port>/pd/api/v1/store/<store_id>
   

   检查 region_count 和 leader_count，同时观察 pending_peer_count 是否为0。

   • 检查TiKV监控指标 raftstore_pending_peer_count 和 raftstore_snapshot_corrupt 确认无异常。

3. 动态解除Leader驱逐：

   • 当 pending_peer_count 持续为0且region_count接近集群平均值时，移除调度器：

   pd-ctl -u http://<pd_ip>:<pd_port> scheduler remove evict-leader-scheduler-<store_id>
   

[TiDBerrrrrrrr (Ti D Ber D Pp Hk C9 G)]

好的。我这个问题比较常规，没有具体的集群信息和日志，不好意思。

具体的场景就是：

1. 往一个TiKV cluster，里面加一台新的TiKV机器
2. 这个机器在启动后，会报告它的状态给PD；在PD那里它的状态是ONLINE。同时PD会给这个新的机器分一些region。它可能是一些region的leader，也可能是一些region的follower
3. 由于新的region分给了这个机器，有大量的写，所以短时间内，这台机器的API延迟比较高
4. 如果这时候有一些请求发到了这个机器的leader上，那么就会有请求延时.

我想知道有没有办法去解决这个问题？能不能不让请求发到这种还没完全ready的host？

[TiDBerrrrrrrr (Ti D Ber D Pp Hk C9 G)]

这是一个好的思路! 感谢！
不好意思还有一个关于#3的问题。 假如解除leader驱逐之后，PD打算把很多leader放到这个节点上，那么短时间内，这个节点仍可能会有大量的写，一些leader可能catch up了，另一些还没有，那么对于还没有ready的leader来说，API仍然会有延迟。这种情况是不是没招了？毕竟没有控制的办法了🤔。也许可以降低leader transfer的速度，让这个store慢慢加leader，这样影响小一些

[xfworld (魔幻之翼)]

配置足够的资源，才能保障负载的均衡了

[小龙虾爱大龙虾 (Minghao Ren)]

TiDB 集群的调度是一直存在的，如果说新上线的节点受到 ingestion 的影响，那只能说明上线速度太快，应适当调整 PD 调度参数，控制 region 调度速度，降低影响

[lyndon879 (Ti D Ber Pm Jo N9z8)]

看看这两个参数满不满足你的需要，leader-schedule-limit、region-schedule-limit。
另外可以看看 Placement Policy，把新节点打上标签，在数据同步完成前点不接收 Leader，可以尝试下。

[清风明月]

增加资源的配置，延迟应用连接时长，等数据库都启动了，在起应用。

[TiDBerrrrrrrr (Ti D Ber D Pp Hk C9 G)]

另外可以看看 Placement Policy，把新节点打上标签，在数据同步完成前点不接收 Leader，可以尝试下。

这个也是一个好的思路。意思是起新机器之后，把他们加入到一个特别的rule group, 只充当follower/learner, 之后再移出去，效果可能跟evict-leader-scheduler 类似

[YuchongXU]

等待一段时间让它预热一下

[清风明月]

先起应用的话，数据库容易被打挂。

[TiDBerrrrrrrr (Ti D Ber D Pp Hk C9 G)]

我们的情况是把tidb作为一个数据库的服务给多个应用使用，所以没法要求应用后启动。目标是减少tidb在各种情况下对应用的影响。

[清风明月]

可以设置下连接超时时间，防止大量请求。还有就是先把tikv启动起来或增加资源和增加节点数，在启tidb。刚开始比较高，后边会逐渐平稳