Avatare nach der Wiederherstellung verloren. Wie bekomme ich sie zurück?

Guten Morgen @ariznaf,

Bevor du zu diesem Schluss kommst, könntest du bitte zu allen deinen Installationen gehen, in den gemeinsamen Ordner jeder Installation wechseln und für jede Installation folgenden Befehl ausführen? Bitte poste die Ergebnisse anschließend hier.

# du -sh uploads

Zum Beispiel habe ich bei unseren Installationen Folgendes getan:

Ursprüngliche Installation:

# du -sh uploads
2.5G uploads

Nur-Socket-Installation (vor der Behebung des Problems):

# du -sh uploads
444K uploads

Dies gab mir den Hinweis, den ich brauchte, um zu erkennen, dass ich den Ordner uploads manuell kopieren musste; und da das Problem bekannt ist, ist die Lösung einfach.

Wenn du alle deine verschiedenen uploads-Ordner mit du -sh uploads in allen gemeinsamen Verzeichnissen überprüfst, erhältst du einen wertvollen Hinweis darauf, was vor sich geht.

Sind sie unterschiedlich, weißt du, dass einige Uploads fehlen, und du kannst dies manuell korrigieren.

Sind sie alle gleich (unwahrscheinlich), wird das Problem interessanter :slight_smile:

Ich habe das Problem gefunden (nicht die Lösung).
Das Problem liegt nicht am Wiederherstellen selbst, sondern an der Änderung des Servernamens.

Lassen Sie mich erklären, wie ich die Wiederherstellung durchgeführt habe (nur für den Fall, dass ein Schritt fehlt).

Ich habe eine frische Kopie von Discourse von GitHub heruntergeladen.
Ich habe den Docker-Setup-Prozess ausgeführt.
Bevor ich die App ausgeführt und mit der Wiederherstellung fortgefahren bin, habe ich die app.yml bearbeitet, um den Socket-Zugriff zu konfigurieren.
Und ich habe den Hostnamen in b.domain.com geändert (ursprünglich a.domain.com).

Ich habe einen Nginx-Reverse-Proxy mit SSL konfiguriert, um HTTPS-Verkehr auf Port 443 zum Discourse-Socket weiterzuleiten.
Dann habe ich neu aufgebaut (launcher rebuild app) und Nginx neu gestartet (service nginx restart).
Ich habe https://b.domain.com aufgerufen, um die erste Konfiguration von Discourse vorzunehmen.
Ich habe es so konfiguriert, dass es von S3 wiederhergestellt wird, und das letzte Backup von Datenbank und Uploads (ohne Miniaturansichten) wiederhergestellt.
Nach der Wiederherstellung werden Sie ausgeloggt.
Ich habe die app.yml bearbeitet, um die app.yml von der alten Seite zu kopieren (um dieselbe Konfiguration und dieselben Plugins zu erhalten).
Ich habe den Hostnamen in app.yml in b.domain.com geändert.

Wieder ein Neuaufbau und ein Neustart von Nginx.

DAS PROBLEM besteht weiterhin: Die Profilbilder (Miniaturansichten) aller Benutzer, die ihr Profil geändert haben, wurden durch das weiße Standardprofilbild ersetzt.
Auch unser Logo oben links fehlt.

@Stephen force_https war aktiviert (wie auf dem ursprünglichen Server, wo es keine Probleme gab). Ich habe versucht, es zu aktivieren und zu deaktivieren, ohne Erfolg. Ich habe es aktiviert gelassen, da wir möchten, dass unsere Seite über HTTPS aufgerufen wird (ohnehin wird im Nginx-Config der HTTP-Verkehr auf Port 80 dauerhaft auf HTTPS-Port 443 umgeleitet).

@riking Ich habe Sidekiq verwendet und den Job avatarmissing ausgelöst, der innerhalb weniger Millisekunden scheinbar erfolgreich abgeschlossen wurde. Nur für den Fall, dass es ein langer Prozess war, habe ich fast 24 Stunden gewartet, um zu sehen, ob die Profilbilder wiederhergestellt wurden.
Aber heute haben wir dasselbe Problem: Keine Avatarbilder (für Personen, die ein Profilbild hochgeladen haben) und kein Logo.

Danach habe ich versucht zu prüfen, ob das Problem an der Namensänderung lag, wie @Stephen vorgeschlagen hatte.

Ich habe den Hostnamen in app.yml und Nginx wieder auf a.domain.com (den ursprünglichen) geändert und neu aufgebaut sowie Nginx neu gestartet.
Ich habe meine lokale hosts-Datei so angepasst, dass a.domain.com auf die IP-Adresse des neuen Servers zeigt, und einen Ping ausgeführt, um sicherzustellen, dass die Verbindung zur neuen IP hergestellt wurde.

