Hallo, ich habe zwei große Probleme beim Stoppen und erneuten Starten von Discourse.
Erstens
Nachdem ich dies zwei- oder dreimal durchgeführt habe (egal ob mit ./launcher stop oder über Portainer), weigert sich der Container, erneut zu starten, und bleibt dauerhaft bei „rm: cannot remove ‘/shared/nginx.http.sock’: Is a directory" hängen. (Ich habe gerade bemerkt, dass sich der Socket nicht im Verzeichnis „shared", sondern in „shared/standalone" befindet. Ist das nur ein Fehler in der Fehlermeldung?)
Aus einem mir bisher unbekannten Grund wird dieser Socket nach dem Stoppen möglicherweise zu einem Verzeichnis, und die Vorlage kann ihn nicht löschen, da sie versucht, ein Verzeichnis zu löschen, obwohl es sich um einen Socket handelt. Das manuelle Löschen ändert nichts; er erscheint jedes Mal erneut.
Zweitens
„./launcher rebuild app" bleibt bei „FATAL: the database system is starting up" hängen, nachdem die erste Meldung „PANIC could not locate a valid checkpoint record" ausgegeben wurde. Ich habe alles gelesen und ausprobiert, was ich zu diesem Problem finden konnte, und die einzige funktionierende „Lösung", die ich gefunden habe, bestand darin, das Discourse-Verzeichnis mit allem Inhalt zu löschen und alles neu einzurichten … offensichtlich keine echte Lösung!
Es scheint, als würde das Stoppen des Discourse-Containers die Datenbank manchmal in einen fehlerhaften Zustand versetzen, sodass sie nicht weitermachen kann, weil sie „startet", vielleicht im Versuch, etwas zu reparieren. Doch ich habe noch nicht herausgefunden, wie ich dieses Problem beheben kann, das anscheinend nach einigen Stop-und-Start-Vorgängen auftritt.
Irgendein Hinweis? Gibt es eine Möglichkeit, Postgres zu erlauben, seine Probleme selbst zu beheben?
Nein, das ist kein Fehler. Diese Datei befindet sich in einem Volume, das im Container eingebunden wird, weshalb die Pfade je nach Perspektive unterschiedlich sind – also innerhalb des Containers im Vergleich zu außerhalb des Containers.
Dies tritt auf, wenn der Container nicht ordnungsgemäß gestoppt wurde. PostgreSQL benötigt etwas Zeit für einen sauberen Herunterfahrprozess, was wir beim Stoppen über unseren Launcher-Befehl gewährleisten. Wenn Ihre Instanz jedoch groß genug ist oder zu viele laufende Transaktionen vorhanden sind, kann es sein, dass die Datenbank nicht innerhalb der vorgegebenen Frist ordnungsgemäß herunterfährt.
Aber ich finde diese „nginx.http.sock" auch auf „shared/standalone" im Host-Dateisystem erstellt. Zunächst pink, als Socket, aber nach einer Weile, vielleicht nach einem Stopp, wird sie blau, als Verzeichnis, und der Container weigert sich zu starten, da er versucht, einen Socket zu löschen, der zu einem Verzeichnis geworden ist.
Also, was können wir tun, um dies zu beheben? Bisher experimentiere ich nur, aber wenn ich online gehe mit einigen hundert verbundenen Nutzern und hunderttausenden Beiträgen, riskiere ich dann, alles zu verlieren, nur weil PostgreSQL abrupte Unterbrechungen nicht bewältigt? Es müsste etwas unternommen werden, um eine beschädigte Datenbank zu reparieren. Kann Discourse auf einer externen PostgreSQL-Datenbank laufen, die wir verwalten können, falls der Discourse-Container nicht startet? Kurz gesagt: Im Falle von „PANIC" oder „FATAL" sollte es eine Lösung geben…
Ich versuche tatsächlich, das Problem (für die Zukunft) zu lösen, indem ich eine „containerisierte" Postgres-Datenbank einrichte und sie mit Discourse verbinde, in der Hoffnung, die Datenbank nicht zu beschädigen (oder zumindest Wartungsarbeiten durchführen zu können, selbst wenn Discourse heruntergefahren ist), wenn ich Discourse stoppe.