pg_restore：[archiver]ファイルヘッダーのサポートされていないバージョン（1.14）

私はライブサーバーと開発ボックスを持っています。それぞれpostgresqlを実行しているliveおよびdevと呼びます。私はpgadmin4で両方を表示して両方を問題なく管理でき、どちらもライブWebサイトとして動作していて、もう1つは私の開発ボックスでデバッグモードでWebサイトで実行すると、完全に機能します。かなり普通の設定。

何年もの間、私が書いたのと同じbashスクリプトを実行していて、ライブデータベースをダンプし、それを開発ボックスで復元しているので、最新のライブスナップショットを操作できます。

今日、これは私にタイトルの付いたメッセージで失敗します：

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

私はこれを診断しようとし、オンラインで広範囲に検索しましたが、困惑して失敗しました。そこで、ここで専門知識を求めています。

次の情報を共有します。

$ pg_dump --version
pg_dump (PostgreSQL) 10.11 (Ubuntu 10.11-1.pgdg18.04+1)
$ pg_restore --version
pg_restore (PostgreSQL) 10.11 (Ubuntu 10.11-1.pgdg18.04+1)
$ pg_dump --host=live.lan --port=5432 --dbname=mydb --username=myuser --format=custom > test.backup
$ ls -l test.backup 
-rw-r--r-- 1 bernd bernd 2398358 Dec 23 23:40 test.backup
$ file test.backup 
test.backup: PostgreSQL custom database dump - v1.14-0
$ pg_restore --dbname=mydb test.backup 
pg_restore: [archiver] unsupported version (1.14) in file header

pg_dumpとpg_restoreが同じバージョンであり、

$ which pg_dump
/usr/bin/pg_dump
$ which pg_restore
/usr/bin/pg_restore
$ ls -l /usr/bin/pg_dump /usr/bin/pg_restore
lrwxrwxrwx 1 root root 37 Nov 14 23:23 /usr/bin/pg_dump -> ../share/postgresql-common/pg_wrapper
lrwxrwxrwx 1 root root 37 Nov 14 23:23 /usr/bin/pg_restore -> ../share/postgresql-common/pg_wrapper

私はそれらが同じバージョンであるだけでなく、同じラッパースクリプトによって実行されていることを確認できます（これはたまたまperlスクリプトです-今ではあまり見られなくなった言語であり、私は広範囲にコード化してきました）

だから私は完全に困惑したままです。ライブマシンのバージョンに問題があると考えています。

$ ssh live.lan
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-72-generic x86_64)
$ which pg_dump
/usr/bin/pg_dump
$ which pg_restore
/usr/bin/pg_restore
$ pg_dump --version
pg_dump (PostgreSQL) 10.10 (Ubuntu 10.10-0ubuntu0.18.04.1)
$ pg_restore --version
pg_restore (PostgreSQL) 10.10 (Ubuntu 10.10-0ubuntu0.18.04.1)

ライブボックスにわずかに古いバージョンのpg_dumpがあることがわかります（私の開発ボックスのpg_dumpがライブボックスへのRPCを使用してpg_dumpを実行した場合にのみ問題になります）。

現在、私の開発ボックスでいくつかのpostgresqlのアップグレードが行われていることがわかりました。たとえば、次のようになります。

$ pg_lsclusters
Ver Cluster Port Status Owner    Data directory              Log file
10  main    5432 online postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
11  main    5433 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
12  main    5434 online postgres /var/lib/postgresql/12/main /var/log/postgresql/postgresql-12-main.log

空のログファイルが示すように、11と12のクラスターは未使用のままです。私は10を使用していますが、次のことに気づきます。

$ psql --version
psql (PostgreSQL) 12.1 (Ubuntu 12.1-1.pgdg18.04+1)
$ ssh live.lan
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-72-generic x86_64)
$ psql --version
psql (PostgreSQL) 10.10 (Ubuntu 10.10-0ubuntu0.18.04.1)

穏やかな魚ですが、明らかに原因や関連性はありません。

1. 私はpsqlではなくpg_dumpを使用しています
2. 私はライブボックスではなく開発ボックスのpgツールのみを使用しています（それらは無関係である必要があります。理論的には、データボックス全体が私の開発ボックスのpg_dumpにデータベースダンプを提供するライブボックスのポート5432を介して転送されます。

これがラブボックスのクラスターです。live.lanでpg_dumpを実行しているのはポート5432を超えています。

$ pg_lsclusters 
Ver Cluster Port Status Owner    Data directory           Log file
10  main    5432 online postgres /data/postgresql/10/main /var/log/postgresql/postgresql-10-main.log

私は現在これに深く当惑し、身もだえしています。前進する手がかりを深く感謝します。暗闇の中で釣り回らざるを得ない場合は、おそらくpostgres 11と12を再度アンインストールして、それが役立つかどうかを確認します。そうでない場合/usr/share/postgresql-common/pg_wrapper、pg_dumpとpg_restoreの2つのパスが互換性のないバージョンのパスを分岐する方法と場所を確認するためにトレースする必要があります。 。

