Ich habe ein funktionierendes Forum und möchte einige Dinge sehen, die vor ein paar Tagen durcheinandergeraten sind. Ich bin bei AWS, also erstelle ich ein AMI des funktionierenden Forums, starte eine neue Instanz und versuche, ein Backup von vor ein paar Tagen wiederherzustellen. Das schlägt mit den unten stehenden Meldungen fehl.
Es kann kein Versions- oder Schemamismatch sein, da der Server aus einem frischen Image des funktionierenden Forums erstellt wurde.
Ich habe es mit einem Neuaufbau versucht.
Ich habe versucht, ein Backup von nur einem Tag zuvor wiederherzustellen – dasselbe Ergebnis.
Das Einzige, was ich Seltsames getan habe, ist, dass ich PDF-Dateien aus dem Upload-Verzeichnis (…/uploads/original/1X/*.pdf) gelöscht habe, um etwas Platz zu schaffen. Ich werde es ohne diesen Schritt noch einmal versuchen, aber es scheint unwahrscheinlich, dass dies der Übeltäter ist.
> [2019-11-30 01:17:44] 'admin' hat die Wiederherstellung gestartet!
> [2019-11-30 01:17:44] Markiere Wiederherstellung als laufend...
> [2019-11-30 01:17:44] Stelle sicher, dass /var/www/discourse/tmp/restores/default/2019-11-30-011744 existiert...
> [2019-11-30 01:17:44] Lade Archiv in das tmp-Verzeichnis herunter...
> [2019-11-30 01:23:24] Entpacke Archiv, das kann eine Weile dauern...
> [2019-11-30 01:27:52] Keine Metadatendatei zum Extrahieren vorhanden.
> [2019-11-30 01:27:52] Validiere Metadaten...
> [2019-11-30 01:27:52] Aktuelle Version: 20191129144706
> [2019-11-30 01:27:52] Wiederherzustellende Version: 20191120015344
> [2019-11-30 01:27:52] Extrahiere Dump-Datei...
> [2019-11-30 01:50:57] ungültiger Befehl \N
> [2019-11-30 01:50:57] ungültiger Befehl \N
>
>
> < wiederholt sich etwa 100 Mal >
>
> [2019-11-30 01:51:07] ungültiger Befehl \N
> [2019-11-30 01:54:13] ungültiger Befehl \N
> [2019-11-30 01:54:13] AUSNAHME: psql ist fehlgeschlagen
> [2019-11-30 01:54:14] /var/www/discourse/lib/backup_restore/restorer.rb:331:in `restore_dump'
> /var/www/discourse/lib/backup_restore/restorer.rb:75:in `run'
> /var/www/discourse/lib/backup_restore.rb:166:in `block in start!'
> /var/www/discourse/lib/backup_restore.rb:163:in `fork'
> /var/www/discourse/lib/backup_restore.rb:163:in `start!'
> /var/www/discourse/lib/backup_restore.rb:22:in `restore!'
> /var/www/discourse/app/controllers/admin/backups_controller.rb:119:in `restore'
> usw...
Ich verbinde diese Fehler zwar mit einer Übereinstimmung der PostgreSQL-Version, aber ich habe diese \N-Fehler vor kurzem auf einem System gesehen, dem der Speicherplatz ausgegangen war (ich stellte eine Sicherung auf demselben System wieder her, von dem sie erstellt wurde). Ich habe die Diagnose des Problems nicht abgeschlossen (es war ein anderes bizarres Problem, das ich hatte, und das Wiederherstellen einer Sicherung auf einem anderen Server hat das Problem gelöst; ich habe mich gefragt, ob das Wiederherstellen auf demselben Server das Problem ebenfalls gelöst hätte).
Sie haben erwähnt, dass Ihnen der Speicherplatz ausgeht. Ich vermute, dass dies das Problem ist. Beim Wiederherstellen wird viel Speicherplatz benötigt, da die Sicherung entpackt wird. Dadurch liegen zwei vollständige Kopien der Sicherung vor, plus der Speicherplatz, der für die Wiederherstellung und für die Möglichkeit einer Rückgängigmachung bei einem Fehler benötigt wird.
Es wird noch schlimmer, aber vielleicht näher am eigentlichen Problem… Unter der Hypothese, dass ich mehr Festplattenspeicher benötige, habe ich eine neue Instanz aus meinem Image erstellt, dieses Mal mit 100 GB im Vergleich zu den vorherigen 50 GB. (Backups sind jeweils 5 GB groß und werden auf S3 gespeichert.) Diesmal erhielt ich eine explizite Fehlermeldung: „No space left on device
‘No space left on device’ tritt nicht nur auf, wenn ein Gerät keine Gigabytes mehr hat, sondern auch, wenn das Dateisystem keine Inodes mehr hat. Aber das ist hier eindeutig nicht das Problem. (iUse% wäre dann bei 100 %).
Immer noch keine Lösung. Ich dachte, ich würde es mit einer Wiederherstellung auf einer neuen Lightsail-Instanz versuchen, anstatt ein AMI meiner funktionierenden EC2-Instanz zu starten. Es schlägt immer noch fehl, aber die Fehlermeldungen sind etwas anders.
Sowohl die alte als auch die neue Instanz sind auf dem neuesten Stand, beide sind Standard-Docker-Installationen, und beide verwenden dieselbe PostgreSQL-Version:
Creating missing functions in the discourse_functions schema
Cannot restore into different schema, restoring in-place
Könnte es an Plugins liegen? Auf der „Quellseite“ sind mehrere Plugins installiert, sowohl unterstützte als auch benutzerdefinierte. Einige verwenden benutzerdefinierte Benutzerfelder. Ich habe versucht, auf saubere „Zielseiten“ mit und ohne Plugins wiederherzustellen.
Gibt es Hinweise, wie man beginnt, die Schemata zu vergleichen?
> [2019-12-07 04:51:36] 'admin' hat die Wiederherstellung gestartet!
> [2019-12-07 04:51:36] Markiere Wiederherstellung als läuft...
> [2019-12-07 04:51:36] Stelle sicher, dass /var/www/discourse/tmp/restores/default/2019-12-07-045136 existiert...
> [2019-12-07 04:51:36] Lade Archiv in tmp-Verzeichnis herunter...
> [2019-12-07 04:53:49] Entpacke Archiv, das kann eine Weile dauern...
> [2019-12-07 04:57:12] Keine Metadatendatei zum Extrahieren vorhanden.
> [2019-12-07 04:57:12] Validiere Metadaten...
> [2019-12-07 04:57:12] Aktuelle Version: 20191129144706
> [2019-12-07 04:57:12] Wiederhergestellte Version: 20191120015344
> [2019-12-07 04:57:12] Extrahiere Dump-Datei...
> [2019-12-07 04:59:10] Erstelle fehlende Funktionen im discourse_functions-Schema
> [2019-12-07 04:59:11] Kann nicht in ein anderes Schema wiederherstellen, stelle direkt wieder her
> [2019-12-07 05:05:02] ERROR: current transaction is aborted, commands ignored until end of transaction block
> [2019-12-07 05:05:03] ERROR: current transaction is aborted, commands ignored until end of transaction block
> < wiederholt sich etwa 100 Mal >
> [2019-12-07 05:05:03] ERROR: current transaction is aborted, commands ignored until end of transaction block
> [2019-12-07 05:05:03] EXCEPTION: psql failed
> [2019-12-07 05:05:03] /var/www/discourse/lib/backup_restore/restorer.rb:331:in `restore_dump'
> /var/www/discourse/lib/backup_restore/restorer.rb:75:in `run'
> /var/www/discourse/lib/backup_restore.rb:166:in `block in start!'
> /var/www/discourse/lib/backup_restore.rb:163:in `fork'
> /var/www/discourse/lib/backup_restore.rb:163:in `start!'
> /var/www/discourse/lib/backup_restore.rb:22:in `restore!'
> /var/www/discourse/app/controllers/admin/backups_controller.rb:119:in `restore'
> < Rest des Tracebacks >
In PostgreSQL läuft eindeutig etwas schief. Hast du einen Blick in die Logs geworfen?
Weit hergeholt: Könnte dies speicherbezogen sein? Kannst du versuchen, die Ausgabe von free -m während der Wiederherstellung zu überwachen und zu prüfen, ob der (virtuelle) Speicher erschöpft ist?
Ich weiß, dass es eine schwierige Frage ist, da wir nicht wissen, worin das Problem besteht, aber sollte ich die Plugins im Allgemeinen vor dem Versuch der Wiederherstellung auf der Zielseite installieren? Oder lädt und erstellt die Wiederherstellung die Plugins automatisch?
Ja, das solltest du – die Wiederherstellung übernimmt das nicht für dich.
Andererseits glaube ich nicht, dass dies dein Problem ist, da die Wiederherstellung doch für die korrekte Datenbankstruktur sorgt (einschließlich pluginspezifischer Dinge).
Ich denke, #1 ist nicht fatal und lediglich eine Nebenwirkung der Wiederherstellung am selben Ort.
Du könntest in Betracht ziehen, alle Data-Explorer-Abfragen zu exportieren und zu löschen sowie das Data-Explorer-Plugin vor der Erstellung deines Backups zu entfernen.
Alternativ könntest du den relevanten Inhalt der Tabelle plugin_store_rows hier posten?
Es gibt tatsächlich doppelte Abfragen mit doppelten (plugin_name, key)-Paaren, z. B. q:-11 und q:-2, aber eindeutigen IDs. Ich erkenne kein Muster bei den Duplikaten; sie sind beispielsweise nicht meine Lieblingsabfragen oder ähnliches.
Mein nächster Schritt wird daher sein, die Duplikate zu entfernen, ein Backup zu erstellen und dann von diesem wiederherzustellen.
Das Muster wurde gefunden. Wenn ich eine vom System gehaltene Abfrage ausführe, wird ein Duplikat erstellt, was offenbar die Wiederherstellung unterbricht.
Ich kann das auf einer sauberen Testumgebung nicht nachstellen, aber es tritt auf meiner Produktionsumgebung konsequent auf. Ich habe alle Produktions-Plugins auf der Testumgebung installiert, kann es aber immer noch nicht reproduzieren.
Wie kann ich herausfinden, was mit meiner Produktionsumgebung nicht stimmt?
Wie kann ich die doppelten Abfragen entfernen, da sie vom System verwaltet werden? Muss ich sudo -u postgres psql discourse... ausführen? Das klingt beängstigend.
