postgresqlの一貫したバックアップのためのストレージスナップショット-異なるデータおよびログボリューム
私たちは多くのLinux VMをvmware /共有ストレージ環境で実行しており、それぞれが独自のpostgreSQLインスタンス（9.0と9.3の混合）を実行しています。現在、VMは単一のルートパーティション/ボリューム上にあり、バックアップ/復元プロセスに基盤となるVMFSボリュームのストレージベースのスナップショットを使用して（〜8年）大きな成功を収めています。 （そして私たちのDRサイトへの複製）。
ストレージのアーキテクチャにより、postgres WALファイルをキャッシュされていない、ほぼ書き込みボリュームに分離して、ストレージ側でのキャッシュチャーンを減らすことができます。ストレージ（Nimble Storage）を使用すると、両方のボリュームを単一の保護/スナップショットグループに割り当てることができますが、スナップショットが保護グループ内のすべてのボリュームで正確に同時に発生することをベンダーから引き出すことができませんでした-可能性は高いですが、ミリ秒単位で離れている可能性は常にあります。
そのために、pg_benchを使用して可能な限り高速にデータをDBに書き込みながら、いくつかの実験を行いました。実験後、スナップショットのボリュームを復元し、VM + postgresを起動しました
- データボリュームとログボリュームの両方のスナップショットをほぼ同時に取得-結果：DBが回復しました
- 最初にスナップショットデータボリューム、〜1分後にログボリューム-結果：DBが回復しました
- 最初にスナップショットログボリューム、約1分後にデータボリューム-結果：DBが回復しました
- WALチェックポイントが新しいデータをデータファイルに書き込んだ後、最初にスナップショットログボリューム、約3分後にデータボリューム：結果：DBが回復しました
そのため、両方のスナップショットがボリュームレベルで一貫しており、比較的近い距離にある限り、WAL /ログボリュームのスナップショットの時間に基づいて、DBの一貫したコピーが得られます。
私の質問：これは安全ですか？テストで欠落している主なケースは何ですか？何が問題になる可能性がありますか？
Postgresのドキュメントはこれが安全ではないことを示していますが、テストはかなり堅牢であることを示しているようです： http://www.postgresql.org/docs/9.1/static/backup-file.html
データベースが複数のファイルシステムに分散している場合、すべてのボリュームの正確に同時に凍結されたスナップショットを取得する方法がない場合があります。たとえば、データファイルとWALログが異なるディスク上にある場合、またはテーブルスペースが異なるファイルシステム上にある場合、スナップショットは同時でなければならないため、スナップショットバックアップを使用できない場合があります。このような状況でコンシステントスナップショット手法を信頼する前に、ファイルシステムのドキュメントをよく読んでください。
注：はい、PostgreSQLをホットバックアップモードにしたり、ストレージのVMware統合を使用してVM自体を静止したりするなど、一貫性を確保する他のオプションについては知っていますが、スピードと利便性のためにストレージのみのソリューションを探しています。クライアントへの影響はゼロです。
あなたが引用したドキュメントはそれをすべて述べていますが、同時に撮られたスナップショットに関するベンダーの主張を検証したいのなら、私はあなたを責めません。おそらく何かを明らかにする方法は、 WALシステム のストレステストをより具体的に行うことかもしれません。
例えばpgbenchベースのテストに加えて、ランダムな呼び出しをpg_switch_xlog()に追加して、ログのローテーションを強制し、チェックポイント間隔を短くしたり長くしたり（checkpoint_timeoutおよびcheckpoint_timeout）と、小さいまたは大きいwalファイルサイズを使用します。
不足しているものがない限り、スナップショットが同時に取得されなかったため、回復したDBは少しラッキーなタイミングに起因すると考えています。最後のケースでは、現在のxlogの場所が0/A1C0FFEE。次に、システムに特に重い負荷が3分間かかります。これにより、WALファイル全体が循環し、DBが0/DEADBEEFデータのスナップショットが作成されたとき。復元しようとすると、データスナップショットの時点で書き込まれていたWALファイルがなくなっており、リカバリが失敗します。