Ich habe also ein Discourse-Backup von unserem ursprünglichen Server und wir versuchen, das System auf ein neues System zu verschieben.
Leider gibt es zwei Probleme:
Während der Wiederherstellung wird angezeigt, dass 71 von 1073 Uploads nicht nach S3 migriert wurden, und schlägt daher während des Wiederherstellungsprozesses fehl.
Wenn ich versuche, dies auf der Hauptinstanz zu beheben, indem ich die Beiträge neu backe usw., wird angezeigt, dass einige Uploads immer noch nicht nach S3 migriert wurden, selbst wenn ich versuche, den uploads:migrate_to_s3 Rake-Mechanismus zu verwenden.
Gibt es irgendeine Möglichkeit, detaillierte Informationen von migrate_to_s3 zu erhalten, welche Uploads nicht migriert wurden, damit ich sie manuell beheben kann? Es ist auch möglich, dass sie sich auf ein totes/fehlgeschlagenes S3-Repository beziehen, von dem wir ursprünglich hochgeladen haben, außer dass die Dinge zu diesem Zeitpunkt explodierten und wir einfach die S3-Mechanismen wechselten (natürlich zu MinIO), und es gab noch alte Dinge, die auf der AWS S3-Seite lagen. Was ich glaube, ich kann nicht einfach auf meine MinIO-Instanz migrieren.
Alternativ dazu gibt es eine Möglichkeit, die S3-Upload-Prüfung des Wiederherstellungsmechanismus zu deaktivieren, da ich die Migration der Uploads bereits selbst erzwungen habe?
OK, ich habe es nach einer eingehenden Untersuchung der DB herausgefunden. Es scheint Reste (71 Uploads) aus der ursprünglichen, längst abgestorbenen S3-Umgebung zu geben (oder besser gesagt, eine verfügbare, aber nicht primär genutzte S3-Umgebung, da sie nicht kosteneffektiv war).
Ich habe Folgendes getan:
Vom Ursprungsserver:
./launcher enter app
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%ExpectedS3DomainGoesHere%'
(ersetzen Sie ExpectedS3DomainGoesHere durch die tatsächliche URL, die Sie für Ihre S3-Konfiguration verwenden)
Dies liefert Ihnen URLs, mit denen Sie arbeiten können, da wir einige Dinge tun müssen.
Wenn die URLs aus älteren Buckets unter anderen URLs stammen, verwenden Sie den Amazon S3-Client (oder den Client für Ihr S3-Speicher-Backend) und:
a. Synchronisieren Sie die unerwarteten Buckets mit den unerwarteten URLs, falls verfügbar, lokal.
b. Synchronisieren Sie die Elemente von Lokal in den neuen Bucket.
Sichern Sie den Standort erneut auf der ‘origin’-Maschine/dem Server. Laden Sie dieses neueste Update herunter.
Vom neuen Zielserver:
Richten Sie Discourse wie erwartet ein, kopieren Sie app.yml und dergleichen vom Ursprungsserver auf den neuen Server unter /var/discourse/containers/, um sicherzustellen, dass der Rebuild die richtigen Plugins usw. trifft, die benötigt werden.
Stellen Sie sicher, dass Sie alle DISCOURSE_BACKUP_LOCATION: s3-Einträge in der app.yml auskommentieren, wenn Sie mit lokalen Backup-Kopien arbeiten. Ich hatte einige Probleme mit S3, das seltsam mit Backup-Dateien umging, die abgeschnitten wurden, daher habe ich den lokalen Ansatz für eine Wiederherstellung gewählt.
Befolgen Sie die Schritte unter Restore a backup from the command line, um das Backup auf Ihren Server zu übertragen und wiederherzustellen. Einschließlich der Rebuild-Schritte.
Das war für mich schmerzhaft zu lösen, aber es wurde gelöst, nachdem ich die Uploads-Tabelle in der DB eingehend untersucht hatte. ABER, das scheint funktioniert zu haben, also…
Was in solchen Situationen oft funktioniert, ist das vorübergehende Deaktivieren von S3-Uploads auf der ursprünglichen Instanz, bevor ein Backup erstellt wird. Nach der Wiederherstellung können Sie S3 wieder aktivieren.