UND WUNDERRBAR: Da sind die Avatare und unser Profil.

Das Problem liegt also nicht am Wiederherstellungsprozess selbst, sondern daran, dass irgendwie die vollständigen URL-Pfade gespeichert werden und versucht wird, von der falschen Stelle darauf zuzugreifen.
Es ist dennoch seltsam, da der ursprüngliche Server noch läuft (er hätte die Bilder auch vom falschen Ort finden müssen – also vom ursprünglichen Server statt vom neuen).

Aber无论如何 das Problem liegt nicht am Wiederherstellungsprozess oder daran, dass die Bilder aufgrund einer Art Korruption erneut hochgeladen werden müssen.

Das Problem ist die Änderung des Servernamens.

Nun ist die Frage: Wie verlegt man ein Discourse-Forum von einer Domain/einem Hostnamen auf einen anderen?

Ich habe versucht, den Hostnamen erneut auf b.domain.com zu ändern.

Leider ohne Erfolg.

Es scheint, als würde bei Verwendung des alten Namens alles funktionieren (aber ich vermute jetzt, dass Bilder und andere Inhalte von dem alten Server bezogen werden, der noch online ist. Ich erhalte neue Beiträge und Benachrichtigungen über neue Beiträge auf dem alten Server, obwohl ich die IP-Adresse für a.domain.com in meiner hosts-Datei geändert habe).

Ich habe die Anweisungen in diesem Beitrag befolgt, um den Hostnamen zu ändern:

Ich dachte, dass es ausreichen würde, wenn Discourse a.domain.com auf b.domain.com umleitet. Auch habe ich rake posts:rebake ausgeführt, aber das Ergebnis bleibt gleich.

Ich habe die Avatare und das Logo verloren, und die in Beiträgen eingefügten Bilder sind ebenfalls verschwunden.

Schließlich habe ich, wie von @neounix vorgeschlagen, alle Uploads erneut entpackt, um das Verzeichnis unter shared/standalone/uploads/ zu ersetzen, aber leider ohne Erfolg. Die Ergebnisse sind dieselben.

Gibt es in deiner Datenbank wirklich wertvolle Informationen? Es könnte einfacher sein, einfach ganz neu anzufangen, ohne sich um Serverwechsel kümmern zu müssen.

Alle Daten und Beiträge seit der Eröffnung des Forums vor einigen Monaten?

Wie ich bereits sagte, habe ich den Server erfolgreich auf einen anderen Server verlegt, indem ich den Server gestoppt, alle Daten auf einen neuen Server kopiert und ihn neu gestartet habe.

Der Support hat mir jedoch mitgeteilt, dass der korrekte Weg darin besteht, ein Standard-Backup zu erstellen und die Datenbank wiederherzustellen.

Ich versuche dies zu tun, stoße dabei jedoch jedes Mal auf Probleme.
Ich benötige zudem einen Testserver, um die Auswirkungen von Plugins, Änderungen oder Upgrades zu testen, bevor ich sie in der Produktion durchführe.

Ich kann es nicht abwarten, bis der Server abstürzt, um zu prüfen, ob ich ihn wiederherstellen kann oder nicht.

Bisher endeten alle Wiederherstellungstests mit Problemen, und das System war nicht funktionsfähig, wobei Bilder oder andere Inhalte verloren gingen.

Im Anschluss an diese Saga:

https://meta.discourse.org/t/postgresql-12-update/151236/193

habe ich die Methode „Backup & Restore auf einer anderen Discourse-Instanz

Sind alle Avatare verschwunden oder nur einige davon? Benutzerdefinierte Avatare sind im Grunde Uploads. Funktionieren andere Uploads wie erwartet?

Gehe zur Rails-Konsole und überprüfe den Datensatz des nicht funktionierenden Avatars in der Datenbank. Haben sie die korrekten Werte für URL, Dateigröße, Breite, Höhe, Erweiterung?

User.find_by_username('Overgrow').user_avatar
User.find_by_username('Overgrow').uploaded_avatar

Sie müssen auch ihre optimierten Versionen enthalten. Du kannst das wie folgt überprüfen:

OptimizedImage.where(upload_id: upload_id).where(version: 2)

Zunächst einmal vielen Dank für deine Hilfe @Overgrow.

