最近、ディスクスペースは要求の厳しいリソースです。通常、データはできるだけ長く保存する必要がありますが、潜在的な「ディスク容量不足」の問題を防ぐために必要なアクションを実行しないと、これが問題になる可能性があります。
このブログでは、PostgreSQLでこの問題を検出して防止する方法と、手遅れの場合に修正に役立つ可能性のあるいくつかのオプションについて説明します。
PostgreSQLのディスク容量の問題を特定する方法
残念ながら、このようなディスク容量不足の状況にある場合は、PostgreSQLデータベースログにいくつかのエラーが表示される可能性があります。
2020-02-20 19:18:18.131 UTC [4400] LOG: could not close temporary statistics file "pg_stat_tmp/global.tmp": No space left on deviceまたはシステムログでも：
Feb 20 19:29:26 blog-pg1 rsyslogd: imjournal: fclose() failed for path: '/var/lib/rsyslog/imjournal.state.tmp': No space left on device [v8.24.0-41.el7_7.2 try http://www.rsyslog.com/e/2027 ]PostgreSQLは読み取り専用クエリを実行している間は動作を継続できますが、最終的にはディスクへの書き込みに失敗し、クライアントセッションに次のように表示されます。
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.次に、ディスクスペースを見ると、この不要な出力があります…
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pve-vm--125--disk--0 30G 30G 0 100% /PostgreSQLのディスクスペースの問題を防ぐ方法
この種の問題を防ぐ主な方法は、ディスクスペースの使用量、およびデータベースまたはディスクの使用量の増加を監視することです。このため、グラフはディスク容量の増加を監視するためのわかりやすい方法である必要があります。
データベースの拡張についても同じです：
監視するもう1つの重要なことは、レプリケーションのステータスです。レプリカがあり、何らかの理由でこれが機能しなくなった場合、構成によっては、PostgreSQLがすべてのWALファイルを保存して、レプリカが戻ってきたときに復元する可能性があります。
この監視システムはすべて、警告システムがなければ意味がありません。アクションを実行する必要がある場合：
PostgreSQLのディスク容量の問題を修正する方法
監視およびアラートシステムが実装されている（または実装されていない）場合でも、ディスクスペース不足の問題に直面している場合は、データを失うことなく（またはそれ以下）、この問題を修正するための多くのオプションがあります。可能な限り）。
最初のステップは、ディスクスペースがどこにあるかを判断することです。ベストプラクティスは、データベースストレージ用に少なくとも1つの個別のパーティションを作成することです。これにより、データベースまたはシステムが過剰なディスク領域を使用しているかどうかを簡単に確認できます。これのもう1つの利点は、損傷を最小限に抑えることです。ルートパーティションがいっぱいの場合でも、データベースは問題なく自分のパーティションに書き込むことができます。
データベーススペースの使用状況を確認する基本的な方法は、ファイルシステムのデータディレクトリを確認することです。
$ du -sh /var/lib/pgsql/11/data/
819M /var/lib/pgsql/11/data/または、データディレクトリ用に別のパーティションがある場合は、df-hを直接使用できます。
PostgreSQLコマンド「\l+」は、サイズ情報を追加するデータベースを一覧表示します。
$ postgres=# \l+
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges | Size | Tablespace
| Description
-----------+----------+-----------+---------+-------+-----------------------+---------+------------
+--------------------------------------------
postgres | postgres | SQL_ASCII | C | C | | 7965 kB | pg_default
| default administrative connection database
template0 | postgres | SQL_ASCII | C | C | =c/postgres +| 7817 kB | pg_default
| unmodifiable empty database
| | | | | postgres=CTc/postgres | |
|
template1 | postgres | SQL_ASCII | C | C | =c/postgres +| 7817 kB | pg_default
| default template for new databases
| | | | | postgres=CTc/postgres | |
|
world | postgres | SQL_ASCII | C | C | | 8629 kB | pg_default
|
(4 rows)pg_database_sizeとデータベース名を使用すると、データベースのサイズを確認できます。
postgres=# SELECT pg_database_size('world');
pg_database_size
------------------
8835743
(1 row)そして、pg_size_prettyを使用してこの値を人間が読める形式で表示すると、さらに優れたものになる可能性があります。
postgres=# SELECT pg_size_pretty(pg_database_size('world'));
pg_size_pretty
----------------
8629 kB
(1 row)スペースがどこにあるかがわかったら、対応するアクションを実行してスペースを修正できます。行を削除するだけではディスク領域を回復するのに十分ではないことに注意してください。タスクを完了するには、VACUUMまたはVACUUMFULLを実行する必要があります。
ディスク領域を回復する最も簡単な方法は、ログファイルを削除することです。 PostgreSQLのログディレクトリまたはシステムログをチェックして、そこからある程度のスペースを確保できるかどうかを確認できます。このようなものがある場合：
$ du -sh /var/lib/pgsql/11/data/log/
18G /var/lib/pgsql/11/data/log/ディレクトリの内容をチェックして、ログのローテーション/保持の問題があるかどうか、またはデータベースで何かが発生してログに書き込んでいないかどうかを確認する必要があります。
$ ls -lah /var/lib/pgsql/11/data/log/
total 18G
drwx------ 2 postgres postgres 4.0K Feb 21 00:00 .
drwx------ 21 postgres postgres 4.0K Feb 21 00:00 ..
-rw------- 1 postgres postgres 18G Feb 21 14:46 postgresql-Fri.log
-rw------- 1 postgres postgres 9.3K Feb 20 22:52 postgresql-Thu.log
-rw------- 1 postgres postgres 3.3K Feb 19 22:36 postgresql-Wed.logログを削除する前に、ログが大きい場合は、最後の100行程度を保持してから、削除することをお勧めします。したがって、空き領域を生成した後に何が起こっているかを確認できます。
$ tail -100 postgresql-Fri.log > /tmp/log_temp.logそして：
$ cat /dev/null > /var/lib/pgsql/11/data/log/postgresql-Fri.log「rm」で削除しただけで、ログファイルがPostgreSQLサーバー（または別のサービス）で使用されている場合、スペースは解放されないため、このcat/を使用してこのファイルを切り捨てる必要があります。代わりにdev/nullコマンド。
このアクションは、PostgreSQLおよびシステムログファイル専用です。データベースに重大な損傷を与える可能性があるため、pg_walコンテンツまたは別のPostgreSQLファイルを削除しないでください。
通常のPostgreSQL操作では、更新によって削除または廃止されたタプルは、テーブルから物理的に削除されません。それらは、VACUUMが実行されるまで存在します。そのため、特に頻繁に更新されるテーブルでは、定期的にVACUUM（AUTOVACUUM）を実行する必要があります。
ここでの問題は、VACUUMだけを使用してスペースがオペレーティングシステムに戻されないことです。同じテーブルでのみ使用できます。
VACUUM FULLは、テーブルを新しいディスクファイルに再書き込みし、未使用の領域をオペレーティングシステムに戻します。残念ながら、実行中は各テーブルに排他ロックが必要です。
テーブルをチェックして、VACUUM（FULL）プロセスが必要かどうかを確認する必要があります。
レプリケーションスロットを使用していて、何らかの理由でアクティブになっていない場合：
postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
slot_name | slot_type | active
-----------+-----------+--------
slot1 | physical | f
(1 row)すべてのスタンバイノードで受信されるまでWALファイルが保存されるため、ディスクスペースに問題が発生する可能性があります。
これを修正する方法は、レプリカを回復するか（可能な場合）、スロットを削除することです。
postgres=# SELECT pg_drop_replication_slot('slot1');
pg_drop_replication_slot
--------------------------
(1 row)したがって、WALファイルによって使用されていたスペースが解放されます。
前述したように、監視およびアラートシステムは、この種の問題を回避するための鍵です。このように、ClusterControlは、システムを稼働させ、必要に応じてアラームを送信したり、データベースクラスターの動作を維持するためのリカバリアクションを実行したりするのに役立ちます。さまざまなデータベーステクノロジーを展開/インポートし、必要に応じてスケールアウトすることもできます。