web-dev-qa-db-ja.com

pg_restoreを使用して、新しいバージョンのPostgreSQLから復元します

PostgreSQL v9.0を実行している（本番）DBサーバーとPostgreSQLv8.4を実行している開発マシンがあります。本番DBのダンプを取り、開発マシンで使用したいと思います。開発マシンでpostgresをアップグレードできません。

実稼働マシンで、次のコマンドを実行します。

pg_dump -f nvdls.db -F p -U nvdladmin nvdlstats

開発マシンで、次のコマンドを実行します。

pg_restore -d nvdlstats -U nvdladmin nvdls.db

そして、私はこのエラーを受け取りました：

pg_restore: [archiver] unsupported version (1.12) in file header

これは、ダンプ時にcustom、tar、plain_textのいずれの形式を選択したかに関係なく発生します。

私は オンラインでの1つの議論 を見つけました。これは、開発マシンでpg_restoreの新しいバージョンを使用する必要があることを示唆しています。 9.0バイナリを開発マシンにコピーするだけでこれを試しましたが、リンクの問題が原因で失敗します（予期しないことではありません）。

Plain_textダンプを使用するポイントは、それが生の移植可能なSQLになることだと思いました。どうやらそうではありません。

9.0 DBを8.4インストールに組み込むにはどうすればよいですか？

postgresqlexportrestorepsqlpg-dump
11
Phrogz

pg_restoreはのみ「カスタム」形式で取得されたダンプを復元します。

「プレーンテキスト」ダンプを実行する場合は、psqlを使用して生成されたSQLスクリプトを実行する必要があります。

 psql -f nvdls.db dbname username
28
a_horse_with_no_name

Pg_dump/pg_restoreを使用した9.0から8.4への移動はサポートされていません。前方への移動のみがサポートされています。

ただし、通常は（データのみのダンプで）データを取得でき、場合によってはスキーマを取得できますが、それはほとんどの場合幸運であり、使用している機能によって異なります。

通常は、pg_dumpとpg_restoreのターゲットバージョンを使用する必要があります。つまり、この場合、8.4のバイナリを使用する必要があります。ただし、同じバージョンのpg_dumpとpg_restoreを使用する必要があります。どちらのツールもネットワーク全体で正常に機能するため、バイナリをコピーする必要はありません。

また、a_horse_with_no_nameが言うように、平文モードでpg_dumpを使用する方がよい場合があります。これにより、必要に応じてダンプを手動で編集できます。特に、1つのスキーマのみのダンプ（-sを使用）と1つのデータのみのダンプを作成できます。スキーマダンプのみが編集を必要とする可能性があります。

5
Magnus Hagander

Postgresqlを8.Xから9.2.4にアップグレードすることでこれを解決しました。 Mac OS-Xでbrewを使用している場合は、-を使用します。

brew upgrade postgresql

これが完了したら、新しいpostgresインストールがパスの一番上にあることを確認してください。次のようになります（バージョンのインストールパスによって異なります）-

export PATH=/usr/local/Cellar/postgresql/9.2.4/bin:$PATH
2
Blake

9.0データベースにbytea列が含まれている場合は、さらに大きな問題が発生します。

これらの列は、「hex」表現を使用してpg_dumpによってエクスポートされ、次のようにダンプファイルに表示されます。

SELECT pg_catalog.lowrite（0、 '\ x0a2'）

9.0より前のpostgresバックエンドのどのバージョンもbyteaの16進表現を理解できず、9.0側のpg_dumpにそれを使用しないように指示するオプションが見つかりません。データベースまたはサーバー全体のデフォルトの「bytea_output」設定をESCAPEに設定すると、pg_dumpによって無視されるように見えます。

ダンプファイルを後処理して、16進数でエンコードされたすべてのbytea値をエスケープされた値に実際に変更することは可能だと思いますが、byteaに通常保存されている種類のもの（画像、PDFなど）を追跡できないほど破損するリスクはありません。私を興奮させます。

2
Matthew

私は同じ問題を抱えていました。 DBのエクスポート/インポートにはpgdumpとpsqlを使用しました。

1.PGPASSWORDを設定します

export PGPASSWORD='h0ld1tn0w';

2.pg_dumpを使用してDBをエクスポートします

pg_dump -h <<Host>> -U <<username>> <<dbname>> > /opt/db.out

/opt/db.outはダンプパスです。自分で指定できます。

3.次に、別のホストのPGPASSWORDを再度設定します。ホストが同じであるか、パスワードが同じである場合、これは必要ありません。

4.別のホストにdbをインポートします

psql -h <<Host>> -U <<username>> -d <<dbname>> -f /opt/db.out

ユーザー名が異なる場合は、db.outファイルでローカルユーザー名を見つけて置き換えます。また、データではなく、ユーザー名が置き換えられていることを確認してください。

0
Somnath Muluk