Auf neuen Host wiederherstellen

Ich habe einen neuen Host eingerichtet, um eine „Staging“-Umgebung zu haben. Ich habe die gleiche Discourse-Installation mit der exakt gleichen Version neu erstellt. Ich verwende Version: 2.8.2.

Erster Kommentar: Ab Version 2.8.2 ist die Größe meines Backups von 282 MB auf etwa 90 MB gesunken. Ich bin mir nicht sicher, warum, aber ich werde das einfach mit einigen intelligenten Informationen nutzen, die ich hinzugefügt habe.

Ich habe das neueste Archiv von meinem Forum heruntergeladen und in den lokalen Speicher der neuen Staging-Umgebung hochgeladen.

Die Wiederherstellung schlägt fehl aufgrund von:

[2022-02-27 19:41:18] ALTER TABLE
[2022-02-27 19:41:18] ALTER TABLE
[2022-02-27 19:41:18] Migrating the database...
[2022-02-27 19:43:00]
[2022-02-27 19:43:00] Reconnecting to the database...
[2022-02-27 19:43:00] Reloading site settings...
[2022-02-27 19:43:00] Disabling outgoing emails for non-staff users...
[2022-02-27 19:43:02] Disabling readonly mode...
[2022-02-27 19:43:02] Clearing category cache...
[2022-02-27 19:43:02] Reloading translations...
[2022-02-27 19:43:02] Remapping uploads...
[2022-02-27 19:43:02] Remapping 'https://forum.geekbeacon.org' to 'https://forum-staging.geekbeacon.org'
[2022-02-27 19:43:08] Restoring uploads, this may take a while...
[2022-02-27 19:43:36] EXCEPTION: 8 posts are not remapped to new S3 upload URL. S3 migration failed for db 'default'.
[2022-02-27 19:43:36] /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:87:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:373:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:66:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:317:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:62:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:44:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:61:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:23:in `restore'
/var/www/discourse/script/spawn_backup_restore.rb:36:in `block in <main>'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>'
[2022-02-27 19:43:36] Trying to rollback...
[2022-02-27 19:43:36] Rolling back...
[2022-02-27 19:43:36] Cleaning stuff up...
[2022-02-27 19:43:36] Dropping functions from the discourse_functions schema...
[2022-02-27 19:43:36] Removing tmp '/var/www/discourse/tmp/restores/default/2022-02-27-194051' directory...
[2022-02-27 19:43:36] Unpausing sidekiq...
[2022-02-27 19:43:36] Marking restore as finished...
[2022-02-27 19:43:36] Notifying 'csgeek' of the end of the restore...

1 „Gefällt mir“

[quote=„Samir_Faci, Beitrag:1, Thema:219515″]
EXCEPTION: 8 posts are not remapped to new S3 upload URL. S3 migration failed
[/quote]

Das ist Ihr Problem. Verwenden Sie vielleicht denselben S3-Bucket und denselben Bucket? Überprüfen Sie vielleicht, ob die versteckte Einstellung, die etwa „S3 im Backup herunterladen“ heißt, aktiviert ist. Sie müssen nach dem Namen der Einstellung suchen oder im Quellcode nachsehen.

Oder vielleicht müssen Sie überprüfen, ob die restlichen Uploads auf Ihrer Produktionsseite auf S3 sind.

1 „Gefällt mir“

Ich habe keine S3 konfiguriert. Ich vermute, dass der alte Server einige alte Daten hat, die nicht auf einen gültigen S3-Speicherort abgebildet wurden.

Ich bin zum älteren Server zurückgekehrt und habe 2 Buckets konfiguriert, 1 für Backups und 1 für Medien. Ich bin dem Leitfaden gefolgt und habe AWS S3 einschließlich des CDN eingerichtet.

Wenn ich rake uploads:migrate_to_s3 ausführe, was fehlschlug, habe ich danach posts:rebake ausgeführt und das scheint die Anzahl der Fehler reduziert zu haben, aber es schlägt immer noch fehl:

Bitte beachten Sie, dass die Migration zu S3 derzeit nicht rückgängig gemacht werden kann!
[CTRL+c] zum Abbrechen, [ENTER] zum Fortfahren

Hochladen von Uploads nach S3 für 'default'...
Dateien nach S3 hochladen...
 - Lokale Dateien auflisten
 => 208 Dateien
 - S3-Dateien auflisten
. => 978 Dateien
 - Dateien nach S3 synchronisieren
