Dieses empfohlene Upgrade ist fehlgeschlagen und hat mein Forum nach dem Ausfall nicht wieder zum Laufen gebracht. Ich führe jetzt discourse-doctor aus, um zu versuchen, es zu reparieren, und wenn das auch fehlschlägt, habe ich einen VM-Snapshot gemacht.
Ausgabe:
2023-04-19 18:28:31.298 UTC [42] LOG: received fast shutdown request
2023-04-19 18:28:33.651 UTC [65] LOG: shutting down
2023-04-19 18:28:33.974 UTC [42] LOG: database system is shut down
FAILED
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' failed with return #<Process::Status: pid 59 exit 2>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params "su postgres -c 'psql $db_name -c \\\"alter schema public owner to $db_user;\\\"'"
bootstrap failed with exit code 2
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
c13e1ba313de8fc84f6e2fb0f88197a908803c39791283effb8c82f55b56b6dc
Command exited with non-zero status 1
1.85user 1.84system 3:21.56elapsed 1%CPU (0avgtext+0avgdata 36996maxresident)k
197608inputs+368outputs (1133major+96509minor)pagefaults 0swaps
Bearbeiten: Discourse-doctor hat uns wieder zum Laufen gebracht.
Ich habe das im Grunde genommen angefordert, eine Stunde nach dieser Benachrichtigung ein Upgrade durchgeführt und war der Erste, der dies tat. Kein wirklicher Stress mit diesem Snapshot vorher, also habe ich hier einen für das Team übernommen, Jungs.
2023-04-19 18:28:26.755 UTC [45] LOG: Das Datenbanksystem wurde nicht ordnungsgemäß heruntergefahren; automatische Wiederherstellung wird durchgeführt.
Wenn Ihre Datenbank nicht sicher in 60 Sekunden heruntergefahren werden kann, was bei großen Datenbanken mit langsameren Festplatten vorkommt, gerät sie in diesen Zustand und schlägt einen Wiederaufbau fehl, wenn sie nicht in 5 Sekunden wiederhergestellt werden kann (was selten vorkommt, da sie groß/langsam ist).
Dies hat nichts mit den hier aufgeführten Änderungen zu tun und ist ein Problem in Discourse seit mindestens 2016.
Ahh, danke. Vielleicht sollte man bei größeren Foren wie unserem länger warten. Wenn Sie den DB-Prozess einfach beenden, müssen Transaktionen nach dem Neustart zurückgerollt werden, was sehr lange dauern kann.
Die Terminologie bezüglich Beta ist etwas verwirrend. Das Admin-Dashboard besagt, dass wir Beta ausführen. Gibt es irgendwo anders, wo wir nachsehen sollten? Mein Verständnis ist, dass Beta für Discourse empfohlen wird, basierend auf den Release-Ankündigungen, die die Verwendung des stabilen Zweigs abraten.
Wann wurden 60 Sekunden für eine sichere Abschaltung festgelegt? Wie viele Installationen sind jetzt viel größer als damals üblich?
Idealerweise sollte diese 60-Sekunden-Wartezeit eher eine Closed-Loop-Wartezeit mit einem Limit sein. Es scheint, dass das Limit höher sein sollte, wenn es jetzt viele Instanzen gibt, die jetzt anfällig sind.
Ich glaube, ich habe das schon 2016 gesehen. Aber die Dinge haben sich geändert. BEARBEITEN: Hier ist ein neuer Commit.
Ich glaube nicht, dass viele bei einer Standardinstallation, da es fast von Anfang an so war.
Äh, ja. Das ist eine große Datenbank. Ich vermute, dass nur wenige Leute eine so große Datenbank haben, die nicht auf RDS oder zumindest in einem separaten Container läuft. Sie sollten wahrscheinlich in Erwägung ziehen, auf eine 2-Container-Installation umzusteigen.
Wir werden es in Betracht ziehen. Ist die Umschaltmethode dokumentiert? Und gibt es andere Vorteile, die eine Erhöhung des 60-Sekunden-Timers nicht bieten würde?
Sie können einen neuen Container erstellen, während der alte weiterläuft. Sie müssen die Datenbank nicht herunterfahren, um einen neuen Container zu erstellen.
Es gibt jetzt ein 10-minütiges Zeitfenster für das Herunterfahren von Postgres, was Ihr aktuelles Problem lösen sollte. Sobald Sie einen weiteren Rebuild durchführen, haben Sie die 10 Minuten anstelle von einer.
Oh, dieser Typ hat gerade eine komplett neue Zwei-Container-Instanz gebaut und dann aus dem Backup wiederhergestellt. Das werden wir definitiv nicht ohne guten Grund tun, ich musste es nur tun, um die Speicherplatzanforderungen des PG13-Upgrades vor etwa 2 Monaten zu vermeiden.
Wenn es eine Dokumentation gibt, wie das ohne einen kompletten Neuaufbau von Grund auf möglich ist, dann werden wir die Wiederherstellung von Backups auf jeden Fall in Betracht ziehen.