postgreSQLで、ディスクの空き容量が不足している問題

はじめに

Pythonで作成したETLで、PostgreSQLに接続を試みたら、ディスクの空き容量が不足していて、接続できなかった。

この問題について見ていこう。

pgAdmin4で、テーブルの中身を確認しようとしてもアクセスできなかった。

具体的には、pgAdmin4を開いてもタイムアウトしたり、「ディスク容量不足」に関するエラーメッセージが表示された。

ディスクとは、コンピュータの「本棚」のようなもの。テーブルやインデックス、ログファイルなど、すべてのデータが保存される場所である。

PostgreSQLは、たとえば新しいデータを挿入したり、クエリを実行するたびに、一時ファイル（tempファイル）を生成する。そのため、一定の空き容量が常に必要になる。

空き容量が完全にゼロになると、新たな接続すら受け付けられないという致命的な状態になる。

一時的なクエリ結果を保存しておく「キャッシュ」や、「一時テーブル」「WAL（Write Ahead Log）」と呼ばれるログファイルの肥大化も原因の一つ。

WALとは、PostgreSQLがデータの整合性を保つために書き込むログで、バックアップやレプリケーションにも利用される。これらが適切にローテーション（古いログを削除）されないと、ディスクを圧迫する。

※レプリケーション（Replication）とは、データベースの内容を複製して別の場所（サーバ）に同期する仕組みのこと。

チーム内で、同じデータベースを使っているが、チームの1人が不要なテーブルをいくつか削除したら、ディスク容量がいっぱいでDB接続できないという問題が一時的に解決した。

このとき、DROP TABLE や TRUNCATE を使ってサイズの大きいテーブルを削除または初期化することで、空き容量が回復したと考えられる。

その後、自分が再度データベースに接続して、ETL処理を実行しようとしたとき、再び「ディスク容量が不足している」というエラーが発生した。

この現象から分かるのは、根本的な解決にはなっていなかったということ。

PostgreSQLでは、削除されたデータやテーブルの実体は、VACUUM（バキューム）処理を行わないと完全には解放されない。また、ETL処理が重い一括処理（バルクロードなど）である場合、一時ファイルが一気にディスクを圧迫する。

以下のような対策が考えられる：

ディスク容量の問題は、データベースの可用性に直結する重要な課題です。

一時的な削除対応ではなく、容量監視の仕組み化やPostgreSQLの内部処理に対する理解が重要だと実感しました。

今後は、ETL実行前にディスク残量を確認したり、運用チームと連携して、ログ管理やVACUUM運用を含めた「ディスク健全性」を維持していく必要があると感じています。