tidb8.5.3 tikv存储不均衡

[TiDBer_yangxi]

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

今天备份tidb到另一个集群，用的br，但是由于new_collation_enabled不一致，我强制改了备库的系统表里面的配置，然后restore一半的时候还是报错Cannot read http://10.253.99.31:8333/cairui-bigdata-temp/biz-2/163041/1218108_2022_3a99d8a6786dfb9986d467b9e1958c81a304d5c97b47cd73cde52c3a098c7801_1775637289965_default.sst into /data1/tidb-data/tikv-20160/import/.temp/e90fb0d6-22d0-4e16-b5ac-e728748b6c4b_31520784_18181_474655_default_2.sst: downloaded size 50830127, expected 56073007: [BR:KV:ErrKVDownloadFailed]download sst failed，这种失败了两次，我最后删掉了目标集群里面的库。在这个过程中我发现原先tikv的存储不是很均衡，gc时间也是停在了凌晨，导致我现在部分tikv的磁盘好像未释放空间有点爆满

查询service-gc-safepoint 这个莫名失败了
tidb@sjpt-ds-estj9:~$ tiup ctl:v8.5.3 pd --pd https://10.2.17.36:2379 service-gc-safepoint
Starting component ctl: /home/tidb/.tiup/components/ctl/v8.5.3/ctl pd --pd https://10.2.17.36:2379 service-gc-safepoint
Usage:
pd-ctl service-gc-safepoint [flags]

Flags:
-h, --help help for service-gc-safepoint

