【TiDB 使用环境】生产环境
【TiDB 版本】v8.5.1
【操作系统】centos7
【部署方式】机器部署 40核 128G
【集群数据量】1
【集群节点数】5
62这个节点空间满了,但是region却很少。
我们是用的裸kv,用来存储kv数据。
【TiDB 使用环境】生产环境
【TiDB 版本】v8.5.1
【操作系统】centos7
【部署方式】机器部署 40核 128G
【集群数据量】1
【集群节点数】5
62这个节点空间满了,但是region却很少。
我们是用的裸kv,用来存储kv数据。
62节点启动多长时间了;
另到 /data/tikv-20160目录,看下文件有哪些。
和其它节点一起启动的,昨天写入数据时,该节点报空间满了。https://asktug.com/uploads/default/original/4X/d/6/3/d63cc1a65dbbf5c578d194dae9ab4c4287891b06.png
这张图片里的db,里面都是sst文件
是不是有空region,或者清理数据之后没有GC?
不会自动gc吗
正常情况是会gc的,出问题了,就得排查一切可能性~
有个 tidb 的话,那现在 gc 正常么?
看下 gc safe point https://docs.pingcap.com/zh/tidb/stable/pd-control/#service-gc-safepoint
不推荐使用裸 kv,官方不太可能提供技术支持。
gc是正常的。
我们并不是二维表的使用场景,只用作kv存储。
那可以试试做下 compact:专栏 - TiDB MVCC 问题处理 | TiDB 社区
看看空间能否回收。
我知道你想做裸 kv 存储,但是官方不提供技术支持的话你们要有遇到问题只能自己兜底的预期。
tikv-ctl --host tikv_ip:port compact --bottommost force -d kv -c write --bottommost force --region xxx
执行过这个命令,执行了一夜,发现没什么变化。
嗯嗯,我们是用tidb习惯了,所以用tikv比较顺手,就没有考虑其它kv存储
default 也 compact 下呢。
感谢回复,我们重新部署了6.5.3版本的,看看是否还遇到这个情况。遇到了我再试试
觉得因为磁盘满导致故障,估计数据库已经损坏,是不是可以重新创建
磁盘满是因为过期数据没有回收。
不是因该自动gc吗?
理论上是的
compact试试