Wir haben unser Discourse-Forum aufgebaut, getestet und absichtlich Lücken gesucht, bevor wir das gesamte Projekt in die Produktion bringen. Ich habe gerade mein Testforum, bei dem S3-Uploads aktiviert waren, von einem Server auf einen anderen migriert. Nach der Wiederherstellung wurden alle URLs für angehängte Inhalte auf die URL des Forums umgeschrieben und nicht auf die S3…
Glücklicherweise handelt es sich um ein Testforum, daher ist uns die Daten nicht allzu wichtig. Dennoch möchte ich:
A. Dies trotzdem beheben.
B. Eine Möglichkeit finden, dies in der Produktion zu verhindern oder abzuschwächen.
Betroffen waren nicht nur Beiträge, sondern alle Bilder, Medien, Inhalte und Avatare (was ziemlich dramatisch ist)…
Bevor Sie die Wiederherstellung durchführen, können Sie S3 auf der Zielseite in Ihrer app.yml konfigurieren (nicht über das Admin-Dashboard). Sobald Sie bestätigt haben, dass dies eingerichtet ist und Sie auf den richtigen Bucket zugreifen können, können Sie mit der Wiederherstellung fortfahren. Die Medien sollten dann korrekt verknüpft sein.
Wir haben das im Wesentlichen so gemacht und sind dadurch in diese Situation geraten.
Ich habe die app.yml genau so, wie sie war, am Zielort kopiert und anschließend vom Original ein Backup erstellt. Das Problem lag bei der Wiederherstellung: Beim Wiederherstellen wurden die URLs umgeschrieben, obwohl sich nichts geändert hatte und die S3-Uploads weiterhin aktiviert waren.
Letztendlich haben wir das Problem mit einer Neuberechnung (Rebake) gelöst – wir sind uns zwar nicht sicher, was genau geholfen hat, da Discourses Caching sehr aggressiv ist und wir zwischen den vielen Versuchen nicht wissen, welche Maßnahme den Ausschlag gab. Dennoch bleiben die Fragen offen: Wie führen wir Migrationen mit minimalen Problemen durch oder stellen sogar aus einem Backup in der Produktion wieder her, falls dies nötig ist?
Das klingt so, als hättest du S3 über die Site-Einstellungen konfiguriert und nicht über Umgebungsvariablen, wie Kris vorgeschlagen hat. Der Wiederherstellungsprozess muss über S3 Bescheid wissen. Das ist mit Site-Einstellungen nicht möglich.
Falls du möchtest, kannst du auch eine Sicherung ohne Uploads über die Konsole erstellen: discourse backup --sql_only
Das Wiederherstellen einer solchen Sicherung überschreibt die Upload-URLs nicht. Solange dein neuer Server Zugriff auf denselben S3-Bucket hat, funktioniert das.
Die S3-Konfiguration befindet sich in der app.yml, nicht in den Site-Einstellungen.
Edit:
Mir ist bewusst, dass ich nicht ausführlich genug erkläre und ich nicht beabsichtige, Details zu verschweigen.
Wir nutzen OVH S3, und dies ist in der app.yml konfiguriert.
Ich habe unser Testforum ohne Uploads gesichert, wobei S3 zu diesem Zeitpunkt noch aktiviert war.
Anschließend habe ich es auf der neuen Site mit exakt derselben app.yml wiederhergestellt, und dort begann das Problem. Um es klarzustellen: Es ist aktuell behoben, aber ich bin unsicher, ob es an meinem mehrfachen Neustarten lag oder daran, dass Discourse aggressiv zwischengespeichert hat. Deshalb muss ich wissen, wie man dies wirklich korrekt durchführt und es beim ersten Mal richtig macht. Meine Sorge ist, dass wir, falls wir jemals eine Sicherung auf unsere Produktionsinstanz wiederherstellen müssen und auf dieses Problem stoßen, genau wissen müssen, wie wir es sofort beheben können, bevor die Benutzer es bemerken.
Wie bereits erwähnt: Wenn Sie auf einem Server wiederherstellen möchten, der denselben S3-Bucket verwendet, stellen Sie sicher, dass S3 in app.yml konfiguriert ist, und erstellen Sie ein Backup ohne Uploads (discourse backup --sql_only). Upload-URLs werden nicht umgeschrieben, wenn das Backup keine Uploads enthält.
Wenn Sie auf einem Server wiederherstellen möchten, der einen anderen S3-Bucket verwendet oder überhaupt keine S3-Konfiguration hat, verwenden Sie ein vollständiges Backup mit Uploads. Die Upload-URLs werden während der Wiederherstellung umgeschrieben.
Sind Sie sich zu 100 % sicher, dass Sie den OVH-S3-Dienst über die Umgebungsvariablen in app.yml auf beiden Servern konfiguriert und ein Backup ohne Uploads (Dateiendung .sql.gz) erstellt haben?
Als ich es zunächst mit den hochgeladenen Dateien wiederhergestellt habe, ist es tatsächlich kaputtgegangen, sodass ich es diesmal komplett löschen und von vorne beginnen musste, wobei ich ein Backup ohne Uploads erstellt habe. Dort hat das Problem begonnen. Die URLs waren weiterhin falsch geschrieben.
Ich bin mir nicht sicher, wie das passieren konnte. Der Wiederherstellungsprozess überspringt den gesamten upload-bezogenen Code (einschließlich der Umstellung von Upload-URLs), wenn du eine .sql.gz-Datei wiederherstellst.
Vielleicht reden wir aneinander vorbei? Ich spreche von der url-Spalte in der uploads-Tabelle, die normalerweise //your-s3-bucket/original/... lautet, im Gegensatz zu /uploads/original bei einer lokalen Installation.
Ein Nachteil bei der Wiederherstellung einer .sql.gz-Datei ist, dass keine URLs umgeschrieben werden. Es wird davon ausgegangen, dass der Server über denselben Hostnamen erreichbar ist wie der Server, auf dem das Backup erstellt wurde. Du musst die URLs neu zuordnen, wenn du die Hostnamen änderst.
Keine Hostnamen wurden geändert. Nur A-Einträge aktualisiert, gesichert und erledigt.
Benutzer-Avatare fehlten (und das lag daran, dass ich den uploads-Ordner nicht migriert habe). S3-Bilder für Anhänge/Medien wurden für die Forum-URL neu geschrieben. Nicht die Bucket-URL.
Ich hatte also erwartet, dass die URLs für S3-Uploads für das Obige als https://some-bucket-name-here.s3.bhs.io.cloud.ovh.net/optimized geschrieben werden, aber es war tatsächlich https://forum.somedomainhere.com/uploads/optimized, was natürlich nicht funktionieren wird.
Ich kann gerne eine weitere VM hochfahren und eine direkte Wiederherstellung durchführen, wenn du möchtest, dass ich alle meine Schritte überprüfe.
Ja, bitte tu das. Und schaue dir die Ausgabe der Wiederherstellung an. Es sollte keine Erwähnung einer URL-Umzuordnung geben, wenn du eine .sql.gz-Datei wiederherstellst.
Ich habe es wiederhergestellt, indem ich einfach aus der in S3 gespeicherten sql.gz-Datei wiederhergestellt habe. Bisher ist nur etwas mit Benutzer-Avataren und einigen Beiträgen schiefgelaufen, aber ich schätze, das lag daran, dass sie bei ihrer Erstellung nicht in S3 hochgeladen wurden.
In einer Produktionsumgebung, vorausgesetzt, alles läuft vom Start an reibungslos und alles befindet sich in S3 … wenn ich aus einem Backup wiederherstelle, habe ich dann nicht dasselbe seltsame Problem wie in der ursprünglichen Beitragsbeschreibung, oder?
