浅谈TiKV集群运维问题排查与修复——磁盘空间占

一、背景介绍

在业务快速扩张的年代，vivo 内部的很多业务为了可以快速上线，给现网功能提供支撑，在 KV 类型的选型下许多场景都选用了轻量快速的 Redis 集群。但是随着业务的不断发展与稳定，当数据量级达到一定程度的时候，数据性质开始发生变化：有的历史 Redis 集群热度下沉，但是依然基于 Redis 集群作为载体进行 KV 存储。这种类型的数据不仅量大，而且访问频次不高。

业务的发展阶段变化也会对数据载体的诉求也会相应发生变化。对于大规模而热度不算高的 KV 存储场景而言，业务对降低成本的诉求日益增多。为了满足这种类型的业务诉求，vivo 基于 TiKV 自研一套 KV 系统供业务使用。为了让业务可以更加便捷的接入，我们基于计算存储分离架构进行设计，把 TiKV 作为存储层开发 Redis 协议兼容的 KV 存储组件。架构如下：

为了让机器资源可以得到更加高效的利用，我们使用不同业务混合部署的模式在相同的服务器上部署 TiKV 实例。随着集群使用的场景日益增多，使用过程中面临的问题也会各种各样，TiKV 集群会出现诸如磁盘空间占用与预期不符，读写时延抖动，负载（存储占用，region 个数，或者热读热写）不均衡等等的问题。

这次先从磁盘空间占用问题着手，从几个比较常见的排查点进行着手和排查。其他的问题排查和修复会通过其他的文章后续进行分享。

二、问题与排查

磁盘空间的占用空间如果较高，例如磁盘剩余空间占比低于 pd 的 low-space-ratio，会导致 pd 的 scheduler 判断节点所在机器磁盘资源不足，无法执行调度作业，导致集群的各种负载会越发不均衡；更加严重的情况可能会直接影响当前物理机器上的所有 TiKV 实例的可用性。

当前我们使用 TiKV 的 4.X，5.X 以及 6.X 版本，其中有的特性在更新的版本中会得到修复。

从我们运维的经验来看，磁盘空间占用构成主要分以下几块：

• 日志
• buffer （占位文件）
• 数据

后续将根据这几种维度在 TiKV 的日常运维工作中进行排查和分析。总的来说，组成如下：

（1）日志

① Tikv 日志

② RocksDB 日志

（2）buffer

① 占位符文件

（3）数据

①RocksDB 数据

• raft 数据（老版本）
• KV 数据

② titan 数据

• raft 数据（老版本）
• KV 数据