tikv空间严重不平衡

🪐 TiDB 技术问题
1

目前集群有40个tikv，但是数据现在疯狂往两个tikv里写入。这两个tikv空间已经93%了还在写入。其它tikv有大量空间。有什么办法吗？这两台机器的store得分已经远超其它tikv。
当前pd设置的相关参数如下
» config show
{
“replication”: {
“enable-placement-rules”: “true”,
“enable-placement-rules-cache”: “false”,
“isolation-level”: “”,
“location-labels”: “dc,host”,
“max-replicas”: 3,
“strictly-match-label”: “false”
},
“schedule”: {
“enable-cross-table-merge”: “true”,
“enable-diagnostic”: “true”,
“enable-joint-consensus”: “true”,
“enable-tikv-split-region”: “true”,
“enable-witness”: “false”,
“high-space-ratio”: 0.7,
“hot-region-cache-hits-threshold”: 3,
“hot-region-schedule-limit”: 4,
“hot-regions-reserved-days”: 7,
“hot-regions-write-interval”: “10m0s”,
“leader-schedule-limit”: 512,
“leader-schedule-policy”: “count”,
“low-space-ratio”: 0.9,
“max-merge-region-keys”: 300000,
“max-merge-region-size”: 20,
“max-pending-peer-count”: 256,
“max-snapshot-count”: 256,
“max-store-down-time”: “30m0s”,
“max-store-preparing-time”: “48h0m0s”,
“merge-schedule-limit”: 64,
“patrol-region-interval”: “10ms”,
“region-schedule-limit”: 8192,
“region-score-formula-version”: “v2”,
“replica-schedule-limit”: 256,
“slow-store-evicting-affected-store-ratio-threshold”: 0.3,
“split-merge-interval”: “1h0m0s”,
“store-limit-version”: “v1”,
“swtich-witness-interval”: “1h0m0s”,
“tolerant-size-ratio”: 0,
“witness-schedule-limit”: 4
}
}

2

看下数据表的 region 分布，这个和数据结构有关系，已经是十分严重的写偏斜了，接着会是读偏斜。俗称 热点问题。

参考下：

3

现在空间很急迫，有什么干预方法让集群先不挂掉吗？改表设计来不及

4

什么版本的数据库？有没有做lighting导入？
部分版本导入数数据会导致倾斜。

5

你要搞清楚结构上的限制，可以通过手动分region的方式缓解。但是如果情况很紧急，估计效果不太好。

因为 tikv 压力太大，region 无法有效被 PD 调度

6

数据有很多大表。好几个库，不至于非要往这两个kv写。这点实在理解不了

7

如果是怕空间满了，可以先考虑把这两个节点上的leader驱逐走。

8

能看一下监控grafana，pd页面的operator

9

数据映射region严重倾斜啊

10

1）手动驱逐这两个KV上的副本；
2）使用Placement Rules规则应该也是可以限制避免往这两个store上写的。

11

这个和配置有关系了，没配置好的话，会这样子了

12

是不是有些实例开启了Titan

13

如何手动驱逐？

14

应该表主键行值作为 _tidb_rowid，没有提前设置预切分和打散 Region

15

目前已经驱逐了leader 但是数据还在写入

16

config set low-space-ratio 0.5 # default 0.9

自己算个百分比试试
17

Placement Rules in SQL | TiDB 文档中心

一个馊主意：参考上面的文档，找到频繁写入的表，创建policy，指定leader和follower所要用的kv节点。然后表应用该策略。缺点就是，会产生很多region的调度，IO负载应该会很高。
根本原因还是得找到数据倾斜这么高的原因。

18

目前已经解决了，调整了权重。目前控制住了

19
  • label 规划：根据实际机房 / 可用区架构重新设计 label，确保调度器能感知到所有节点的可用性。
  • 热点分析：使用 pd-ctl hot read/hot write 命令定位热点 Region，确认是否存在业务层面的热点键。
  • 长期监控：在 Grafana 中重点监控 TiKV - Space 面板，设置节点使用率 80% 的告警阈值。
20

大佬，请问您怎么调整的呀。学习分享下呢。