Windows Server 2008 R2 上の Postgresql 9.0.8 物理バックアップで「アクセスが拒否されました」という結果になる

Question

私は、PostgreSQL 9 管理クックブック (Riggs/Krosing) の「スタンドアロン ホット物理データベース バックアップ」レシピに従って、Postgresql 9.0.8 データベースの物理バックアップを実行するスクリプトを作成しましたが、これを Windows Server 2008 R2 用に変更しました。

レシピのステップ 4 では、rsync を使用してすべてのデータ ファイル (pg_xlog ディレクトリを除く) をコピーしますが、robocopy.exe を使用しています (rsync は *nix ユーティリティであり、Windows を使用しているため)。問題は、多くの場合、ファイルの 1 つがコピーできず、「アクセスが拒否されました」という結果になることです。手動でファイルをコピーすると、「アクセスが拒否されました」というエラーで失敗します。長さバックアップ スクリプトが失敗した後 - これは再試行できる断続的な問題ではありません。ファイルは、PostgreSQL プロセスを再起動した後にのみコピーできます。常に異なるファイルです。昨晩は %PGDATADIR%\5432\base\24609\38122 でした。

皆さんもこのような経験をしたことがあるか、またこれを解決するために何をしたかをお聞かせください。私は次のことを検討しています:

1. バックアップの直前に PostgreSQL サーバーを再起動します (これはハックだと認めます)
2. VSHADOW、DISKSHADOW、hobocopy（注：robocopyではありません）などの開いているファイルをコピーできる何らかのユーティリティを使用する
3. PostgreSQL にすべてのロックを解除するように指示する方法があるのでしょうか?
4. [追加] 以下を参照してください - 定期的に「掃除機をかける」ことで症状が解消されるようです

Answer 1

まず最初に、料理本はしまっておいて、代わりに本を読んでくださいPostgresマニュアルのバックアップに関するセクション章全体を読んでください。それほど長くはありません。
(この章と本の間にはいくつかの類似点があることに気付くでしょう。ほとんどの Postgres の本はマニュアルの美化されたバージョンにすぎませんが、常にマニュアルを主な参考資料として参照してください。)

以下で使用する用語はすべてマニュアルからのものです (したがって、読書課題をスキップできると思ったらそれはできません。スキップすると、ひどく混乱する可能性があります)。

---

さて、実際の問題ですが、Unix ソリューションは Windows に直接移植できないことが多く、これはその 1 つのケースです。*nix システムは操作中のファイルを問題なく取得しますが、Windows は表示されているエラーをスローします。

この問題への対処方法は、実行しているバックアップの種類によって異なります。

ファイルシステムレベルのバックアップ

もしあなたが「ファイルシステムレベルのバックアップ」あなたしなければならないサーバーをシャットダウンします。これで議論は終わりです。他の選択肢はありません。このタイプのバックアップを信頼できるものにするには、データベースを完全にシャットダウンする必要があります (取得するバックアップが信頼できない場合、何の意味があるのでしょうか)。

継続的なアーカイブ / ポイントインタイムリカバリとスレーブサーバー

もしあなたがベースバックアップセットアップの一環としてポイントインタイムリカバリ& ログシッピングには 2 つのオプションがあります:

• とにかくサーバーをシャットダウンしてください。
• 開いているファイルをコピーできるツールを使用する（質問のオプション（2））

その後、ポイントインタイムリカバリ/ログシッピングのドキュメントの残りの部分に従って、スレーブサーバーを作成します。
データベースサーバーをディスクにコピーする場合は、スレーブを停止し、バックアップして再起動するだけです。マスターサーバーはオンのままなので、スレーブは再起動時に失われたデータをキャッチアップします。

また、ベース バックアップと、通常はスレーブに送信するロール トランザクション ログを、信頼性の高い優れたデータベース バックアップとして使用することもできます。これは、質問で達成しようとしていることに最も近いもののように思えますが、代わりに私が説明したスレーブ バックアップをお勧めします。メリットが多く (ホット スタンバイがある)、マスター サーバーの作業が少なくなります (バックアップのトランザクション ログをロールするための追加のチェックポイントが不要)。

その他

上記のどれも気に入らない場合は、SQL ダンプ
欠点もあります。Postgres はダンプされる各テーブルをロックする必要があるため (つまり、データベースへの書き込みがブロックされます)、SQL ダンプは他のオプションよりも低速です。データベース
が実際のサイズである場合、この方法はお勧めしません。