web-dev-qa-db-ja.com

インデックス付きのテーブルスペースを失った後、データベースを回復するにはどうすればよいですか?

パフォーマンスを向上させるために、PostgreSQL9.3データベースのすべてのインデックスをSSDのテーブルスペースに移動することを考えています。このSSDはRAIDアレイにないため、障害が発生してテーブルスペースが失われるシナリオを検討する必要があります。

ドキュメント(およびさまざまな ブログ )は、テーブルスペースを失うと、データベースが回復できないほど壊れてしまう可能性があることを警告しています。インデックスを失うだけの場合、これは本当に当てはまりますか?

障害が発生した後は、低速ですが機能しているデータベースがあり、デフォルトのテーブルスペース(または別のSSD上の新しいテーブルスペース)を使用して、安全にインデックスを再作成できると想定しています。私が間違っている?データベースは実際にどうなりますか?また、データベースを障害発生前の状態に復元するのは簡単ですか?

2
kontextify

SSDにどの程度の改善を期待していますか?ビジー状態のインデックスで実際に物理I/Oがほとんど発生しないのは驚くべきことであり、物理I/Oデバイスの実際のパフォーマンスの問題を解決したことはないと思います。

PostgresSQLについては、バッファリングや回復可能性などについてコメントするのに十分な知識はありませんが、回復可能性よりもパフォーマンスを選択することはおそらく良い習慣ではないと思います。

データが棚のテープにあるときに、これまで知られていなかったリカバリのバグを見つけたことを知りたくありません。 RAIDの前の数日間にDBAクラフトを学びました。毎晩、眠れない夜でした。常に、常に、常にRAIDを使用します。

ユーザーがパフォーマンスについて不満を持っている場合は、ホットフェイルオーバーを備えた10ディスクRAID5アレイに配置するために12個のSSDが必要であることをユーザーに伝えます。彼は頭を回転させて去りますが、注文書を持って戻ってくるかもしれません。

幸運を。

1
Terry