TL;DR
ClickHouse をしばらく運用してたら、じりじりとディスク残量が減ってきてしまい、原因がシステムログの溜まり過ぎだと判ったので、TTL 機能でパンクを回避したという話です。
経緯
本件は以前書いた「ClickHouse で億単位レコードの集計をざっくりベンチマーキングしてみた」の後日談的な話になります。EC2 インスタンス上で ClickHouse (公式 Docker イメージ)を半年程運用してきたところ、いつの間にかディスクの残量が2割に。調べると、コンテナ内の /var/lib/clickhouse/ 以下の使用量がじりじりと増加の一途を辿っていることが判明。アプリケーション用のデータはほぼ一定量に保っている筈なんだけどな⋯ そういや ClickHouse のログってどーやって管理されてるんだろ？ と思い、system データベースのログテーブルを覗いてみたら、運用開始当時のログレコードがそのまま残っているようでした(例)。
USE system; SELECT * FROM query_log ORDER BY event_time LIMIT 5;
これはイカン。確か ClickHouse はレコードに TTL を設定して一定期間を経たものを自動削除する機能があったはず⋯ あ、これですね↓
ログテーブルに TTL を設定する
という訳で、ログテーブル(asynchronous_metric_log error_log metric_log part_log processors_profile_log query_log text_log trace_log)に「90日以上経過したレコードを削除」するように TTL を追加してみます。ログテーブルには共通して、event_time という Datetime 方のタイムスタンプ列があるようなので、
ALTER TABLE system.<ログテーブル名> MODIFY TTL event_time + INTERVAL 90 DAY DELETE;
としてやります。
ここで注意しなければならない点として、既にログレコードが溜まり過ぎている場合は、ALTER TABLE にめっちゃ時間がかかってしまったり、場合によってはメモリやストレージの不足で処理が中断されてしまう事があるようです(当方環境)。なので、事前にテーブルのレコード数を確認しておいて、億を超えているような場合は手動で古いレコードをある程度削除しておくのが吉っぽいです。
システムの領域を勝手にいじって良いもんだろうか？ という疑念はありましたが、AI 先生に訊いてみたところ、この方法を推奨してたのでえいやっとやってみました。手当して一週間程経ちましたが、問題は発生しておらず、ストレージ使用量はほぼ一定を保っています。
