pd一直在balance region平衡

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】3.0.12
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
从昨天下午开始,一直在balance region,insert语句大量慢查询,大部分时间在prewrite阶段。


region score分数一直在波动,为什么分数一直在变呢?之前一直没有过这种情况,是因为使用空间大于60%了吗?

一直在平衡region,一天了也没完,这两个节点程锯齿状波动,上去再下来

导致现在有大量的insert慢查询

pd参数如下:
» config show
{
“replication”: {
“location-labels”: “”,
“max-replicas”: 3,
“strictly-match-label”: “false”
},
“schedule”: {
“disable-location-replacement”: “false”,
“disable-make-up-replica”: “false”,
“disable-namespace-relocation”: “false”,
“disable-raft-learner”: “false”,
“disable-remove-down-replica”: “false”,
“disable-remove-extra-replica”: “false”,
“disable-replace-offline-replica”: “false”,
“enable-one-way-merge”: “false”,
“high-space-ratio”: 0.6,
“hot-region-cache-hits-threshold”: 3,
“hot-region-schedule-limit”: 4,
“leader-schedule-limit”: 4,
“low-space-ratio”: 0.8,
“max-merge-region-keys”: 200000,
“max-merge-region-size”: 20,
“max-pending-peer-count”: 16,
“max-snapshot-count”: 3,
“max-store-down-time”: “30m0s”,
“merge-schedule-limit”: 8,
“patrol-region-interval”: “100ms”,
“region-schedule-limit”: 8,
“replica-schedule-limit”: 8,
“scheduler-max-waiting-operator”: 3,
“schedulers-v2”: [
{
“args”: null,
“disable”: false,
“type”: “balance-region”
},
{
“args”: null,
“disable”: false,
“type”: “balance-leader”
},
{
“args”: null,
“disable”: true,
“type”: “hot-region”
},
{
“args”: null,
“disable”: false,
“type”: “label”
}
],
“split-merge-interval”: “1h0m0s”,
“store-balance-rate”: 15,
“tolerant-size-ratio”: 5
}
}
»
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】

看上去这个问题比较类似,参考一下热点调度的问题:

high-space-ratio=0.6
你各个tikv节点磁盘使用率现在是多少?

我的scheduler operator create都是balance-region,没有热点。


v3.0默认是0.6,我刚才改成0.7了, tikv磁盘使用率最多的64%。

考虑升级么? 3.X… :face_with_spiral_eyes:

虽然我最早接触的就是这个版本,但是真心没现在的版本好用…


Region Score 是 PD 用来调度 Region 的一个重要指标,它是根据当前 Store 的状态和 Region 的状态计算出来的一个分数,用于评估 Region 在当前 Store 上的合适程度。Region Score 的高低决定了 PD 是否会将该 Region 调度到当前 Store 上。

PD 通过计算每个 Store 上的 Region Score,来决定将 Region 调度到哪个 Store 上。Region Score 的计算方式是根据当前 Store 的状态和 Region 的状态计算出来的,具体计算方式可以参考 TiDB 官方文档 [1]

Region Score 的计算机制是根据当前 Store 的状态和 Region 的状态来计算的。PD 会根据当前 Store 的剩余空间、负载情况、磁盘使用率等因素,计算出当前 Store 的 Score。同时,PD 也会根据 Region 的大小、副本数量、分布情况等因素,计算出每个 Region 的 Score。最终,PD 会将每个 Region 的 Score 除以其权重,得到最终的 Region Score。

PD 会根据 Region Score 的高低来决定将 Region 调度到哪个 Store 上。当 PD 发现某个 Store 的 Region Score 过高时,会将一些 Region 调度到其他 Store 上,以达到负载均衡的目的。同时,当 PD 发现某个 Store 的 Region Score 过低时,会将一些 Region 调度到该 Store 上,以提高该 Store 的利用率。


我怀疑是热点调度,打破了这个平衡,可以尝试先关闭这个调度服务。
参考问答:


Score 计算的方式,简单描述:

参考文档:


核心算法文档参考:

当tikv部分节点磁盘使用率超过high-space-ratio这个参数,它的打分策略会和低于这个参数的tikv节点的打分策略产生很大的差异,这时它的分数可能远远高于磁盘使用率低于这个参数的tikv节点,会导致大量的region从高使用率tikv节点balance到低使用率tikv节点。。。
调高这个参数后,看看balance会不会趋于稳定

版本有点低,建议升级最新稳定版。
打分变化可能是region平衡的导致的。

region balance 会导致insert 慢吗?insert的prewrite耗时很多,报表有大量读写冲突tikvLockFast,少量写写冲突txnLock和updateLeader。

我把high-space-ratio设成0.75了,现在score在缓慢变化。我想让他调度慢点,少影响写业务,是把region-schedule-limit调低吧?
扩容tikv节点可以解决这个问题吧?

会,因为region 被调度了,还有可能会导致 backoff…

把region-schedule-limit调低会降低balance对集群的影响,你可以把region-schedule-limit调低然后再扩容tikv节点,这样可以让其他使用率高的tikv节点缓慢的将region balance给新扩容的tikv节点,不影响当前集群的业务,又可以降低其他节点的磁盘使用率。

版本太老了吧,我在缩节点,region-schedule-limit被我加到 3600 都不影响系统使用
image

:wink:不仅要考虑版本,还要考虑硬件~

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