更新：

私が発見したさらなる手掛かりは、私に回避策を許可しますが、謎を単に深めることです：

$ sudo -u postgres pg_dump --host=live.lan --port=5432 --dbname=mydb --username=myuser --format=custom > test.backup
$ sudo -u postgres /usr/lib/postgresql/10/bin/pg_dump --host=live.lan --port=5432 --dbname=mydb --username=myuser --format=custom > test2.backup
$ sudo -u postgres pg_restore -l test.backup
pg_restore: [archiver] unsupported version (1.14) in file header
$ sudo -u postgres pg_restore -l test.backup
... produces listing of contents ...
$ sudo -u postgres pg_dump --version
pg_dump (PostgreSQL) 10.11 (Ubuntu 10.11-1.pgdg18.04+1)
$ sudo -u postgres /usr/lib/postgresql/10/bin/pg_dump --version
pg_dump (PostgreSQL) 10.11 (Ubuntu 10.11-1.pgdg18.04+1)

それは信じられないほど困惑しています。考えられる唯一の説明：

1. 同じバージョン番号を報告しているにもかかわらず、2つのpg_dumpは異なります。私はこれを信じられないほど除外します。
2. pg_dumpは、/ usr / lib / postgresql / 10 / bin / pg_dumpを実行するpg_wrapperを実行します。

2つ目はもっともらしいことで、診断するためにpg_wrapperをインストルメント化する必要があります。

アップデート2：

そして、後でpg_wrapperの1つのインストルメンテーション。pg_dumpが実行されるpg_wrapperが実行されるとイベントが発生します/usr/lib/postgresql/12/bin/pg_dumpが、実行され/usr/lib/postgresql/10/bin/pg_restoreます...図を実行してください！これはpostgresqlバージョンの相互運用性バグだと考え始めました！

更新3：

をさらにpg_wrapper詳しく調べて、原因を明らかにしました。そうです、議論の余地はあるかもしれませんが、IMHOではほとんどありませんが、ある種のpg_wrapperバグであると主張します。以下がその機能です。

場合--host（その12は、ダンプを作成しpg_dumpは、私の場合には12、これはpg_dumpのためである）が提供され、それはインストールのPostgreSQLの最新バージョンを使用しています

--host提供されていない場合、ユーザー構成を調べます（私の場合は10で、これはpg_restoreの場合なので、pg_restore 10が実行され、pg_dump 12で作成されたファイルを読み取ることができません）。

では、なぜこれがバグなのでしょうか？私はuse configを持っているので、リモートホストと通信しているかどうかに関係なくそれを尊重したいのです。要点は、ホストを指定した場合、ローカル構成を無視して最新のローカルバージョンを使用することは確かに期待しないことです。（リモートホストが指定されていない場合のように）ローカル構成を尊重するか、rmeoteホストのバージョンを一致させることを期待しています。インストールされている最新バージョンに恣意的に依存することは、私見に深く疑わしいものです。

しかし、動作する回避策があることがわかりました。基本的に次の代わりに：

sudo -u postgres pg_restore -l test.backup

これは機能します：

sudo -u postgres pg_restore --host=localhost -l test.backup

皮肉なことにホストを指定することで、ローカル構成を無視し、PG 10クラスターに正常に復元すると思われる最新バージョンのpg_restoreを使用するように強制します。

ここでは別の工夫がありますが、これはWindowsのケースであることに注意してください。それがLinuxだけの場合は、これ以上読み進めないでください。ここで与えられたすべてのアドバイスは私を助けませんでした、最終的に原因IMCはより単純で、pgAdminの使用と関係がありました。新しいバージョンではnagが繰り返されるため、私の習慣はpgAdminを個別にインストールすることです（stackbuilderは使用しません）。（少なくとも）その場合、pgAdminにはユーティリティプログラムの独自のキャッシュがあり、別様に指示しない限りこれらを使用します。私のpgインスタンスはまだバージョン11（.6）ですが、最新のpgAdminにはおそらくV12ユーティリティが含まれています。これはバージョンの不一致を引き起こす可能性があります。これは、メインマシンからラップトップへの転送に成功した後、忍び寄ってきました。したがって、pgAdminで（メニュー）ファイル->設定->パスを実行し、postgresインストールに対応するバイナリパスを設定します。IMC C：\ Program Files \ PostgreSQL \ 11 \ bin。それは仕事をしました。

pgadminが最新かどうかを確認してください。この問題があり、更新することで解決しました

このエラーは、バックアップファイルの作成に使用されたpg_dumpのバージョンと、復元の試行に使用されたpg_restoreのバージョンの間のバージョンの不一致が原因で発生します。

PostgreSQLを更新すると問題が解決しました