Retention Policy未应用至数据库且不生效引发磁盘空间不足

• 服务器磁盘使用率即将达到阈值，排查发现此前创建的Retention Policy（数据保留策略，简称RP）未被系统自动触发执行
• 删除原有RP重新创建后，策略仍未生效，无法自动清理过期数据释放存储空间，无法定位配置错误点
• 相关配置参考：
  

1. RP绑定配置错误 #

RP是InfluxDB库级别的资源，不做全局生效，创建时未指定对应业务库、未设为默认RP、写入数据时未指定目标RP，都会导致数据不在目标RP管辖范围内，自然不会被清理。

• 执行命令检查目标库下的RP配置，确认保留时长、分片时长配置符合预期：

# 进入influx命令行后执行，替换<你的业务库名>为实际库名
SHOW RETENTION POLICIES ON <你的业务库名>

• 如果新建RP不是库的默认RP，执行命令设为默认，后续默认写入的数据都会纳入该RP管理：

ALTER RETENTION POLICY <你的RP名称> ON <你的业务库名> DEFAULT

2. 后台清理任务未正常运行 #

InfluxDB不会实时删除单条过期数据，以分片组为单位做批量清理：只有当分片组的结束时间早于RP设置的保留阈值时，后台巡检任务才会删除整个分片组。

• 执行命令检查现有分片状态，确认分片的expiry_time（到期时间）是否符合预期：

SHOW SHARDS

• 检查InfluxDB配置文件（1.x版本默认路径/etc/influxdb/influxdb.conf）中的巡检间隔配置，若参数设为0会直接关闭清理任务，间隔设置过大也会导致清理延迟，建议保持默认30分钟：

[data]
retention-check-interval = "30m"

修改配置后重启InfluxDB服务生效。

3. RP时长参数配置不合理 #

• 若RP的保留时长（duration）设为INF（永久保留），永远不会触发数据清理，需根据业务需求修改为具体时长，比如保留7天则设为168h。
• 若分片组时长（shard group duration）设置大于RP保留时长，会导致分片迟迟达不到删除条件，比如RP设为保留24小时、分片组时长设为7天，需要等7天分片周期结束后才会触发清理，期间不会释放空间。可参考规则配置分片时长：
  • 数据保留时长小于2天：分片组时长设为1小时
  • 数据保留时长2天到6个月：分片组时长设为1天
  • 数据保留时长大于6个月：分片组时长设为7天
• 参数配置错误可直接执行命令修改：

ALTER RETENTION POLICY <你的RP名称> ON <你的业务库名> DURATION <保留时长> SHARD DURATION <分片组时长>

4. 底层存储权限或挂载异常 #

若InfluxDB运行用户对数据目录没有读写权限、数据盘被挂载为只读模式，即使清理任务触发也无法删除分片文件释放空间：

• 检查数据目录权限，默认数据目录为/var/lib/influxdb/data，需保证属主为InfluxDB运行用户（通常为influxdb）
• 执行磁盘挂载检查，若挂载参数带ro标识说明为只读模式，需重新挂载为读写模式：

mount -o remount,rw <数据盘挂载路径>

磁盘即将写满时可手动触发过期分片删除，无需等待后台巡检：

1. 执行SHOW SHARDS找到expiry_time早于当前时间的分片ID
2. 执行命令直接删除对应分片释放空间：

DROP SHARD <过期分片ID>

注意：禁止删除未到期分片，避免业务数据丢失

内容的提问来源于stack exchange，提问作者InsuredApple