☰

メイン/ベースの謎のビルドアップのサイズを縮小

tag-icon • tag-icon postgresql postgresql-9.3
メイン/ベースの謎のビルドアップのサイズを縮小

PostgreSQL 9.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) がいっぱいになってすべてがクラッシュしてしまうのではないかと心配しています。

誰かこれに遭遇したことがある人はいますか? ここに何が保存されているのでしょうか? このスペースを素早く解放する安全な方法はありますか? または、少なくとも他の場所に移動します (テーブルスペース ディスクには十分なスペースがあります)。

答え1

分かりました。私のミスです。これは、カスタムのテーブルスペースではなく、同僚がデフォルトのテーブルスペースに作成した新しいデータベースです。

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

SELECT oid, * FROM pg_database

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

現在、私はデータベースをカスタムテーブルスペースに移動しています。

ALTER DATABASE mydb SET TABLESPACE mytablespace;

これで私の問題は解決するはずです。

関連情報