【TiDB 使用环境】生产环境 /测试/ Poc
生产环境
【TiDB 版本】
8.1/7.1
【操作系统】
内部OS
【问题复现路径】做过哪些操作出现的问题
起一台机器
【遇到的问题：问题现象及影响】
当加入一台新的机器，这台机器变成online，开始bootstrap。由于TiKV的raft实现没有"catch up所有的update才上线"的概念，刚起来的机器，由于这段时间的snapshot ingestion影响，write/read latency会比较高。
我们目前的解决办法是
- 给新起来的机器加evict-leader-scheduler
- 在这个机器上线之前的一些pre-start step里面，通过检查这个store的region count和leader count，并和整个cluster level avg去判断这个是不是一个即将ready的store（比如这个store的 region count 必须达到集群平均值的85% 等等）
- 如果是的话，就remove evict-leader-scheduler, 这样leader可以很快起来减少高延迟的影响
- 如果不是的话，就等着，开始反复轮询，直到满足要求为止。
但这个实现的问题在于不可靠。如果任意leader count或者region count没有达到要求，或者对特别小的集群，这种计算方式很容易出错，导致节点一直没办法完成所谓的“bootstrap”所以一直有evict-leader-scheduler。
请问大家有没有更好的办法去解决这个问题？
2 个赞
我之前问过这个问题（链接），得到的答复是store-level catch up不存在。对此我表示同意。那我们该怎么缓解这个问题？ 难道就是拉大所有的limit，让它尽快完成bootstrap吗？
1 个赞
xfworld
(魔幻之翼)
3
没看懂，能不能简单描述下你的场景和你问题？
如果有机会的话，请补充下集群的信息和一些关键日志，谢谢！
松隐青峦
(松隐青峦)
4
直接检查新节点上所有Region的副本状态，确保数据同步完成后再解除Leader驱逐。
-
添加evict-leader-scheduler：
pd-ctl -u http://<pd_ip>:<pd_port> scheduler add evict-leader-scheduler <store_id>```
-
监控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 确认无异常。
-
动态解除Leader驱逐：
- 当
pending_peer_count 持续为0且region_count接近集群平均值时，移除调度器：
pd-ctl -u http://<pd_ip>:<pd_port> scheduler remove evict-leader-scheduler-<store_id>
2 个赞
好的。我这个问题比较常规，没有具体的集群信息和日志，不好意思。
具体的场景就是：
- 往一个TiKV cluster，里面加一台新的TiKV机器
- 这个机器在启动后，会报告它的状态给PD；在PD那里它的状态是ONLINE。同时PD会给这个新的机器分一些region。它可能是一些region的leader，也可能是一些region的follower
- 由于新的region分给了这个机器，有大量的写，所以短时间内，这台机器的API延迟比较高
- 如果这时候有一些请求发到了这个机器的leader上，那么就会有请求延时.
我想知道有没有办法去解决这个问题？能不能不让请求发到这种还没完全ready的host？
这是一个好的思路! 感谢！
不好意思还有一个关于#3的问题。 假如解除leader驱逐之后，PD打算把很多leader放到这个节点上，那么短时间内，这个节点仍可能会有大量的写，一些leader可能catch up了，另一些还没有，那么对于还没有ready的leader来说，API仍然会有延迟。这种情况是不是没招了？毕竟没有控制的办法了🤔。也许可以降低leader transfer的速度，让这个store慢慢加leader，这样影响小一些
小龙虾爱大龙虾
(Minghao Ren)
8
TiDB 集群的调度是一直存在的，如果说新上线的节点受到 ingestion 的影响，那只能说明上线速度太快，应适当调整 PD 调度参数，控制 region 调度速度，降低影响
3 个赞
松隐青峦
(松隐青峦)
9
看看这两个参数满不满足你的需要，leader-schedule-limit、region-schedule-limit。
另外可以看看 Placement Policy，把新节点打上标签，在数据同步完成前点不接收 Leader，可以尝试下。
3 个赞
清风明月
10
增加资源的配置，延迟应用连接时长，等数据库都启动了，在起应用。
1 个赞
另外可以看看 Placement Policy，把新节点打上标签，在数据同步完成前点不接收 Leader，可以尝试下。
这个也是一个好的思路。意思是起新机器之后，把他们加入到一个特别的rule group, 只充当follower/learner, 之后再移出去，效果可能跟evict-leader-scheduler 类似 
1 个赞
我们的情况是把tidb作为一个数据库的服务给多个应用使用，所以没法要求应用后启动。目标是减少tidb在各种情况下对应用的影响。
清风明月
15
可以设置下连接超时时间，防止大量请求。还有就是先把tikv启动起来或增加资源和增加节点数，在启tidb。刚开始比较高，后边会逐渐平稳