In einer Multi-Node-Einrichtung mit einem web_only-Container hinter einem Load-Balancer wurde festgestellt, dass einige Einstellungen nach der Änderung nur auf einem einzelnen Knoten angewendet werden (wahrscheinlich auf dem Knoten, mit dem ich über den Load-Balancer verbunden war, als die Änderungen vorgenommen wurden). Ich habe dies insbesondere bei Folgendem bemerkt: Global notice, Globally pinned posts und jetzt zuletzt bei der Änderung des Themas zur Aktualisierung eines benutzerdefinierten Themas.
Am Ende werden Änderungen für Benutzer nur dann dargestellt, wenn der Load-Balancer sie mit demselben Knoten verbindet, auf dem sie vorgenommen wurden. Dies führt in einigen Fällen zu gemischten Seitenaufrufen und einer unübersichtlichen Darstellung der Website.
Nun zur Frage. Muss ich nach solchen Änderungen einen Konfigurations-Neuladebefehl in Rake auf allen Knoten ausführen oder muss vielleicht eine bestimmte Umgebungsvariable beim Ausführen des Containers hinzugefügt werden, damit Auto-Reloads/Cluster-Modus die Konfiguration automatisch an die Geschwisterknoten weitergeben?
Danke! Ich hatte das Gefühl, dass mir da etwas fehlte. Gibt es vielleicht einen Dokumentationsartikel, der erwähnt, nach welchen Konfigurationsänderungen solche Aktionen erforderlich sind? Ich habe die Dokumentationsartikel kurz durchgesehen und nichts Spezielles dazu oder zur HA-Einrichtung bemerkt.
Nur zur Überprüfung: Haben Sie eine gemeinsame Redis-Datenbank zwischen allen Knoten? Das ist für das Funktionieren von Discourse unerlässlich.
(Einige andere Anwendungen funktionieren mit einer Redis pro Knoten, aber der Versuch, dies mit Discourse zu tun, wird die Art von Problemen verursachen, die Sie beschreiben)
Ja. Redis wird von allen Discourse-Knoteninstanzen gemeinsam genutzt. Ich habe das Setup so konzipiert, dass es hochverfügbar (HA) ist, daher gibt es separate S3/Redis/PostgreSQL-Instanzen.
Beobachten Sie Fehlermeldungen wie Global messages on xx timed out, message bus is no longer functioning correctly in /logs?
Zuvor stellte ich fest, dass Zeitüberschreitungen auftreten, wenn Redis und der Message Bus auf separaten Hosts laufen, was zu einer fehlerhaften Synchronisierung zwischen verschiedenen Unicorn-Workern führt.
Meine Problemumgehung bestand darin, den gesamten Unicorn-Server regelmäßig neu zu laden.
Ah. Immerhin gab es diese Meldungen Global messages on xx timed out, message bus is no longer functioning correctly. Aber ich habe fälschlicherweise im tatsächlichen Log-Verzeichnis nachgesehen. Wenn ich mir jetzt im Fehlerbereich der Web-Oberfläche die Protokolle ansehe, habe ich tatsächlich die von Ihnen erwähnten Einträge bemerkt. Ich muss mich daran gewöhnen, dass bei Discourse unterschiedliche Fehler an unterschiedlichen Stellen angezeigt werden. Es ist trotzdem schön, Funktionen auf der Discourse-Webseite zu haben.