web-dev-qa-db-ja.com

メイン/ベースの不思議な蓄積のサイズを縮小します

PostgreSQL9.3の使用。約800万行を更新する長時間実行クエリがありました。明らかに問題が発生しました。 2日後、ディスク容量不足のアラートが表示されました。クエリを停止しました。これが私が見たものです。

root@server:/var/lib/postgresql/9.3/main# du -BM * | sort -n
1M  global
1M  pg_notify
1M  pg_serial
1M  pg_snapshots
1M  pg_stat
1M  pg_stat_tmp
1M  pg_tblspc
1M  pg_twophase
1M  PG_VERSION
1M  pg_xlog/archive_status
1M  mydb.opts
1M  mydb.pid
3M  pg_subtrans
7M  base/1
7M  base/12030
7M  base/12035
11M base/22029472
21M pg_clog
72M pg_multixact/offsets
315M    pg_log
444M    pg_multixact/members
516M    pg_multixact
625M    pg_xlog
3493M   base/pgsql_tmp
61851M  base/22053373
65372M  base

これに注意してください：61851M base/22053373

私の実際のデータは異なるボリュームに格納されたテーブルスペースにあるので、これは積み重なっている一時的なトランザクションのものであると思います。

同様の問題に関するオンライン投稿がいくつかありますが、私が見つけた標準的な解決策はありません。一般的に、アドバイスは「VACUUM FULLを実行する」であり、蓄積された残骸がなくなることがあります。それが私が今していることですが、時間がかかり、残りのディスク容量（3GB）がいっぱいになり、すべてがクラッシュするのではないかと心配しています。

誰もがこれを経験したことがありますか？ここには何が保存されていますか？このスペースをすばやく解放する安全な方法はありますか？または、少なくとも別の場所に移動します（テーブルスペースディスクに十分なスペースがあります）。

postgresqlpostgresql-9.3
3
panta82

私はそれを考え出した。それは私の間違いです。これは、同僚がカスタムテーブルスペースではなく、デフォルトのテーブルスペースに作成した新しいデータベースです。

同様の問題を経験している人のために、調査中に私が学んだいくつかのことをここに示します。私の場合、base/22053373はデータベースのOIDです。どのデータベースが次のようになっているのかがわかります。

SELECT oid, * FROM pg_database

内部の各ファイルは、pgタイプ（テーブルまたはその他）のoidにちなんで名付けられています。最大のファイルは、おそらく最大のテーブルからのものです。データベースに接続し、pg_classコレクションから選択してどれを見つけます。

現在、dbを使用してカスタムテーブルスペースに移動しています

ALTER DATABASE mydb SET TABLESPACE mytablespace;

これで私の問題は解決すると確信しています。

3
panta82