Wir betreiben seit einigen Jahren eine selbst gehostete Discourse-Instanz unter https://discourse.bokeh.org. Im Großen und Ganzen war sie absolut zuverlässig und erforderte kaum Wartungsaufwand. Insbesondere das Durchführen von Updates verlief in der Regel völlig problemlos und ohne jegliche Schwierigkeiten.
Heute jedoch, nach einem Update auf 2.7beta7 (das zunächst ohne Fehler abzulaufen schien), ist unsere Seite komplett zusammengebrochen. Sie hat noch eine Weile mit falsch gerenderten Seiten und Fehlern in der JavaScript-Konsole vor sich hin gelungelt, doch nach einem Versuch, ein Rollback durchzuführen, wurde die Benutzeroberfläche unbrauchbar. Nach dem Einloggen auf den Droplet habe ich zudem vergeblich folgende Versuche unternommen:
Rebuild
./launcher rebuild app
Dies ist bei mehreren Versuchen auf unterschiedliche Weise fehlgeschlagen.
Discourse Doctor
./discourse-doctor
Restore
./launcher enter app
discourse restore <backup file>
Hmm. Vielleicht ist da nur ein einziger defekter Beitrag? Ich vermute, du müsstest die Datenbank wiederherstellen, den Fehler beheben und dann die Sicherungsdatei mit der neuen Datenbank neu erstellen. Aber es ist wirklich schwer zu sagen.
Hast du ein frisches Droplet-Backup oder einen Snapshot, den du wiederherstellen kannst?
Leider nein. DO-Backups erfolgen nur wöchentlich, und ich hatte tägliche Discourse-Backups in S3 eingerichtet, wobei ich eine Woche an frischen Backups und ein Jahr an älteren in Glacier aufbewahrte. Aufgrund meiner bisherigen positiven Erfahrungen mit vielen Discourse-Upgrades hatte ich geglaubt, dass dies sowohl ausreichend als auch besser sein würde (und ich hatte zuvor erfolgreich Testwiederherstellungen durchgeführt).
Nun, eigentlich ein Update. In einem Anfall der Verzweiflung habe ich das Wiederherstellungsskript einfach hart abgebrochen, während des Schritts „Dateien zu S3 synchronisieren“, bevor es sich über den einen fehlerhaften Beitrag beschwerte und einen Rollback startete.
Die Website ist tatsächlich wieder hochgefahren und im abgesicherten Modus zugänglich. Ich habe die Theme-Komponente „KOPPIEREN EINFÜGEN“ für Codeblöcke deaktiviert, die anscheinend jetzt völlig inkompatibel mit der neuesten Beta ist. Danach scheint die Website tatsächlich weitgehend in Ordnung zu sein, sogar ohne abgesicherten Modus. Aber:
Gibt es empfohlene Maßnahmen, um sicherzustellen, dass alles so „aufgeräumt“ wie möglich ist? Zum Beispiel Assets erneut zu S3 hochladen und „neu backen“? Wo finde ich die besten, aktuellsten Anweisungen dafür?
EDIT: Soweit ich das beurteilen kann, ist alles wieder normal. Bilder in alten Beiträgen laden korrekt von S3/CDN. Meine Frage ist also: Wenn wir Bilder zu S3 hochladen, sollte diese Option dann deaktiviert sein?
Uploads in geplanten Backups einschließen. Wenn dies deaktiviert wird, wird nur die Datenbank gesichert.
Ich dachte, es böte eine zusätzliche Redundanzebene, wenn es aktiviert ist, aber es scheint die Quelle all dieser Probleme während der Wiederherstellung zu sein?
Als ich das letzte Mal zu einem anderen Hosting-Anbieter gewechselt bin, hatte ich auch Probleme mit S3 bei der Wiederherstellung. Deshalb habe ich danach gefragt, und die Antwort war: Ja. Wenn du deine Bilder in S3 speicherst, musst du das Backup ohne Uploads erstellen. Nur die Datenbank. Ich weiß aber nicht, ob das in deinem Fall die Lösung ist. Wenn du es ausprobierst, erstelle vorher unbedingt einen Snapshot.
@pfaffman Danke! Die Seite scheint jetzt völlig normal zu funktionieren, aber ich würde einen kurzen Blick / eine Sanity-Check bei Gelegenheit nicht ablehnen, falls Sie dazu bereit sind. Ich habe Ihre kommerziellen Kontaktdaten für etwaige zukünftige Notfälle notiert.
Hier ist ein Retro, falls es für andere hilfreich sein könnte
ZUSAMMENFASSUNG
Nach einem (erfolgreichen) Upgrade hat ein inkompatibles nicht-offizielles Theme-Komponenten-Plugin die Benutzeroberfläche der Seite beschädigt. Dies war zu diesem Zeitpunkt nicht bekannt, sodass der Wiederherstellungsprozess aus einem Backup eingeleitet wurde, der jedoch aufgrund einer weniger als idealen Konfiguration auf Probleme stieß.
DETAILS
Ein Upgrade auf 2.7beta7 wurde eingeleitet und erfolgreich abgeschlossen.
Nach dem Upgrade war die Benutzeroberfläche der Seite jedoch stark beeinträchtigt: Beitragsinhalte fehlten vollständig, die obere Navigation (einschließlich Benutzer-/Login-Bereich) fehlte ebenfalls vollständig, und die JS-Konsole meldete Fehler.
Der Grund dafür war ein inkompatibles Drittanbieter-Theme-Modul zum Kopieren und Einfügen von Codeblöcken, was jedoch zu diesem Zeitpunkt nicht bekannt war.
Ebenso unbekannt war zu diesem Zeitpunkt die Möglichkeit, den abgesicherten Modus zu aktivieren. Hätte man dies gewusst, hätten die verbleibenden Probleme vermieden werden können.
Der Zugriff auf \admin wurde durch direkte Navigation ermöglicht, und ein Versuch zum Rollback wurde eingeleitet. Dies führte sofort zum Abmelden des Benutzers, und es schien keine Möglichkeit zu geben, sich mit der beschädigten Benutzeroberfläche erneut anzumelden.
Ich meldete mich am DigitalOcean-Droplet an, um eine manuelle Wiederherstellung mit dem neuesten Backup-Tarball aus S3 einzuleiten.
Viele Wiederherstellungsversuche scheiterten kurz vor dem letzten Schritt, nach dem Hochladen der S3-Assets, aufgrund eines Fehlers in einem einzelnen Beitrag.
Offensichtlich liegt dies daran, dass Wiederherstellungen, die versuchen, Assets erneut auf S3 hochzuladen, fehleranfällig sein können (mehrere Berichte dazu auf Meta).
Es war jedoch nicht notwendig, Upload-Assets zu sichern, da diese bereits auf S3 gespeichert sind!
Während eines der vielen Wiederherstellungsversuche wurde die Seite auch komplett gelöscht, um einen „sauberen Anfang
Wenn ich einen Vorschlag zum Wiederherstellungsprozess machen könnte, wäre es, einige Optionen anzubieten, um ihn widerstandsfähiger zu gestalten. Wenn also nur ein fehlerhafter Beitrag eine erfolgreiche Wiederherstellung verhindert, würde ich bei der Frage „Fehlerhaften Beitrag löschen?
Das wird in einer der nächsten 2.8-Betas enthalten sein. Leider ist es für das kommende 2.7-Release noch nicht bereit.
Es tut mir leid, dass ich deinen Hilferuf nicht früher gesehen habe. Hier ist ein Tipp für alle anderen, die Probleme mit Wiederherstellungen haben, bei denen die Backups auf S3 gespeichert sind: Extrahiere die Datei dump.sql.gz aus deinem Backup und benenne sie um. Wenn das ursprüngliche Backup beispielsweise discourse-2020-10-09-133921-v20201007124955.tar.gz war, sollte die resultierende Datei discourse-2020-10-09-133921-v20201007124955.sql.gz heißen. Die Wiederherstellung dieser Datei sollte dann funktionieren.
