Ich habe Probleme beim Wiederherstellen unserer Staging-Discourse-Instanz. Staging läuft auf v2.4.0.beta1 +36. Haben Sie eine Idee, wo das Problem liegen könnte oder wo ich suchen sollte? Vielen Dank im Voraus!
Unten ist das Ende der Log-Ausgabe:
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] Migration der Datenbank...
[2019-07-16 20:08:16] Erneute Verbindung zur Datenbank...
[2019-07-16 20:08:16] Neuladen der Site-Einstellungen...
[2019-07-16 20:08:16] Deaktivieren ausgehender E-Mails für Nicht-Mitarbeiter...
[2019-07-16 20:08:16] Leeren des Emoji-Caches...
[2019-07-16 20:08:16] Deaktivieren des Nur-Lese-Modus...
[2019-07-16 20:08:16] Leeren des Theme-Caches
[2019-07-16 20:08:22] Extrahieren von Uploads...
[2019-07-16 20:08:40] Migrieren der Uploads zu S3...
[2019-07-16 20:08:46] Wiederherstellungsprozess wurde abgebrochen!
[2019-07-16 20:08:46] Versuch eines Rollbacks...
[2019-07-16 20:08:46] Rollback läuft...
[2019-07-16 20:08:47] Aufräumen...
[2019-07-16 20:08:47] Entfernen des tmp-Verzeichnisses '/var/www/discourse/tmp/restores/default/2019-07-16-200516'...
[2019-07-16 20:08:48] Fortsetzen von Sidekiq...
[2019-07-16 20:08:48] Markieren der Wiederherstellung als abgeschlossen...
Nachfolgend ist die Ausgabe nach der Ausführung von discourse restore BACKUP_FILENAME in der Kommandozeile zu sehen. Jegliches Feedback ist willkommen, vielen Dank!
Ausgehende E-Mails für Nicht-Mitarbeiter werden deaktiviert...
Emoji-Cache wird geleert...
Nur-Lese-Modus wird deaktiviert...
Theme-Cache wird geleert
Hochladungen werden extrahiert...
Uploads werden zu S3 migriert...
Wird geprüft, ob 'default' bereits migriert wurde...
524 von 9474 Hochladungen wurden nicht zu S3 migriert. Die S3-Migration für die Datenbank 'default' ist fehlgeschlagen.
321 Beiträge wurden nicht auf die neue S3-Hochlade-URL umgemappt. Die S3-Migration für die Datenbank 'default' ist fehlgeschlagen.
Suche nach fehlenden Hochladungen in: default
Fehlende Hochladungen werden behoben:
..........................................................................................................
116 Beitragshochladungen fehlen.
116 Hochladungen fehlen.
106 von 116 sind Hochladungen nach dem alten Schema.
98 von 83342 Beiträgen sind betroffen.
rake posts:missing_uploads hat 98 Probleme identifiziert. Die S3-Migration für die Datenbank 'default' ist fehlgeschlagen.
Keine Beiträge müssen neu gerendert werden.
Hochladungen werden für 'default' zu S3 migriert...
Einige Hochladungen wurden nicht auf das neue Schema migriert. Bitte führen Sie diese Befehle in der Rails-Konsole aus:
SiteSetting.migrate_to_new_scheme = true
Jobs::MigrateUploadScheme.new.execute(nil)
Der Wiederherstellungsprozess wurde abgebrochen!
Rückgängigmachen wird versucht...
Rückgängigmachen läuft...
Aufräumen...
Verzeichnis '/var/www/discourse/tmp/restores/default/2019-07-22-172918' wird entfernt...
Sidekiq wird wieder aktiviert...
Wiederherstellung wird als abgeschlossen markiert...
'system' wird über das Ende der Wiederherstellung informiert...
Abgeschlossen!
[FEHLGESCHLAGEN]
Wiederherstellung abgeschlossen.
Nein, es ist noch nicht behoben. Als Workaround könntest du jedoch die Site-Einstellung enable_s3_uploads vor der Erstellung des Backups vorübergehend deaktivieren.
Ich bin mir ziemlich sicher, dass ich gerade ebenfalls davon betroffen bin. Ich denke, dies sollte als Fehler markiert werden.
(Wenn es sich um ein anderes Problem handelt, kannst du es gerne in ein separates neues Thema verschieben.)
Es ist ziemlich wichtig, dass die Wiederherstellung von Backups funktioniert.
Beachte, dass der Grund für das Versagen nicht offensichtlich ist, wenn du die Admin-Oberfläche verwendest und neben dem Backup-Namen auf Wiederherstellen klickst. Du erhältst dann:
...
Migriere Uploads zu S3...
Wiederherstellungsprozess wurde abgebrochen!
...
Die vollständige Wiederherstellung über die Kommandozeile liefert mehr Details:
discourse enter app
discourse restore example-net-2020-01-02-033557-v20191219112000.tar.gz
...
Verbindung zur Datenbank wird wiederhergestellt...
Website-Einstellungen werden neu geladen...
Ausgehende E-Mails für Nicht-Mitarbeiter werden deaktiviert...
Emoji-Cache wird geleert...
Nur-Lese-Modus wird deaktiviert...
Theme-Cache wird geleert
Uploads werden extrahiert...
Uploads werden neu zugeordnet...
Remapping '//forum-example-net.s3.dualstack.eu-west-2.amazonaws.com/' zu '/uploads/default/'
optimized_images=3
uploads=1
Migriere Uploads zu S3...
Prüfe, ob 'default' bereits migriert wurde...
6 von 12 Uploads wurden nicht zu S3 migriert. S3-Migration für DB 'default' fehlgeschlagen.
1 Beitrag wurde nicht auf die neue S3-Upload-URL neu zugeordnet. S3-Migration für DB 'default' fehlgeschlagen.
Suche nach fehlenden Uploads auf: default
0 Beitrags-Uploads fehlen.
Bitte stelle die folgenden Umgebungsvariablen bereit
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
und entweder
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
oder
- DISCOURSE_S3_USE_IAM_PROFILE
Wiederherstellungsprozess wurde abgebrochen!
Rollback wird versucht...
Rollback wird durchgeführt...
Aufräumen...
Funktion aus dem Schema 'discourse_functions' wird entfernt
Verzeichnis '/var/www/discourse/tmp/restores/default/2020-01-06-222212' wird entfernt...
Sidekiq wird fortgesetzt...
Wiederherstellung wird als abgeschlossen markiert...
'System' wird über das Ende der Wiederherstellung informiert...
Fertig!
[FEHLGESCHLAGEN]
Wiederherstellung abgeschlossen.
Ich habe etwas Debug-Code in uploads.rake direkt vor „Bitte stelle die folgenden Umgebungsvariablen bereit
Meines Erachtens lautet die Annahme: Wenn Sie Uploads auf S3 haben, führen Sie ein rein datenbankbasiertes Backup durch, und es wird nicht fehlschlagen, da keine Uploads enthalten sind.
Stimmt, aber das hilft nicht, wenn das Backup, das du hast, die Uploads enthält.
Klarstellung: Das ist für mich gerade nicht kritisch wichtig. Ich kann die problematischen Zeilen auskommentieren und die Wiederherstellung abschließen, aber andere können das nicht.
Es ist nicht nötig, dies in einen bug umzuwandeln. Das Thema liegt in meinem Verantwortungsbereich, und ich habe bereits eine enorme Menge an Zeit damit verbracht, den Wiederherstellungsprozess zu refaktorisieren, zahlreiche Tests hinzuzufügen und ihn zuverlässiger zu machen. Ich werde noch ein paar Anpassungen vornehmen, um die Wahrscheinlichkeit zu verringern, dass die Wiederherstellung nach S3 fehlschlägt, und um im Admin-UI mehr Informationen auszugeben.
Soweit ich weiß, wurde die Sicherung/Wiederherstellung überarbeitet, aber ich habe gerade festgestellt, dass dies immer noch ein Problem darstellt.
Ein Versuch auf beta11, eine Sicherung wiederherzustellen, bei der enable s3 uploads aktiviert war, schlägt immer noch fehl mit:
[2020-02-18 09:51:38] Wiederherstellung von Uploads, dies kann eine Weile dauern...
[2020-02-18 09:51:38] AUSNAHME: Bitte stellen Sie die folgenden Umgebungsvariablen bereit:
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
und entweder
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
oder
- DISCOURSE_S3_USE_IAM_PROFILE
[2020-02-18 09:51:38] /var/www/discourse/lib/file_store/to_s3_migration.rb:34:in `s3_options_from_env'
Die S3-Zugangsdaten sind in der wiederhergestellten Datenbank vorhanden, sodass es nicht erforderlich ist, diese ebenfalls als Umgebungsvariable bereitzustellen.
Die Bereitstellung der Umgebungsvariablen führt ebenfalls zu einem Fehler:
Wiederherstellung von Uploads, dies kann eine Weile dauern...
Prüfen, ob db8015 bereits migriert wurde...
200 von 206 Uploads wurden nicht zu S3 migriert. S3-Migration für db 'db8015' fehlgeschlagen.
5 Beiträge wurden nicht auf die neue S3-Upload-URL umgemappt. S3-Migration für db 'db8015' fehlgeschlagen.
Keine Beiträge erfordern ein Neubacken.
Migration von Uploads zu S3 für 'db8015'...
Hochladen von Dateien zu S3...
- Auflisten lokaler Dateien
=> 21 Dateien
- Auflisten von S3-Dateien
. => 16 Dateien
- Synchronisieren von Dateien mit S3
.....................
Aktualisieren der URLs in der Datenbank...
Entfernen alter optimierter Bilder...
Markieren aller Beiträge mit Lightboxen für ein Neubacken...
5 Beiträge wurden für ein Neubacken markiert
AUSNAHME: 183 von 206 Uploads wurden nicht zu S3 migriert. S3-Migration für db 'db8015' fehlgeschlagen.
/var/www/discourse/lib/file_store/to_s3_migration.rb:127:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:74:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:350:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:61:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:203:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:48:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:30:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:58:in `run'
script/discourse:143:in `restore'
Ich habe keine Ahnung, warum dies fehlschlägt.
Die meisten Uploads waren bereits in S3, daher sind die Angaben „200 von 206 Uploads wurden nicht zu S3 migriert
Das Mischen von lokalen Uploads mit auf S3 gespeicherten Uploads wird nicht unterstützt. Ja, ich weiß, es ist möglich, in einen solchen Zustand zu geraten, wenn jemand von lokalen Uploads auf S3 umstellt und die bestehenden Uploads nicht auf S3 migriert, aber das ist eine andere Geschichte…
Bei der Wiederherstellung eines Backups werden Uploads immer neu gemappt, wenn das System Änderungen erkennt, die die Upload-URLs beeinflussen. Dazu gehören der Wechsel zwischen Standalone- und Multisite-Betrieb, der Wechsel zwischen lokalen Uploads und S3 sowie Änderungen an den S3- und CDN-Einstellungen. Alle Uploads werden basierend auf den Einstellungen am korrekten Ort wiederhergestellt, entweder lokal oder auf S3.
Gelegentlich stoßen wir auf Backups, bei denen die automatische Neuabbildung und Migration zu S3 aus verschiedenen Gründen fehlschlägt. Sie können frühe Verbesserungen im Entwicklungszyklus von Version 2.5 erwarten.