Alle Avatare und Emojis (sogar Seitenbilder wie Header usw.) waren zwar „da“, aber unsichtbar. Bei Nicht-Avatar-Inhalten erscheinen sie wie defekt, bei Avataren wird der graue Platzhalter angezeigt. Einige Benutzer konnten einfach einen neuen hochladen, und diese sind dann sichtbar.

Bei meinen ersten Versuchen, den Befehl auszuführen, erhielt ich:

FATAL:  the database system is in recovery mode

Also… das ist der Fall :eyes: (Ich habe viele „Verbindungsabbrüche“, daher vermute ich, dass es etwas mit der Datenbank zu tun hat, oder?)

Aber nachdem ich es schließlich durchgehalten habe:

User.find_by_username(‘Overgrow’).user_avatar

=> #<UserAvatar:0x000055702722d200
 id: 4,
 user_id: 3,
 custom_upload_id: 20504,
 gravatar_upload_id: 12240,
 last_gravatar_download_attempt: Thu, 21 May 2020 10:16:55 UTC +00:00,
 created_at: Sat, 30 May 2019 16:33:16 UTC +00:00,
 updated_at: Thu, 21 May 2020 10:16:55 UTC +00:00>

(Habe heute versucht, einen neuen hochzuladen, aber es funktioniert nicht).

User.find_by_username(‘Overgrow’).uploaded_avatar

=> #<Upload:0x00005555cd911b58
 id: 20504,
 user_id: 3,
 original_filename: "16_2.png.jpg",
 filesize: 56220,
 width: 360,
 height: 360,
 url: "/uploads/default/original/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8.jpeg",
 created_at: Thu, 15 Aug 2019 20:02:47 UTC +00:00,
 updated_at: Thu, 15 Aug 2019 20:02:47 UTC +00:00,
 sha1: "63347a46c0ca945f53613722a73c233484d642c8",
 origin: nil,
 retain_hours: nil,
 extension: "jpeg",
 thumbnail_width: 360,
 thumbnail_height: 360,
 etag: nil,
 secure: false,
 access_control_post_id: nil,
 original_sha1: nil>

OptimizedImage.where(upload_id: 20504).where(version: 2)