................................................................................................................................................................................................................
Aktualisieren der URLs in der Datenbank...
Alte optimierte Bilder entfernen...
Alle Beiträge mit Lightboxen zum erneuten Sichern markieren...
15 Beiträge wurden zum erneuten Sichern markiert
rake abgebrochen!
FileStore::ToS3MigrationError: 1 Beiträge sind nicht auf die neue S3-Upload-URL abgebildet. S3-Migration fehlgeschlagen für DB 'default'.
/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:87:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:373:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:66:in `migrate'
/var/www/discourse/lib/tasks/uploads.rake:123:in `migrate_to_s3'
/var/www/discourse/lib/tasks/uploads.rake:102:in `block in migrate_to_s3_all_sites'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rails_multisite-4.0.0/lib/rails_multisite/connection_management.rb:80:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rails_multisite-4.0.0/lib/rails_multisite/connection_management.rb:90:in `each_connection'
/var/www/discourse/lib/tasks/uploads.rake:100:in `migrate_to_s3_all_sites'
/var/www/discourse/lib/tasks/uploads.rake:96:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => uploads:migrate_to_s3
(Vollständige Trace durch Ausführen der Aufgabe mit --trace anzeigen)

Gibt es eine Möglichkeit, migrate_to_s3 im ausführlichen Modus auszuführen, um den problematischen Beitrag zu identifizieren?

Ich habe das gleiche Problem, migriere meinen Server, ohne den S3-Bucket zu ändern.
Irgendeine Anregung?

Schlägt Ihre Wiederherstellung mit einem Fehler wie diesem fehl?

FileStore::ToS3MigrationError: 1 Beiträge wurden nicht auf die neue S3-Upload-URL umgeordnet. Die S3-Migration für die Datenbank 'default' ist fehlgeschlagen.

In diesem Fall ist es am besten, den Beitrag/die Beiträge zu korrigieren, deren Uploads sich an der falschen Stelle befinden. Ich denke jedoch, dass es einen Fall geben kann, in dem dieser Test ein falsch positives Ergebnis liefert. In diesem Fall können Sie einen Schalter bei der Rake-Aufgabe verwenden, der sie pausiert, damit Sie die Dinge in Ordnung bringen können. Ich kann ihn gerade nicht schnell finden, und er ist auch nicht unter Backup discourse from the command line zu finden, wo er sein sollte. Ich bin gerade mitten in einer Aufgabe und kann ihn jetzt nicht finden.

Ja, ich habe diese Art von Fehler

EXCEPTION: 3 Beiträge werden nicht auf die neue S3-Upload-URL umgeleitet. S3-Migration für Datenbank ‘default’ fehlgeschlagen

Sie können versuchen:

discourse restore --pause dateiname

Das wird die Wiederherstellung pausieren, und Sie können die Datenbank in einem anderen Terminal bearbeiten, um sie zu reparieren. Oder, ich glaube, Sie können es einfach stoppen, bevor es diese Überprüfung durchführt.

Ich muss dies während einer Kommandozeilenwiederherstellung verwenden, glaube ich.

Gleicher Fehler:
Dateien werden nach S3 hochgeladen…

  • Lokale Dateien auflisten
    => 2 Dateien
  • S3-Dateien auflisten
    … => 183549 Dateien
  • Dateien nach S3 synchronisieren
    ..
    Aktualisieren der URLs in der Datenbank…
    Alte optimierte Bilder entfernen…
    Alle Beiträge, die Lightboxen enthalten, zur erneuten Verarbeitung markieren…
    169809 Beiträge wurden zur erneuten Verarbeitung markiert
    FEHLER: 3 Beiträge werden nicht auf die neue S3-Upload-URL umgeschlüsselt. S3-Migration für Datenbank „default“ fehlgeschlagen.
    /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:367: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:179:in restore_uploads’
    /var/www/discourse/lib/backup_restore/restorer.rb:72:in run' script/discourse:243:in restore’
    /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/command.rb:28:in run' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/invocation.rb:127:in invoke_command’
    /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor.rb:538:in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/base.rb:584:in start’
    script/discourse:397:in \u003ctop (required)\u003e' /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:59:in load’
    /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:59:in kernel_load' /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:23:in run’
    /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli.rb:452:in exec' /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/command.rb:28:in run’
    /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in invoke_command' /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor.rb:538:in dispatch’
    /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli.rb:35:in dispatch' /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/base.rb:584:in start’
    /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli.rb:29:in start' /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/exe/bundle:28:in block in \u003ctop (required)\u003e’
    /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/friendly_errors.rb:117:in with_friendly_errors' /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/exe/bundle:20:in \u003ctop (required)\u003e’
    /usr/local/bin/bundle:25:in load' /usr/local/bin/bundle:25:in
    Versuche, zurückzurollen…
    Rolle zurück…
    Bereinige Sachen…
    Funktionen aus dem Schema discourse_functions löschen…
    Temporäres Verzeichnis „/var/www/discourse/tmp/restores/default/2026-01-13-145033“ entfernen…
    Sidekiq entpausieren…
    Wiederherstellung als abgeschlossen markieren…
    „system“ über das Ende der Wiederherstellung benachrichtigen…
    Fertig!

Sie müssen entweder diese drei Uploads korrigieren oder die Wiederherstellung stoppen, bevor diese Prüfung durchgeführt wird.

Wie könnte ich
3 Beiträge auf 168000 finden?

Ist es möglich, die Wiederherstellung zu stoppen und dieses Verifizieren zu überspringen?

Ich würde mir den Code ansehen, der diesen Test durchführt, und dann dieselbe Abfrage ausführen. Ich habe den Code dafür vielleicht schon einmal gepostet.

Ich habe gepostet

Hast du das gemacht? Ich denke, du kannst einfach Strg+C drücken, nachdem die Wiederherstellung abgeschlossen ist. Führst du eine reine Datenbankwiederherstellung durch?

Oh Mist, ich hatte nicht daran gedacht, die Wiederherstellung nach der Datenbank und vor den Uploads zu stoppen.
Ich muss die Uploads nicht von S3 verschieben – kann ich einfach das Frontend und die Datenbank migrieren?

Könntest du mir sagen, welche Option es erlaubt, den rake bei Beiträgen zu stoppen und die problematischen zu identifizieren? Das wäre sehr willkommen.

Irgendwelche Vorschläge? Danke