web-dev-qa-db-ja.com

部分的に構築され、停電によって終了したインデックスによって使用されたスペースを再利用する方法

Mac（10.10.4）でpostgres（postgis）9.4.2を実行しています。

私はいくつかの大きなテーブル（数TB）を持っています。

そのうちの1つで約1週間かかるインデックス作成中に、停電がバッテリーユニットとシステムよりも長く続いたときにインデックスが終了するポイントに近いと予想されるので、利用可能なHDスペースの低下を観察しました降りた。バッファをオフにして、fillfactor=100静的データソースであるため、ビルド中。再起動時に、ドライブに残っている使用可能なスペースは、インデックスビルドのほぼ終了時とまったく同じです。真空分析はスペースを解放しません。

テーブルを落として再度摂取してみましたが、スペースは減りませんでした。現在、インデックスを作成するための十分なスペースがない場所にいます。

インデックスの構築中に生成されたファイルは、停電中にマシンがダウンした方法が原因でシステムによって削除できない場所でスタックしていますか？

テーブルサイズ+データベース内のインデックス（そのドライブ上の唯一のデータ）を見ると、合計すると約6TBになります。ドライブは8TBであり、ドライブに残っている500GBより少ないので、どこかに約1.5TBが失われているようです。これは、インデックスのサイズとほぼ同じです。 。

何か案は？

postgresqlindexpostgresql-9.4disk-spacevacuum
9
dkitchel

通常、postgresを再起動すると、クラッシュリカバリプロセスにより、ロールバックされたインデックスに関連するファイルがデータディレクトリから削除されたはずです。

それが機能しなかった、または少なくとも手動でチェックする必要があると仮定しましょう。

Datadirにあるファイルのリストは、次のようなクエリで設定できます。

_select pg_relation_filenode(oid)
   from pg_class
  where relkind in ('i','r','t','S','m')
    and reltablespace=0
  order by 1;
_

_reltablespace=0_はデフォルトのテーブルスペース用です。問題のあるインデックスがデフォルト以外のテーブルスペースに作成された場合、この_0_は、そのOID in _pg_tablespace_）で置き換える必要があります。

relkindのi、r、t、S、mは、それぞれインデックス、テーブル、トーストスペース、シーケンス、マテリアライズドビューに対応しています。これらのオブジェクトはすべて、名前がpg_relation_filenode(oid)と一致するファイルにデータを持っています。

ディスクでは、データファイルは_$PGDATA/base/oid/_の下にあります。ここで、oidは_select oid,datname from pg_database_によって取得されたデータベースのoidです。デフォルトのテーブルスペースについて話していない場合は、代わりにbaseを_PG_version_somelabel_に置き換えます。

そのディレクトリ内のrelfilenodesに一致するファイルをリストしてソートします。

_ls | grep -E '^[0-9]+$' | sort -n > /tmp/list-of-relations.txt
_

（実際には、1Gbより大きい関係の最初のセグメントのみが保持されます。何にも接続されていない残存セグメントがある場合は、個別に検討する必要があります）

上記のクエリの結果でそのファイルを比較します。

Dbが認識しているオブジェクトに対応しない残存データファイルがある場合、それらはその差分に表示されます。

5
Daniel Vérité