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 headerIch 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 so 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:
- Ich benutze pg_dump nicht psql
- 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 nachverfolgen /usr/share/postgresql-common/pg_wrapper, wie und wo die beiden Pfade pg_dump und pg_restore in inkompatiblen Versionspfaden voneinander abweichen .
Aktualisieren:
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 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)
Das ist unglaublich verwirrend. Die einzig möglichen Erklärungen:
- Trotz der Meldung identischer Versionsnummern sind die beiden pg_dumps unterschiedlich. Ich würde dies als unglaublich ausschließen.
- 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.
Update 2:
Und eine Instrumentierung von pg_wrapper später. Es kommt vor, dass pg_dump pg_wrapper ausführt, das ausgeführt wird, aber /usr/lib/postgresql/12/bin/pg_dumpnoch ausgeführt wird /usr/lib/postgresql/10/bin/pg_restore... Go figure! Ich fange an zu denken, dass dies ein Interoperabilitätsfehler der Postgresql-Version ist!
Update 3:
pg_wrapperEin genauerer Blick auf die Ursache hat es geschafft, 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 --hostbereitgestellt, wird die neueste Version von postgresql installiert (12 in meinem Fall und dies ist für pg_dump, also erstellt pg_dump 12 den Speicherauszug).
Wenn dies --hostnicht angegeben ist, wird die Benutzerkonfiguration konsultiert (10 in meinem Fall, und dies ist für pg_restore, daher wird pg_restore 10 ausgeführt und es kann keine von pg_dump 12 erstellte Datei lesen).
Warum ist das ein Fehler? Weil ich eine Use-Konfiguration habe und möchte, dass respektiert wird, 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.backupdas funktioniert:
sudo -u postgres pg_restore --host=localhost -l test.backupIndem 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.
quelle
sudo -u postgres pg_restore --verbose --clean --jobs=4 --disable-triggers --no-acl --no-owner -h localhost -U postgresql -d everest_development dump.psqlaber das hat nicht funktioniert. Beim Importieren einer Datenbank wird der gleiche Fehler angezeigt.muhammad@muhammad-mohsin:~/workspace_ror/everest$ psql -d everest_development -f dump.psql The input is a PostgreSQL custom-format dump. Use the pg_restore command-line client to restore this dump to a database.Antworten:
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.
quelle
Überprüfen Sie, ob Ihr pgadmin auf dem neuesten Stand ist. Ich hatte dieses Problem und habe es durch Aktualisieren behoben
quelle
Das Aktualisieren von PostgreSQL hat das Problem gelöst
quelle