ライブデータベースでpg_dumpを実行すると、一貫したバックアップが作成されますか？

常に変更されている3GBのデータベースがあり、サーバーを停止せずにバックアップを作成する必要があります（Postgres 8.3）。

pg_dumpは5分間実行されます。プロセス中にデータが変更された場合はどうなりますか？一貫したバックアップを取得できますか？災害がいつ発生するかを知りたくありません。

Postgresのドキュメントhttp://www.postgresql.org/docs/8.3/static/app-pgdump.htmlはこれについて何も述べていません。

マニュアルから：

データベースが同時に使用されている場合でも、一貫したバックアップを作成します。

はい、バックアップを信頼できます。もちろん、それはPostgreSQLであり、PostgreSQLのデータを信頼できます。

pg_dumpは、他の長時間実行クエリの動作と同様に、トランザクションを開始します。一貫性の保証は、MVCC実装によるものです。ダンプは、これらのルール内で常に一貫性があります。

MVCCのすべてのファジー部分は、UPDATEトランザクションが他のクライアントに見える順序やロックの取得方法などの周りにあります。pg_dumpは順序について厳密であり、データベース全体の読み取りロックを取得してダンプします。ほとんどの人にとって、それは彼らが期待することであり、使用されるメカニズムは決してトラブルを引き起こしません。主な同時実行性のリスクは、データベース構造を変更しようとしているクライアントが、ダンプの実行中にブロックされることです。ただし、ダンプの品質には影響しません。

ダンプは、設定で始まりますTRANSACTION ISOLATION LEVEL SERIALIZABLE。

トランザクション分離に関するマニュアル と、 これに関するユーザーリストの説明をお読みください。

見積もり：

バックアップには、分離レベルが設定される前にコミットされたトランザクションのみが表示されます。

基本的にpg_dump、トランザクション分離レベルを設定した後のすべては、このダンプの一部ではありません。

その間、読み取り/書き込み操作は影響を受けません（ロックされます）。

最初にこの古いスレッドについてお答えして申し訳ありません。しかし、私の経験から、pg_dump /を信頼できるという声明を確認することはできません

私は数か月前にプロジェクトをpostgresに切り替えました。そしてもちろん、提案されているように、ライブシステムからpg_dumpを使用してすべてのバックアップを作成しました。しかし、最初のバックアップチェックの後、すべてのダンプのサイズが異なることがわかりました。それらのいくつかをランダムに復元した後、いくつかのテーブルが欠落していることがわかりました。それで、なぜこれが起こるのかを分析し始め、オーバーレイするアプリケーション、例えばアプリサーバー、いくつかのテーブルとpg_dumpのロックが、それらが解放されるまで待たないことがわかりました。バックアップ期間中にサーバーを停止するたびに必要でしたが、これは良い解決策ではありません。

だから私はまだ修正を探していますが、私が言ったように、私はあなたがpg_dumpを信頼できるという声明に強く反対します。