wake-up-neo.com

pg_restore: [archiver] nicht unterstützte Version (1.14) im Dateikopf

Ich habe einen Live-Server und eine Entwicklungsbox, nenne sie live und dev, die beide postgresql ausführen. Ich kann beide ohne Probleme mit pgadmin4 sehen und verwalten, und beide sind voll funktionsfähig, die eine auf einer Live-Website und die andere, wenn ich von einer Website im Debug-Modus auf meiner Dev-Box ausgeführt werde. Ziemlich gewöhnliches Setup.

Seit Jahren führe ich dasselbe Bash-Skript aus, das ich geschrieben habe und das die Live-Datenbank speichert und dann auf der Dev-Box wiederherstellt, damit ich den neuesten Live-Snapshot habe, mit dem ich arbeiten kann.

Heute versagt mir dies mit der betitelten Nachricht:

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

Ich habe versucht, dies zu diagnostizieren, und habe ausgiebig online gesucht, bin aber böse und habe versagt, so dass ich hier die Obergrenze für Fachwissen habe.

Um zu helfen, werde ich Folgendes teilen:

$ 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

Bei pg_dump und pg_restore handelt es sich um identische Versionen und:

$ 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

Ich kann sehen, dass es sich nicht nur um identische Versionen handelt, sondern dass sie von demselben Wrapper-Skript ausgeführt werden (das zufällig ein Perl-Skript ist - das ist eine Sprache, die Sie nicht mehr viel sehen und die ich früher ausgiebig codiert habe).

Also bin ich total ratlos. Ich denke, es könnte ein Versionsproblem mit der Live-Maschine geben:

$ 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)

Ich kann sehen, dass die Live-Box eine etwas ältere Version von pg_dump hat (was nur wichtig wäre, wenn pg_dump auf meiner Entwicklungsbox irgendwie einen RPC für die Live-Box verwendet, um ihren pg_dump auszuführen).

Jetzt gibt es vielleicht einen kleinen Hinweis darauf, dass in meiner Entwicklungsbox einige Postgresql-Upgrades durchgeführt wurden, und zum Beispiel:

$ 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

Die 11 und 12 Cluster bleiben unbenutzt, wie leere Protokolldateien belegen. Ich benutze 10. Aber ich merke das:

$ 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)

das ist leicht fischig, aber wieder nicht offensichtlich eine Ursache oder verwandt:

  1. Ich benutze pg_dump nicht psql
  2. Ich verwende nur die Entwickler-Boxen pg-Tools, nicht die Live-Boxen (sie sollten irrelevant sein, die gesamte Datenübertragung theoretisch über Port 5432 auf der Live-Box, die einen Datenbank-Dump an pg_dump auf meiner Entwicklungsbox liefert.

Hier sind die Cluster auf der Love Box und über Port 5432 läuft auf live.lan pg_dump!

$ 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

Ich bin derzeit zutiefst ratlos und erschüttert. Würde mich sehr über vorwärts bewegende Hinweise freuen. Wenn ich gezwungen bin, im Dunkeln herumzufischen, werde ich wahrscheinlich die Postgres 11 und 12 erneut deinstallieren und prüfen, ob dies hilft. Andernfalls muss ich /usr/share/postgresql-common/pg_wrapper Verfolgen, um zu sehen, wie und wo die beiden Pfade von pg_dump und pg_restore divergiert in inkompatiblen Versionspfaden.

pdate :

Ein weiterer Hinweis, den ich aufgedeckt habe, der mir eine Problemumgehung ermöglicht, aber das Rätsel einfach vertieft, lautet wie folgt:

$ 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 test2.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)

Das ist unglaublich verwirrend. Die einzig möglichen Erklärungen:

  1. trotz der Meldung identischer Versionsnummern sind die beiden pg_dumps unterschiedlich. Ich würde dies als unglaublich ausschließen.
  2. pg_dump führt pg_wrapper aus, der/usr/lib/postgresql/10/bin/pg_dump mit einigen mysteriösen Argumenten ausführt, die es brechen!

