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

【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。
请问大家有没有更好的办法去解决这个问题?

2 个赞

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

1 个赞

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

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

直接检查新节点上所有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_countleader_count,同时观察 pending_peer_count 是否为0。

    • 检查TiKV监控指标 raftstore_pending_peer_countraftstore_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>
    
2 个赞

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

具体的场景就是:

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

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

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

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

1 个赞

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

3 个赞

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

3 个赞

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

1 个赞

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

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

1 个赞

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

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

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

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