集群中TIKV节点负载突然升高

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
【概述】tikv所有节点突然负载变高,IO变高
【背景】没有操作
【现象】集群中所有TIKV节点负载突然升高,IO变高(因为我们集群是普通SATA SSD,IO本就有一点高),主要是负载变高明显
【业务影响】 业务查询变慢
【TiDB 版本】Cluster version: v4.0.9
【附件】

看了下kafka上数据情况,很正常,数据量没有变多

2 Likes

麻烦吧tidb tikv的日志发一下

3 Likes

从监控上推测应该是有慢sql

3 Likes

我都看了tikv/tidb日志都正常,日志刷的很快,有挺多慢查询、查询超时的warn错误,但我们集群应该平时也应该挺多的,因为我们没有用NVME的SSD盘,用的普通的SATA盘,整个集群IO本就不低, 或者有什么关键字您 说下我过滤 下看看吧,日志刷太快了

3 Likes

我刚想起来, 这个集群我改过他gc的时长,改为了744小时/1个月, 今天好像是gc的时间,但时间也不是特别吻合,可能跟这个关系吗?

2 Likes

确定是否和gc有关 你可以看下tikv监控

1 Like

你这个gc时间这么长,应该是有影响的

2 Likes



1 Like

确实是由于gc数据量过多引起的

2 Likes

之所以设置这么长时间是因为: 我们数据量比较大,用BR做数据备份,每次完事备份要时间很长,所以修改了gc时长为1个月,用BR做备份方案是:每月1号完整备份,1号后每天基于1号做增量备份,我们的业务好像只是插入数据比较多,删改更新的场景很少,这样GC数据量应该很少吧? 新增数据也是gc的数据吗

或者有啥好的方案推荐吗?

2 Likes

那我现在只能等着gc完成是吧? 有没有办法处理一下呢,现在业务查询很慢,超时

2 Likes

https://docs.pingcap.com/zh/tidb/v4.0/garbage-collection-configuration#流控

3 Likes

你可以尝试一下这个

这边的建议是 修改br备份修改适合的gc时间,备份完成后将gc时间调整回之前。

1 Like

tikv-ctl --host=ip:port modify-tikv-config -m server -n gc.max_write_bytes_per_sec -v 10MB
请问下这个限制是针对每个tikv节点的限制是吧?
这个 10MB是针对监控里面的哪个指标呢?我怎么看我现在的gc 有多少?

1 Like

抱歉没太明白您的意思,能说的再详细一些吗, 我这边的情况是:数据量挺大大概有1.5T,每次备份的时间挺长,所以修改了gc时间为1个月,然后每月1号完整的备份数据,然后1号后每天基于1号的完整备份做增量备份

这个你可以针对对应节点即可。

1 Like

流控是针对gc写入的

1 Like

你可以在每月1号完整备份时将gc时间调整大一些,然后备份完成调整回正常值,增量备份时一样。

1 Like

突然不太理解了,这样增量备份能成功吗?
我理解的增量备份就是根据历史的gc数据去做的,如果我1号完整备份完了,改了gc时间正常30分钟,那他gc完了,后面的基于1号的增量备份还能成功吗?

1 Like

br备份,我觉得你可以理解为备份分布式物理文件。gc只是在备份期间有关,并且我记得v4.0.9开始,br备份 dumpling,都不需要手动调整gc_life了。你可以查查文档

1 Like