Falschmeldungen bei „Beiträge werden nicht auf neue S3-Upload-URL umgeleitet“

Fehler
1

Ich habe unsere Discourse-Instanz von einem Server auf einen anderen migriert und dabei auf ein interessantes Problem gestoßen…

Wir verwenden S3, um Uploads vom Forum zu speichern. Wir haben dies vor mehreren Jahren aktiviert, daher ist es nichts, was wir bei dieser Migration eingeführt haben.
Nachdem ich ein paar andere Probleme behoben hatte, konnte ich das Backup importieren. Es schlug jedoch bei einem S3-bezogenen Schritt mit folgendem Ergebnis fehl:

Updating the URLs in the database...
Removing old optimized images...
Flagging all posts containing lightboxes for rebake...
72038 posts were flagged for a rebake
EXCEPTION: 257 posts are not remapped to new S3 upload URL. S3 migration failed for db 'default'.

Nach einigem Nachforschen konnte ich das Problem auf diese Zeile zurückführen:

Dann ging ich zur Rails-Konsole und konnte die Abfragen mit folgendem replizieren:

discourse(prod)> SiteSetting.cdn_path("/uploads/#{@current_db}/original").sub(/https?:/, "")
=> "/uploads//original"
discourse(prod)> RailsMultisite::ConnectionManagement.current_db
=> "default"
discourse(prod)> cdn_path = SiteSetting.cdn_path("/uploads/default/original").sub(/https?:/, "")
=> "/uploads/default/original"
discourse(prod)> Post.where("cooked LIKE '%#{cdn_path}%'")
=> ...

Dann ging ich zu diesen bestimmten Beiträgen, und sie waren Teil der Performance Reports (Screenshot ist von, nachdem ich ein Suchen-und-Ersetzen-Skript ausgeführt habe):

Das Bild zeigt HTTP GET-Anfragen, die auf verschiedene Endpunkte einer Keroiod.io-Plattform für Bildungstechnologie abzielen. (Beschriftet von KI)
Das Bild zeigt HTTP GET-Anfragen, die auf verschiedene Endpunkte einer Keroiod.io-Plattform für Bildungstechnologie abzielen. (Beschriftet von KI)866×685 36.9 KB

Anscheinend ruft diese Prüfung jeden Beitrag ab, der /uploads/default/original im “cooked”-Feld enthält, obwohl es sich möglicherweise nicht um ein legitimes Asset handelt. In diesem Fall wurde /uploads/default/original als “einfacher Text” verwendet, daher wurde es während des Migrationsjobs nicht übersehen.

Ich bin mir nicht sicher, ob dies erwartet wird?
Vielen Dank!

2

Ich habe ähnliche Probleme mit “cooked posts” gesehen, glaube ich.

Vielleicht kannst du eine reine Datenbankwiederherstellung durchführen, und dann überspringt es diese Prüfungen.

Das würde ich als Nächstes versuchen.

3

Ich konnte es tatsächlich vollständig wiederherstellen, indem ich einfach den Text in diesen Beiträgen so geändert habe, dass er nicht mit dem Filter übereinstimmt. Es war kein Problem für mich, aber ich erwähne es nur, falls jemand mit dem gleichen Problem konfrontiert ist, da es sich vielleicht lohnt, es in Discourse zu beheben.

2 „Gefällt mir“
4

Ja. Vielleicht sollte der Code einfach keine bearbeiteten Beiträge prüfen.

1 „Gefällt mir“
5

Ich bin ziemlich sicher, dass ich das auch erlebt habe, als ich versucht habe, ein Backup wiederherzustellen, und ich habe das Backup mit “Uploads einschließen” auf DEAKTIVIERT erstellt. Fehlt mir etwas bei der reinen Datenbankwiederherstellung?

Ich bin neu bei Discourse, werde also versuchen herauszufinden, wie ich es umgehen kann, aber dies scheint eine höhere Priorität zu haben, wenn das Backup/die Wiederherstellung für Benutzer, die S3-Buckets als Upload-Speicher verwenden, nicht korrekt funktioniert.

Hier sind meine Log-Dateien des Wiederherstellungsversuchs.

[2025-06-22 16:02:24] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:81:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:385:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:352:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:69:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:49:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:167:in `restore_uploads'
/var/www/discourse/lib/backup_restore/restorer.rb:71:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:20:in `restore'
/var/www/discourse/script/spawn_backup_restore.rb:33:in `block in 
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `
[2025-06-22 16:02:24] Versuche zurückzurollen...
6

Update zu meiner spezifischen Situation… Ich hatte immer noch Dateien in meinem /var/discourse/shared/standalone/uploads, obwohl ich auf S3 für den Speicher umgestellt hatte. Sobald ich das Verzeichnis ‘default’ in diesem Uploads-Verzeichnis gelöscht und einen neuen Backup erstellt hatte, wurde erfolgreich ein nur-Datenbank-Backup (…sql.gz) erstellt. Aus irgendeinem Grund (in meinem Fall) ignoriert es die Einstellung, Uploads NICHT in das Backup einzuschließen, wenn sich Dateien in diesem Verzeichnis befinden, und erstellt sie trotzdem. Lassen Sie mich wissen, wenn weitere Informationen oder Klärungen zu meiner Situation benötigt werden. Es scheint, als ob es sich leicht von der Situation des OP unterscheidet. Auf jeden Fall konnte ich das Problem umgehen und jetzt erfolgreich wiederherstellen.