データクリーンアップ後にデータベースコンテナの容量増加を止める方法

データをクリーンアップした後もデータベースコンテナのサイズが増え続けることがあります。これは、削除済みの行、トランザクションログ、インデックス、コンテナログで、容量を再利用するルールがそれぞれ異なるためです。

コンテナ全体のディスク使用量が増えたからといって、データベースボリュームも増えているとは限りません。データベースのデータディレクトリ、WALまたはbinlogディレクトリ、Dockerログファイル、書き込み可能レイヤー、バックアップまたは一時ファイルのパスを個別に測定してください。そのうえで、削除済みデータの領域がデータベース内部では再利用可能でもホストには返されていないのか、実際にファイルの再構築が必要なのか、それともまったく別のファイルが増え続けているのかを確認します。

増え続けているパスを特定する

名前付きボリュームまたはバインドマウントされたデータベースディレクトリ、コンテナの書き込み可能レイヤー、ホスト側のコンテナログ、データベースのトランザクションログディレクトリ、ダンプや一時ファイルのディレクトリについて、1回のクリーンアップサイクルの前後でサイズを記録します。

PostgreSQLのディスク容量トラブルシューティングでも、同じ原則から始めます。再利用操作を選ぶ前に、容量を消費している場所を特定することが重要です。

Dockerログだけが増えているなら、データベースのクリーンアップは関係ありません。クリーンアップ後にデータファイルのサイズが大きいまま増加しなくなった場合、ホストのファイルシステム上では縮小していなくても、データベースエンジンが解放済みのページをすでに再利用している可能性があります。

データベース内部で再利用できる容量と、ディスクに返される容量を区別する

多くのトランザクションデータベースでは、行を削除した直後にテーブル中央部のファイルブロックを取り除くことはありません。代わりに、後続の挿入で再利用できるよう内部ページを解放済みとして扱いますが、基盤となるファイルのサイズは変わらないままです。

PostgreSQLは分かりやすい例です。通常のVACUUMは内部で領域を再利用しますが、ファイル中央部の領域をオペレーティングシステムに返すことは通常ありません。

クリーンアップ後、新しい挿入時にもファイルが増え続けるかを確認してください。ファイルサイズが安定し、内部の膨張だけが減少している状態は、制御不能な増加とは異なり、通常は緊急の再構築を必要としません。

汎用的なDockerクリーンアップではなく、データベースエンジンの再利用方法を使う

ホストに容量を返すことが目的なら、まずエンジンとストレージ形式を特定します。PostgreSQL、MySQLまたはMariaDB、SQLiteには共通して使える縮小コマンドはありません。また、再利用操作によっては大きなファイルの再構築やテーブルのロックが発生します。

MySQLのストレージに関する記事では、OPTIMIZEがInnoDBテーブルを再構築できることを説明しています。これは、DELETEを実行したからといって、ホストが直ちにそのバイト数を回収できることを意味するわけではありません。

再構築を伴う処理を実行する前に、データベースをバックアップし、十分な作業用空き容量があることを確認してください。大きなテーブルのコピーをもう1つ作成する必要があるコマンドを、ホームサーバーのファイルシステムがほぼ満杯の状態で実行するのは避けるべきです。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

WAL、binlog、レプリケーションの保持期間を個別に確認する

古いアプリケーションの行を削除した後でも、トランザクションログが増えることがあります。アーカイブジョブの失敗、古いレプリケーションスロット、遅延したレプリカ、長時間実行中のトランザクション、バックアップ要件による保持などによって、過去のログセグメントがディスク上に残り続ける場合があります。

最近のPostgreSQLのリカバリに関する記事では、ユーザーがクリーンアップしたばかりのテーブルデータとは別に、WALの保持がストレージを圧迫する可能性を示しています。

WALやbinlogのファイルをファイルシステムから手動で削除しないでください。データベースエンジンを通じて保持の原因を解消し、通常の再利用が再開されたことを確認します。

Dockerログを制限し、書き込み可能レイヤーを確認する

標準出力または標準エラー出力が無制限のDockerログに保存されている場合や、永続ボリュームではなくコンテナレイヤーに一時エクスポート、キャッシュ、データベースファイルが書き込まれている場合、データベースコンテナのサイズが増えているように見えることがあります。

セルフホスト型Dockerの事例では、ログローテーションを設定していない場合、コンテナログが無期限に増加する可能性が指摘されています。

何かを削除する前に、ホスト上の各大容量ファイルをコンテナ内のパスに対応付けてください。将来の増加に備えてログローテーションを設定し、データベースの状態は一時的な書き込み可能レイヤーに任せず、明示的なボリュームに保存します。

クリーンアップによって継続的な余裕が確保されたことを確認する

選択した再利用処理の後、通常の書き込み負荷を代表的な期間実行し、ホストの空き容量、データベースファイルのサイズ、トランザクションログのサイズ、Dockerログ、内部の空き容量または肥大化の指標を比較します。

PostgreSQLの容量削減に関するガイドでは、すべての削除によってオペレーティングシステム上のファイルサイズが直ちに減少すると考えるのではなく、縮小には対象を絞ったメンテナンスが必要だと説明しています。

期待されるデータベースの増加分が再利用または制限され、各クリーンアップサイクルの後にホストの容量が原因不明のまま減少しなくなれば、対策は完了です。データベースファイルを書き換える処理を行う前に、一貫したデータベースコンテナのバックアップに関するZimaSpaceの関連ガイドで、ロールバックの基準を確認してください。

よくある質問

数百万行を削除しても、ホストのディスク容量がほとんど増えないのはなぜですか？

エンジンがファイル自体を切り詰めるのではなく、データベースファイル内でそれらのページを再利用可能として扱っている可能性があります。これにより、今後の増加は抑えられても、ホストから見えるファイルサイズは変わらないことがあります。

コンテナが大きくなるたびに、完全な再構築を実行すべきですか？

いいえ。再構築を伴う処理では、ロック、作業用の一時容量、大量のI/Oが必要になることがあります。ホストに容量を戻す必要があり、エンジン固有のリスクを理解している場合にのみ実行してください。

Docker pruneでデータベースボリュームの容量を回収できますか？

そのボリュームがデータベースの永続状態の一部である限り、安全に回収することはできません。pruneを実行する前に、容量の原因がログ、イメージ、停止中のコンテナ、稼働中のデータベースデータのどれなのかを特定してください。