=> [#<OptimizedImage:0x000056366a01c1a0
  id: 95962,
  sha1: "5a32b5cc3e6f5c58d88a3c92a23076980a8ce840",
  extension: ".jpeg",
  width: 200,
  height: 200,
  upload_id: 20504,
  url: "/uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_200x200.jpeg",
  filesize: 28916,
  etag: nil,
  version: 2>,
 #<OptimizedImage:0x000056366a0741e8
  id: 95942,
  sha1: "ee353c9e23511b471e1a59c1f71a2ded3e366b1e",
  extension: ".jpeg",
  width: 20,
  height: 20,
  upload_id: 20504,
  url: "/uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_20x20.jpeg",
  filesize: 1270,
  etag: nil,
  version: 2>,
 #<OptimizedImage:0x000056366a074120
  id: 95943,
  sha1: "944fa9fc542a79a5c50394c75022bf84ace297e5",
  extension: ".jpeg",
  width: 30,
  height: 30,
  upload_id: 20504,
  url: "/uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_30x30.jpeg",
  filesize: 1952,
  etag: nil,
  version: 2>,
 #<OptimizedImage:0x000056366a074058
  id: 95944,
  sha1: "983490e58bed58c971ffa44e440b02ce3ea72bba",
  extension: ".jpeg",
  width: 40,
  height: 40,
  upload_id: 20504,
  url: "/uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_40x40.jpeg",
  filesize: 2695,
  etag: nil,
  version: 2>,
 #<OptimizedImage:0x000056366a07bf60

Also offensichtlich sind die Bilder vorhanden, werden aber nicht angezeigt. Nur der graue Standard-Avatar-Platzhalter ist zu sehen.

Auf Ebene der Datenbankdatensätze sieht alles in Ordnung aus. Bei der Untersuchung können Sie sich nun zu höheren Ebenen vorarbeiten.

Was erhalten Sie, wenn Sie die URLs der von Ihnen aufgelisteten Uploads manuell aufrufen?

Wenn ich /uploads/default/optimized/3X/6/3/63347a46c0ca945f53613722a73c233484d642c8_2_200x200.jpeg (also) nach meiner Discourse-URL einfüge, erhalte ich einen 404-Fehler, nicht gefunden.

Also … existieren sie nicht? (Ich frage mit Hoffnung :P)

Prüfen Sie auch einige Date URLs aus /uploads/default/original und nicht nur aus /uploads/default/optimized.

404 … Das bedeutet, dass Sie Ihren uploads-Ordner im Dateisystem unter /var/discourse/shared/standalone überprüfen und herausfinden müssen, wo sich die eigentlichen alten Dateien befinden (falls sie existieren). Wenn Sie sie gefunden haben, versuchen Sie, den Speicherort mit neu hochgeladenen Dateien (denen, die funktionieren) zu vergleichen.

Sie können sie auch manuell aus einem Backup wiederherstellen.

Danke für die Erklärung.

Ich habe es gerade noch einmal überprüft und festgestellt, dass einige der aufgeführten Pfade nicht existieren.

Das Seltsame ist, dass Leute versuchen, neue hochzuladen, und auch diese neuen funktionieren nicht. Wenn du mit den von mir angegebenen Befehlen nachschaust, siehst du einen Pfad, der ebenfalls nicht existiert. Wie “malt” Discourse das ab? Denn eines kann ich kaum nachvollziehen: Dass die Dateien fehlen (obwohl das Backup sie eigentlich übernehmen sollte), ist verständlich, aber dass neue Uploads in Phantom-Pfade landen?

Überprüfen Sie den Ordner tombstone in Ihrem Ordner uploads – befinden sich einige der fehlenden Dateien dort?

Der einzige Ordner, den ich in uploads sehe, ist default… Ist der Ordner tombstone für veraltete Dateien oder so etwas?

Zusätzliche Information: Es stellt sich heraus, dass, wenn ein Benutzer versucht, dasselbe Bild hochzuladen, das er bereits hatte (selbst wenn er den Dateinamen ändert – ich nehme an, basierend auf dem, was ich mit diesen Abfragen sehen kann, hängt das vom Hash ab), das Bild nicht geladen wird und leer erscheint. Sobald Sie speichern, sehen Sie den grauen Platzhalter.

Anscheinend können Sie das Bild erneut hochladen, wenn Sie es irgendwie ändern (selbst wenn Sie es nur in einem anderen Format in Photoshop speichern).

Das ist ein normales Verhalten. Der Hash der Datendatei wird in der Datenbank gespeichert, um doppelte Bilder zu vermeiden.

Was passiert, wenn Sie ein Bild über den Compose-Editor hochladen? Wird der Upload abgeschlossen? Wird es im Vorschaufenster angezeigt?

Wenn ich eine Nachricht schreibe und ein Bild darin einfüge, wird es im Vorschaufenster angezeigt und der Upload wird abgeschlossen – ja, das ist das normale Verhalten.

An welchem genauen Punkt hört das Bild also auf, angezeigt zu werden?

Überprüfe die URL des Bildes, das du siehst, und verfolge sie im Dateisystem nach.

Überprüfe die URLs der Bilder, die nicht funktionieren (über die Entwicklertools im Browser). Was ist der Unterschied?

Vielleicht zeigen sie auf eine andere Domain.

Bei der ersten Nachricht bezog ich mich speziell auf Avatare (über das Benutzerprofil), die zweite betrifft den Editor.

Bei einer normalen Nachricht funktioniert das Ziehen und Ablegen oder das Klicken auf die Schaltfläche „Bild hochladen

@Iceman

Dies ist größtenteils nur zur Information, vielleicht sogar zu viel Information, aber es könnte dir auf kleine Weise helfen, zusätzliche Einblicke in einige der interessanten Dinge zu gewinnen, die wir beim gleichzeitigen Betreiben von drei Containern (zwei Webanwendungen und ein Datencontainer) erleben (und wie sich dies auch auf Benutzer-Avatare auswirkt).

Es ist sehr interessant (und meiner Meinung nach sehr cool), wie der Redis-/Sidekiq-Job-Scheduler funktioniert, wenn sie parallel laufen, aber nur einer „auf der Benutzer-Webseite aktiv“ ist:

Ich hoffe, du findest diese kurze Diskussion mit einem Praxisbeispiel interessant. Sie könnte ein wenig Einblick in den Discourse-Job-Scheduler, die Bildoptimierung und Avatare basierend auf unserer Konfiguration bieten:

Ich bin ein großer Fan davon, wie Discourse Redis/Sidekiq zur Planung von Hintergrundjobs einsetzt; und betrachte dies als eine der wichtigsten Stärken und Vorteile der Discourse-Softwarearchitektur.

Hinweis: Diese Konzepte gelten auch in unterschiedlichen, subtilen Formen für verschiedene Phasen des Backup- und Wiederherstellungsprozesses sowie für andere zeitabhängige Prozesse. Daher ist es ratsam, zu verstehen, wie und warum Sidekiq Jobs im Hintergrund plant.

Danke für die Info, @neounix. Das ist sehr hilfreich, um die „Inneren workings