Global Flags:
–cacert string path of file that contains list of trusted SSL CAs
–cert string path of file that contains X509 certificate in PEM format
–key string path of file that contains X509 key in PEM format
-u, --pd string address of PD (default “http://127.0.0.1:2379”)

Get “https://10.2.17.36:2379/pd/api/v1/cluster”: EOF
Error: exit status 1

[Royce1220 (Ti D Ber Kwxb3 N7 I)]

感觉像是gc失败了，导致safe point没有推进导致历史版本数据没有回收？

[Royce1220 (Ti D Ber Kwxb3 N7 I)]

这样可能会导致节点之间占用的空间不一样多

[TiDBer_FpgnfJ1F]

先看是不是 GC 真卡住了

SELECT * FROM mysql.tidb WHERE variable_name = ‘tikv_gc_safe_point’;

[TiDBer_FpgnfJ1F]

– 查看长事务
SELECT * FROM INFORMATION_SCHEMA.CLUSTER_TIDB_TRX WHERE STATE != ‘Committing’ ORDER BY START_TIME ASC LIMIT 10;

– 有异常长事务直接 kill
KILL TIDB <trx_id>;

[乾坤大挪移 (Ti D Ber A8r Uup Mr)]

您提到：
• 部分 TiKV 磁盘空间爆满
• GC 时间停在凌晨
这是典型的 GC 积压导致空间未释放 问题。当 BR 恢复失败中断时，会产生大量临时数据和版本堆积。
解决方案
紧急释放空间（已爆满节点）
– 检查当前 GC 状态
SELECT * FROM mysql.tidb WHERE VARIABLE_NAME LIKE ‘%gc%’;

– 手动触发 GC（谨慎操作）
UPDATE mysql.tidb SET VARIABLE_VALUE = DATE_FORMAT(DATE_SUB(NOW(), INTERVAL 1 HOUR), ‘%Y%m%d-%H:%M:%S +0800’)
WHERE VARIABLE_NAME = ‘tikv_gc_safe_point’;

[乾坤大挪移 (Ti D Ber A8r Uup Mr)]

@TiDBer_yangxi

今天备份tidb到另一个集群，用的br，但是由于new_collation_enabled不一致，我强制改了备库的系统表里面的配置，然后restore一半的时候还是报错Cannot read http://10.253.99.31:8333/cairui-bigdata-temp/biz-2/163041/1218108_2022_3a99d8a6786dfb9986d467b9e1958c81a304d5c97b47cd73cde52c3a098c7801_1775637289965_default.sst into /data1/tidb-data/tikv-20160/import/.temp/e90fb0d6-22d0-4e16-b5ac-e728748b6c4b_31520784_18181_474655_default_2.sst: downloaded size 50830127, expected 56073007: [BR:KV:ErrKVDownloadFailed]download sst failed，这种失败了两次，我最后删掉了目标集群里面的库。在这个过程中我发现原先tikv的存储不是很均衡，gc时间也是停在了凌晨，导致我现在部分tikv的磁盘好像未释放空间有点爆满

TiKV 未释放空间的原因

1）SST import 临时文件

路径

/data1/tidb-data/tikv-20160/import

里面会有：

.temp
.sst

这些是 restore 过程产生的。

如果 restore 中断：

不会自动清理。

---

2）删除库只是逻辑删除

你执行了：

drop database

但：

数据不会立即删除

因为 TiDB 是：

MVCC + GC 回收

删除后：

数据进入：

GC 等待阶段

只有 GC 后才真正释放。

---

3）GC 停在凌晨

你说：

gc时间停在凌晨

说明：

GC 没推进

检查：

mysql.tidb

看：

tikv_gc_safe_point

可能停住了。

例如：

2024-04-08 02:00

一直不动。

那么：

drop 的库不会被清理

磁盘自然不释放。

---

4）Region 不均衡

restore 过程中：

大量 SST 导入

会产生：

大量 Region

如果 restore 中断：

调度不完整。

就会出现：

某些 tikv 写入大量数据
某些 tikv 很少

磁盘不均衡。

---

现在正确处理方案

按顺序执行。

不要跳步骤。

---

第一步：检查 GC 状态

执行

select * from mysql.tidb where variable_name like ‘tikv_gc%’;

重点看

tikv_gc_enable
tikv_gc_run_interval
tikv_gc_safe_point

正常应该类似：

tikv_gc_enable = true
tikv_gc_run_interval = 10m
tikv_gc_safe_point = 当前时间 - 1h

如果 safe_point 不动。

说明 GC 卡住。

---

第二步：手动推进 GC

执行

update mysql.tidb
set variable_value=‘10m’
where variable_name=‘tikv_gc_run_interval’;

然后：

update mysql.tidb
set variable_value=‘true’
where variable_name=‘tikv_gc_enable’;

再看

tikv_gc_safe_point

是否推进。

也可以直接触发：

gc

方法：

set global tidb_gc_run_interval=‘5m’;

等待 10 分钟。

观察：

tikv 磁盘

是否下降。

---

第三步：清理 Import 目录

进入每个 tikv

cd /data1/tidb-data/tikv-20160/import

查看

ls

如果有：

.temp
.sst

可以清理。

但注意：

必须确认没有 restore 在运行

检查

ps -ef | grep br

确认没有。

然后：

rm -rf import/.temp/*

以及

rm *.sst

这样可以立刻释放大量空间。

---

第四步：检查 Region 分布

执行

pd-ctl store

看

capacity
available
region_count

如果出现：

某个 tikv region 特别多

说明不均衡。

---

第五步：开启调度

执行

pd-ctl config show

看：

region-schedule-limit
leader-schedule-limit

建议：

region-schedule-limit = 2048
leader-schedule-limit = 64

临时提升：

pd-ctl config set region-schedule-limit 2048
pd-ctl config set leader-schedule-limit 64
pd-ctl config set replica-schedule-limit 64

让 PD 重新均衡。

---

第六步：检查 GC life time

执行

show variables like ‘tidb_gc_life_time’;

如果是：

24h

说明：

删除数据需要等 24 小时。

可以临时改成：

10m

set global tidb_gc_life_time=‘10m’;

然后等待 GC。

磁盘会快速释放

[Royce1220 (Ti D Ber Kwxb3 N7 I)]

得先排查一下gc没有推进的问题

[独善其身 (Ti D Ber Bi Rqfz5 K)]

GC推进的状态情况有日志输出吗

[纯白镇的小智 (Ti D Ber Qm Qja01 M)]

网络波动、超时、权限、备份文件损坏、目标磁盘空间不足都可能触发TiDB

[TiDBer_yangxi]

| tidb_gc_last_run_time | 20260409-00:23:17.140 +0800 |
| tidb_gc_leader_desc | host:sjpt-ds-estj9.wxxdc, pid:33907, start at 2025-10-27 15:34:17.173066227 +0800 CST m=+2.452381721 |
| tidb_gc_leader_lease | 20260409-09:59:17.203 +0800 |
| tidb_gc_leader_uuid | 668925b6598001d |
| tidb_gc_safe_point | 20260409-00:03:18.890 +0800 |
今天早上gc一次之后，现在正常了，但是我设置的10分钟一次，现在现象好像是到最大值一天才执行的，能查出是什么原因吗

[Royce1220 (Ti D Ber Kwxb3 N7 I)]

是不是有什么长事务

[Royce1220 (Ti D Ber Kwxb3 N7 I)]

tidb_gc_max_wait_time这个值设置的多少呢

[TiDBer_yangxi]

这个值就是一天

[TiDBer_yangxi]

我去看了CLUSTER_TIDB_TRX 这个里面没有大事务

[Royce1220 (Ti D Ber Kwxb3 N7 I)]

嗯，那就是每次等到了强制gc阈值的时候再回收的

[Royce1220 (Ti D Ber Kwxb3 N7 I)]

那不知道是不是br恢复失败有没有影响

[TiDBer_ClS0jENG]

• 备份失败：因 new_collation_enabled 不一致，强制修改备库系统表后，备份恢复报错 Cannot read sst / download sst failed，本质是数据一致性被破坏 + 备份文件校验不通过。
• TikV 存储不均衡：备份操作、删库操作导致 Region 分布异常，部分 TikV 节点数据未迁移 / 未均衡，出现磁盘占用差异。
• GC 异常：GC 时间停在凌晨，部分节点未释放空间，是存储不均衡的直接诱因（旧数据未清理，空间无法复用）。

[TiDBer_yangxi]

new_collation_enabled 不一致 有什么办法解决吗，我修改系统表改成一致会导致文件校验失败吗，会有什么不好的影响吗

[TiDBer_sheldon (宣恩裕)]

@TiDBer_yangxi

备库的系统表里面的配

估计是修改了备库的系统表里面的配置，导致故障。翻一下错误日志看看有没有蛛丝马迹