2

データベースの完全バックアップを毎晩行い、そのダンプを使用して独自の dev-db を作成します。dev-db の作成には約 10 分かかるため、毎朝、仕事に行く前に cron によってスケジュールされます。そのため、ほぼライブのデータベースで作業できるようになりました。

しかし、私が物事をテストしているときは、データベース全体または特定のテーブルだけを最初のバックアップにロールバックすると便利な場合があります。もちろん、dev-db を完全に再作成することもできますが、テストを再度実行するまでにさらに 10 分間待たなければなりません。

データベース/テーブルを特定の時点またはダンプから復元/巻き戻す簡単な方法はありますか?

pg_restore特定のテーブルを復元するために、次のように使用しようとしました。

pg_restore -d my-dev-db -n stuff -t tableA -t tableB latest-live-db.dump

-cや などのオプションも試しました--data-only。しかし、ここには、私が予見できなかったいくつかの問題があるようです。

  • 復元されたデータがコピーバックされるとき、古いデータは自動的に削除されません。
  • 復元の前に FK を明示的に削除してから再度追加しなければ、これを不可能にする外部キー制約がいくつかあります (間違っている場合は修正してください)。
  • 順不同になる PK シーケンスは、この時点ではまったく関係ありませんが、それも問題になる可能性があります。

編集：私がテスト/調査したその他のこと：

  • pg_basebackup
  • より強力な代替手段pg_basebackupは、db-server を停止し、db-files をコピーしてから、db-server を起動することです。

上記の代替案はどちらも失敗します。これは、同じクラスターで複数のローカル データベースを実行していて、合計するとディスク上に大量のデータが存在するためです。このようにデータベースを分離する方法はありません! したがって、ここでのファイル コピー操作では速度は向上しません。

4

1 に答える 1

1

クラスターではなくデータベースについて質問していると思います。私の頭に浮かぶ最初のことは、バックアップを2つの異なるデータベースに復元することです.1つはdev_db名前があり、もう1つはdev_db_back. 次に、新しいデータベースドロップが必要な場合は、withに名前をdev_db変更しますdev_db_backupdev_db

drop database if exists dev_db;
alter database dev_db_backup rename to dev_db;

その後、別のソースから名前を変更するには、バックアップをdev_db_backup再度復元します。これはスクリプトで実行できるため、削除、名前の変更、および復元が自動化されます。削除と名前の変更は瞬時に行われるため、スクリプトを開始するだけで名前の変更が完了し、新しい復元を待つ必要はありません。

10分未満の間隔で繰り返し復元する必要があるのが一般的である場合は、トランザクション内で行っていることを試すことができると思います:

begin;
-- alter the db
-- test the alterations
commit; -- or ...
-- rollback;
于 2014-09-04T08:53:07.133 に答える