Der zweite ist plausibel und erfordert, dass ich pg_wrapper zur Diagnose instrumentiere.

pdate 2 :

Und eine Instrumentierung von pg_wrapper später. Es kommt vor, dass auf pg_dump pg_wrapper ausgeführt wird, auf dem /usr/lib/postgresql/12/bin/pg_dump Ausgeführt wird, auf dem jedoch /usr/lib/postgresql/10/bin/pg_restore Ausgeführt wird. Ich fange an zu denken, dass dies ein Interoperabilitätsfehler der Postgresql-Version ist!

pdate 3 :

Ein genauerer Blick auf pg_wrapper Hat die Ursache herausgearbeitet, und ja, ich würde behaupten, es ist ein pg_wrapper-Fehler, obwohl er möglicherweise umstritten ist, obwohl IMHO kaum. Folgendes macht es:

Wenn --Host Bereitgestellt wird, wird die neueste Version von postgresql verwendet (12 in meinem Fall und dies ist für pg_dump, also erstellt pg_dump 12 den Dump).

Wenn --Host Nicht angegeben wird, wird die Benutzerkonfiguration konsultiert (in meinem Fall 10, und dies gilt für pg_restore, sodass pg_restore 10 ausgeführt wird und eine von pg_dump 12 erstellte Datei nicht gelesen werden kann).

Warum ist das ein Fehler? Weil ich eine Use-Konfiguration habe und es gerne respektiert würde, ob ich mit einem Remote-Host spreche oder nicht. Mehr auf den Punkt, wenn ich einen Host spezifiziere, erwarte ich sicherlich nicht, die neueste lokale Version zu verwenden, ohne die lokale Konfiguration zu beachten. Ich würde erwarten, entweder die lokale Konfiguration zu respektieren (wie es der Fall ist, wenn kein Remote-Host angegeben ist) oder zu versuchen, mit der Version des Rmeote-Hosts übereinzustimmen. Das willkürliche Anlehnen an die neueste installierte Version ist meiner Meinung nach zutiefst fraglich.

ABER es stellt sich heraus, dass es eine Problemumgehung gibt, die funktioniert. Im Wesentlichen anstelle von:

Sudo -u postgres pg_restore -l test.backup

das funktioniert:

Sudo -u postgres pg_restore --Host=localhost -l test.backup

Indem wir den Host ironisch angeben, zwingen wir ihn, lokale Konfigurationen zu ignorieren und die neueste Version von pg_restore zu verwenden, die anscheinend gut funktioniert, wenn ein PG 10-Cluster wiederhergestellt wird.

12
Bernd Wechner

Hier ist eine weitere Wendung, aber bitte beachten Sie zuerst, dass dies ein Windows-Gehäuse ist. Wenn es nur Linux für Sie ist, lesen Sie nicht weiter. Alle hier gegebenen Ratschläge haben mir nicht geholfen, schließlich war die Ursache IMC einfacher und hatte mit der Verwendung von pgAdmin zu tun. Aufgrund des sich wiederholenden Problems bei neueren Versionen ist es meine Gewohnheit, pgAdmin separat zu installieren (ohne Stackbuilder). (MINDESTENS) In diesem Fall verfügt pgAdmin über einen eigenen Cache mit Hilfsprogrammen und verwendet diese, sofern Sie dies nicht anders angeben. Meine pg-Instanzen sind immer noch Version 11 (.6), aber der neueste pgAdmin wird wahrscheinlich V12-Dienstprogramme haben. Was durchaus zu einer Versionsdiskrepanz führen kann. Dies hat sich auf mich eingeschlichen, nachdem ich einige erfolgreiche Übertragungen von meinem Hauptcomputer auf einen Laptop durchgeführt hatte. Also, in pgAdmin do (Menü) Datei-> Einstellungen-> Pfade und legen Sie Binärpfade fest, die Ihrer Postgres-Installation entsprechen, IMC C:\Programme\PostgreSQL\11\bin. Das hat den Job gemacht.

1
Jan