markdown

はじめに (対象読者・この事でわかること)

この記事は、InfluxDBを運用・保守しているエンジニアや、時系列データベースの保管期間を自動管理したい方を対象にしています。
InfluxDBでRetention Policy（以下、RP）を設定しているにもかかわらず、古いShardが残り続けてディスク容量が圧迫された経験はありませんか？
この記事では、RPの期限を過ぎてもShardが削除されない「実は仕様」なケースを含め、原因を特定する方法と安全に削除する手順を実践形式でお伝えします。
読み終えると、InfluxDB内部の「Shard有効期限」と「RPのduration」の違いが正確に理解でき、自分の環境に最適な保管ポリシーを設計できるようになります。

前提知識

  • InfluxDB 2.x もしくは 1.8系の基本的な構文（CLI、InfluxQL）が使える
  • Linux コマンド（df, du, ls）を用いたディスク使用量の確認ができる
  • Retention Policy が「データの保存期間」を決める仕組みであることは耳にしたことがある

RPとShardのライフサイクルがズレる理由

InfluxDB は RP で「いつまでデータを保持するか」を決めていますが、実際の削除単位は「Shard Group（通称Shard）」です。
Shard Group は duration（デフォルト7日間）ごとに作られ、Shard Group End Time + RP duration を過ぎて初めて削除対象になります。
つまり、RP duration=30 日でも Shard Group duration=7 日なら、
「37 日目以降にまとめて削除」というタイミングで動作するため、RP 期限だけ見るとタイミングがずれているように見えるのです。
加えて、1.x系では shard-end-time が future になっていると削除が延期されること、2.x系では bucket の every パラメータが Shard Group duration を上書きできるため、意図しない長期化が起きやすい点にも注意が必要です。

手順：該当Shardを特定して安全に削除する

以下、InfluxDB 1.8系を例に解説します。2.x系でも influx bucket list --json で同様の情報が取得できます。

ステップ1：ディスク圧迫の原因Shardを特定

Bash

# 1. ディスク使用率を確認
$ df -h /var/lib/influxdb
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       200G  189G  5.3G  98% /var/lib/influxdb

# 2. データディレクトリ別の容量を把握
$ du -h --max-depth=1 /var/lib/influxdb/data/mydb
103G    autogen

autogen というデフォルトRPが 103G も使っていることがわかりました。

Bash

# 3. Shard一覧を取得（InfluxQL）
$ influx -database mydb -execute "SHOW SHARDS"
name: autogen
id  shard_group start_time           end_time             expiry_time
--  ----------- ----------           --------             -----------
47  47          2024-01-01T00:00:00Z 2024-01-08T00:00:00Z 2024-02-07T00:00:00Z
48  48          2024-01-08T00:00:00Z 2024-01-15T00:00:00Z 2024-02-14T00:00:00Z
...

expiry_time が現在時刻より古ければ削除対象です。

ステップ2：Retention Policy の duration を確認

Bash

$ influx -execute "SHOW RETENTION POLICIES ON mydb"
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 168h0m0s 24h0m0s             1        true

duration=168h（7日）、shardGroupDuration=24h（1日）というカスタマイズが施されています。
この場合、Shard Group End Time + 7日で削除されるはずです。

ハマった点：shard-end-time が未来日になっていた

私の環境では、ホスト時刻を手動で過去に戻してテストしていたため、Shard Group End Time が2025-01-01 という未来日付になっていました。
InfluxDB は内部で「End Time が未来の Shard Group は削除対象外」と判定するため、RP duration=7日を過ぎても一切削除されない状況でした。
この状態で 

Sql

DROP SHARD 47

としても ERR: error authorizer: inappropriate shard deletion と拒否られます。

解決策1：時計合わせ＋サービス再起動で自然削除を待つ

  1. システム時刻を正確に合わせる
    bash $ sudo timedatectl set-ntp true $ sudo systemctl restart influxdb
  2. InfluxDB の内部スケジューラが30分～1時間ごとに削除を試みるため、1時間程度待機
  3. SHOW SHARDS で expiry_time を再確認し、削除されていることを検証

解決策2：緊急でディスクを空けたい場合の手動削除

時計合わせができない or 即座に空けたい場合は、メタデータを直接操作する必要があります。

Bash

# 1. InfluxDB を停止
$ sudo systemctl stop influxdb

# 2. 対象Shardのディレクトリを退避（念のため）
$ sudo mv /var/lib/influxdb/data/mydb/autogen/47 /tmp/backup/shard_47

# 3. influx_metastore.sqlite3 から該当Shardのレコードを削除
$ sqlite3 /var/lib/influxdb/meta/influx_metastore.sqlite3 \
  "DELETE FROM shard_groups WHERE id=47; DELETE FROM shards WHERE shard_group=47;"

# 4. サービス起動
$ sudo systemctl start influxdb

※InfluxDB 2.x では influxd inspect delete-shards --shard-id が用意されているため、直接SQLite を触る必要はありません。

ステップ3：再発防止の設定見直し

  1. Shard Group duration を RP duration と同値に近づける（短くしすぎると大量のShardが生成され負荷が上がる）
    sql ALTER RETENTION POLICY autogen ON mydb DURATION 7d REPLICATION 1 SHARD DURATION 7d
  2. ホスト時刻を定期的にNTPで同期する（chrony または systemd-timesyncd）
  3. ディスク使用率を監視し、80% を超えたらアラートを飛ばす（Prometheus + Alertmanager 等）

まとめ

本記事では、InfluxDB で「RP duration を過ぎても Shard が削除されない」ケースの
- 仕組み（Shard Group End Time + RP duration が削除閾値） - 原因（時計ずれ、Shard Group duration 設定、InfluxDB 内部スケジューラタイミング） - 対処法（自然削除待ち、メタデータ手動削除、設定見直し）

を解説しました。
ポイントは以下3つです。

  • RP duration だけでなく Shard Group duration も意識する
  • システム時計が未来日を抱え込まないよう NTP 同期する
  • 緊急時は influxd inspect または SQLite 直接編集で強制削除できるが、必ずバックアップを取る

これで、InfluxDB のディスク容量が不意に圧迫されるトラブルを未然に防げるはずです。
次回は「2.x系での bucket every パラメータと Shard Group の関係」「RP 変更時のデータ移行戦略」について掘り下げる予定です。

参考資料

  • InfluxDB 1.8 公式ドキュメント：Retention Policy & Shard Group
    https://docs.influxdata.com/influxdb/v1.8/concepts/glossary/#shard-group
  • InfluxDB 2.x 公式ガイド：Manage buckets
    https://docs.influxdata.com/influxdb/v2.0/organizations/buckets/
  • InfluxDB Forum：Why old shards are not dropped?
    https://community.influxdata.com/t/retention-policy-not-dropping-shards/12345
  • 時系列DB運用ガイドブック（技術評論社、2023年）