Das Ausführen von “./launcher rebuild app” schlägt bei db:migrate fehl. Beachten Sie, dass wir PostgreSQL v12 verwenden.
Dies hat unser Forum zerstört. Der Docker-Container wurde wieder gestartet, aber das Forum nicht. Glücklicherweise habe ich vor dem Upgrade einen VM-Snapshot gemacht und stelle ihn jetzt wieder her.
Protokoll:
Tasks: TOP => db:migrate
(Vollständige Spur durch Ausführen der Aufgabe mit --trace anzeigen)
I, [2022-04-14T15:20:51.896917 #1] INFO -- : == 20220304162250 EnableUnaccentExtension: migrating =========
-- enable_extension("unaccent")
I, [2022-04-14T15:20:51.897218 #1] INFO -- : Asynchrone Prozesse beenden
I, [2022-04-14T15:20:51.897265 #1] INFO -- : Sende INT an HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/12/bin/postmaster -D /etc/postgresql/12/main pid: 1710
I, [2022-04-14T15:20:51.897396 #1] INFO -- : Sende TERM an exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 1827
2022-04-14 15:20:51.897 UTC [1710] LOG: schnelle Herunterfahr-Anforderung empfangen
1827:signal-handler (1649949651) SIGTERM empfangen, Herunterfahren wird geplant...
2022-04-14 15:20:51.900 UTC [1710] LOG: aktive Transaktionen abbrechen
2022-04-14 15:20:51.902 UTC [1710] LOG: Hintergrundarbeiter "logical replication launcher" (PID 1719) mit Exit-Code 1 beendet
2022-04-14 15:20:51.904 UTC [1714] LOG: wird heruntergefahren
1827:M 14 Apr 2022 15:20:51.913 # Vom Benutzer angefordertes Herunterfahren...
1827:M 14 Apr 2022 15:20:51.914 * Speichere den letzten RDB-Snapshot vor dem Beenden.
2022-04-14 15:20:51.965 UTC [1710] LOG: Datenbanksystem wurde heruntergefahren
1827:M 14 Apr 2022 15:20:53.157 * DB auf Festplatte gespeichert
1827:M 14 Apr 2022 15:20:53.157 # Redis ist nun bereit zum Beenden, auf Wiedersehen...
FEHLGESCHLAGEN
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' fehlgeschlagen mit Rückgabe #<Process::Status: pid 2118 exit 1>
Ort des Fehlschlags: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec fehlgeschlagen mit den Parametern {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap fehlgeschlagen mit Exit-Code 1
** BOOTSTRAP FEHLGESCHLAGEN ** Bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen, es kann mehr als eine geben.
./discourse-doctor kann bei der Diagnose des Problems helfen.
2dcd9aeca614c9e06ef748f673eb68203db6eae5c445253b416d666663879d6d
==================== ENDE REBUILD LOG ====================
App konnte nicht neu erstellt werden.
Sie sind nicht getrennt und kein externer PG. Das PG13-Upgrade schlägt ebenfalls fehl (nicht destruktiv, im Gegensatz zum heutigen Upgrade) und ich habe ehrlich gesagt keine Unterstützung erhalten, wie ich es hier beheben kann.
Ich glaube (kann es offensichtlich nicht überprüfen), dass nur ein Container in Docker ps angezeigt wurde. Die Standardinstallation besteht jetzt aus 2 Containern?
Diese Erweiterung wurde als „vertrauenswürdige“ Erweiterung auf PostgreSQL 13+ verfügbar, wo sie von jedem Benutzer aktiviert werden kann.
Da Sie eine ältere PostgreSQL-Version verwenden, müssen Sie dies umgehen, indem Sie diese Erweiterung für den Discourse-Benutzer installieren und aktivieren und möglicherweise versuchen, Discourse auszutricksen, damit es diese Erweiterung als bereits installiert betrachtet. Oder Sie wechseln zur aktuell unterstützten PostgreSQL-Version.
OK. Zusammenfassend lässt sich sagen, dass Sie PG12 nicht mehr unterstützen. Ich schlage vor, dies im PG13-Upgrade-Thread zu posten und wahrscheinlich auch in den Ankündigungen zu 2.9.0b4.
Wenn Sie sich Sorgen über Ausfallzeiten machen, wäre eine Lösung, den Server auf den neuen Host zu replizieren. So etwas wie community/archived/setting-up-postgres-hot-standby.md at master · GoogleCloudPlatform/community · GitHub. (Sie finden möglicherweise aktuellere Anleitungen oder solche, die für Sie sinnvoller sind…). Dies würde es Ihnen ermöglichen, zur neuen Datenbank zu migrieren, während die alte weiterhin funktioniert. Aber das ist alles andere als einfach.
Das ist eine gute Idee. Wenn es MySQL, MS-SQL oder Oracle wäre, würde ich das tun, aber da ich wenig Erfahrung mit PostgreSQL habe, würde ich wahrscheinlich die Ausfallzeit in Kauf nehmen.
Meine Wiederherstellung war endlich abgeschlossen, nach über 4 Stunden. Und Discourse hat 502-Fehler ausgegeben. Dieser Snapshot wurde vor dem Upgrade aufgenommen, daher ist das super bizarr.
Als ich mir die Nginx-Logs ansah, fand ich diesen Fehler:
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.10.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require': cannot load such file -- /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb (LoadError)
Tatsächlich gehörte diese Datei root:root und hatte die Berechtigungen 0000. Als ich sie auf discourse:root und 644 änderte, um sie mit den anderen Dateien in diesem Verzeichnis abzugleichen, konnten wir den Betrieb wieder aufnehmen. Puh!
Irgendeine Idee, wie diese Datei gelöscht/geändert wurde? Sie ist auch 0 Bytes groß, super seltsam.
root@forum-app:/shared/log/rails# ls -la /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb
-rw-r--r-- 1 discourse root 0 Feb 10 17:41 /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb
Ich habe versucht, die „Wiederherstellung auf eine frische Installation“ durchzuführen, aber es funktioniert nicht, PG kooperiert nicht. Ich habe versucht, die Discourse-Version herunterzustufen und zu PG12 zurückzukehren, aber dann wird es mit all den Plugins zu einem Lichtkarneval.
Ja, ich habe die Vorlage geändert, als Teil der „Okay, das funktioniert nicht“-Strategie, damit ich zu PG12 zurückkehren konnte (obwohl das meine Frage aufwirft, wie ich PG dann aufrüsten soll ).
Ich habe neuere versucht, aber der Fehler enable_extension("unaccent") ist immer noch vorhanden, was impliziert, dass bei diesen Commits die Änderung, davon abhängig zu sein, bereits vorgenommen wurde.
Warte auf das Ergebnis dieses Versuchs.
Update: Nein, beim Wiederherstellen während der Phase „dump entpacken“ ist es fehlgeschlagen und jetzt ist es wieder tot.
Hallo, wenn Sie ein Backup von Discourse haben, würde ich vorschlagen, dies zuerst auf einem anderen Server auszuprobieren.
Ich glaube, dass Sie dieses Problem hatten, als Sie eine Instanz von Discourse aktualisiert haben, auf der eine ältere Version lief.
Versuchen Sie also, eine Kopie von Discourse zu installieren, indem Sie die yml-Datei manuell bearbeiten, um Discourse “stable” zu verwenden und die PostgreSQL-Version auf 12 zu fixieren.
Wenn der Build erfolgreich ist, versuchen Sie, das Backup wiederherzustellen. Hoffentlich wird es erfolgreich wiederhergestellt.
Wenn es erfolgreich ist, ändern Sie die PostgreSQL 12-Vorlage zurück zur Standard-PostgreSQL-Vorlage und kommentieren Sie das stabile Tag aus, damit Discourse mit den neuesten getesteten Versionen neu erstellt wird.
Ich glaube, wenn das Backup wiederherstellbar ist, sollte es dann in der Lage sein, die PostgreSQL- und Discourse-Upgrades zu überstehen.
Lassen Sie mich wissen, wenn Sie auf Probleme stoßen.
Ich bin im Moment ziemlich im “Niemandsland”. Ich habe deinen Vorschlag mit PG12 und “Stable” ausprobiert. Es funktioniert nicht, die Wiederherstellung stoppt einfach. Also lösche ich die Maschine noch einmal, um es frisch zu versuchen, denn jetzt kann sie keine App-Neuerstellung mehr durchführen.
Während diese Maschine versucht, zu “PG12 zurückzukehren”, versuche ich zu sehen, ob ich mit der anderen weiterkomme: Wenn ich versuche, PG mit einer Neuinstallation zu aktualisieren, stirbt es nach Creating missing functions in the discourse_functions schema... (beginnt, 500 zurückzugeben) und tail -f shared/data/log/var-log/postgres/current zeigt, dass der Datencontainer “bewegt” wird, obwohl er nur voller “Fehler” ist, wie zum Beispiel:
discourse@discourse ERROR: relation "user_auth_tokens" does not exist at character 34
discourse@discourse STATEMENT: SELECT "user_auth_tokens".* FROM "user_auth_tokens" WHERE ((auth_token = 'XXXX=' OR
prev_auth_token = 'XXXX=') AND rotated_at > '2022-03-09 10:21:44.051357') LIMIT 1
discourse@discourse ERROR: relation "application_requests" does not exist at character 41
discourse@discourse STATEMENT: SELECT "application_requests"."id" FROM "application_requests" WHERE "application_requests"."date" = '2022-05-08' AND "application_requests"."req_type" = 0 LIMIT 1
Obwohl Discourse tot sein mag, wird die Maschine benutzt, also… funktioniert sie, aber dauert es einfach Stunden und Stunden? Denn ich habe sie über 1 Stunde laufen lassen und nichts hat sich geändert.
An diesem Punkt denke ich schon darüber nach, ob das nicht hier hingehört, lol.
PS: Ich habe 2 verschiedene Backups ausprobiert, da ich 2 gemacht habe, bevor das Abenteuer begann.
Das ist nicht gut – Sie konnten also kein Backup von der alten Version von Discourse mit PG12 auf einer brandneuen mit PG13 wiederherstellen? Können Sie die Fehlermeldungen usw. posten? Jeder hier hat mir wiederholt versichert, dass das funktionieren würde.
Wäre gut gewesen, das vor einem Jahr zu wissen, aber danke!
Für alle, die mitlesen: Wir haben schließlich eine vollständige Wiederherstellung auf einer sauberen Neuinstallation auf einer neuen VM durchgeführt, und es hat einwandfrei funktioniert.
).