Hallo!
Wir migrieren derzeit alle unsere Uploads/Bilder zwischen zwei verschiedenen s3-kompatiblen Diensten (beide sind DigitalOcean Spaces, falls das relevant ist), und ich habe festgestellt, dass wir in einer ziemlich schlechten Situation stecken.
Ich beginne mit einer Erklärung, wie die Migration durchgeführt wurde:
Es könnte erwähnenswert sein, dass ich auch die für den Spaces-Bucket bereitgestellte CDN-URI verwendet habe (mit einem Rebuild).
Ausgabe fehlender Uploads:
rake posts:missing_uploads
Suche nach fehlenden Uploads auf: default
Behebe fehlende Uploads:
🚫
17075 Post-Uploads fehlen.
16906 Uploads fehlen.
1 von 16906 ist ein Upload nach dem alten Schema.
14646 von 139801 Posts sind betroffen.
post_uploads haben 3448 Einträge
optimized_images haben 25681 Einträge
uploads haben 5764 Einträge
Du kannst unter Moving from one S3 bucket to another nachsehen.
Ich denke, ich habe einen Entwurf für eine Anleitung, die ich morgen veröffentlichen werde.
Das wäre sehr hilfreich, vielen Dank!
Hey @Jite!
Sieh nach, ob das für dich funktioniert. Wenn ja, erstelle ich ein ordentliches howto.
Dies geht davon aus, dass Sie ein Tool installieren und konfigurieren können, um Ihre Daten vom alten Bucket auf einen lokalen Rechner zu übertragen und anschließend vom lokalen Rechner in den neuen Bucket zu verschieben. Weitere Informationen finden Sie unter aws cli sync (kann auch für Nicht-AWS-Buckets konfiguriert werden) und gsutil rsync. Wenn Sie sehr große Datenmengen haben oder zwischen Buckets desselben Anbieters wechseln, sollten Sie Methoden untersuchen, die die Daten direkt zwischen den Buckets übertragen.
Wechseln Sie in ein Verzeichnis, das als Zwischenablage geeignet ist (z. B. mkdir temp-bucket; cd temp-bucket), bevor Sie so etwas wie Folgendes ausführen. Diese Beispiele enthalten die Schalter -n und --dry-run, um Ihnen zu zeigen, was passieren wird. Wenn das so aussieht, wie Sie es möchten, führen Sie den Befehl erneut ohne diesen Schalter aus.
gsutil rsync -r -n gs://=OLD= .
or
aws s3 sync s3://=OLD= .
gsutil rsync -r -n . gs://=NEW=
or
aws s3 sync . s3://=NEW=
Sie führen diese Befehle in der Rails-Konsole aus. Um dorthin zu gelangen, führen Sie Folgendes aus:
cd /var/discourse
./launcher enter app
rails c
Für den neuen Bucket laden Sie ein Bild mit der neuen Konfiguration hoch und führen Folgendes aus:
Upload.last.url
Sie sollten etwas Ähnliches sehen:
=> "//discourse-bucket.s3.dualstack.us-east-2.amazonaws.com/`original/2X/7/12345fbea574afc4e02db80107e6682430aede2c.png"
Dann erhalten Sie discourse-bucket.s3.dualstack.us-east-2.amazonaws.com für den neuen Bucket. Den Hostnamen des alten Bucket ermitteln Sie auf ähnliche Weise wie oben.
Verwenden Sie dies, um zu überprüfen, ob Ihre Uploads dort sind, wo Sie sie erwarten:
Upload.order(Arel.sql('RANDOM()')).limit(10).pluck(:id, :url)
Nun aktualisieren Sie die Datenbank, um den neuen Bucket anstelle des alten zu verwenden. DbHelper.remap ersetzt Vorkommen in allen Tabellen.
DbHelper.remap("//=OLDHOST=/","//=NEWHOST=/")
s3_endpoint erfordern.HINWEIS: Wenn Sie in den SiteSettings in der Datenbank einen s3_endpoint definiert haben und zu AWS wechseln (wo kein Endpunkt benötigt wird), müssen Sie diese Site-Einstellung löschen, nachdem Sie den neuen Container mit den aktualisierten Einstellungen erstellt haben (oder nachdem Sie eine Datenbank wiederhergestellt haben, in der diese Einstellung gesetzt ist).
Wenn Sie Beiträge haben, die direkt auf den neuen S3-Bucket verweisen (vielleicht hatten Sie zuvor keine s3_cdn_url definiert), können Sie hier sehen, wie Sie nur die benötigten Beiträge neu bearbeiten.
Holen Sie sich die Beiträge:
posts=Post.where("cooked like '%=NEWHOST=%'")
Sehen Sie, wie viele es sind:
posts.count
Bearbeiten Sie diese Beiträge neu:
posts.each do |p| p.rebake! end
Oder ersetzen Sie einfach den Bucket durch das CDN:
posts.each do |p|
p.cooked.gsub!(/=NEWHOST=/,"=CDN=")
p.save!
end
Vielen Dank für die Antwort.
Im Grunde habe ich das letzte Mal genau das Gleiche gemacht, aber ich habe es erneut versucht. Das Problem ist, dass posts.count 0 zurückgibt. Alle Beiträge enthalten die Datei transparent.png im „cooked post
Hmm. Richtig. Diese geänderte Lösung funktioniert nur, um ein Neuladen zu vermeiden. Wenn ein Neuladen nicht funktioniert, liegt etwas anderes falsch. Vielleicht sind die Assets nicht dort, wo Discourse sie erwartet?
Nun, es ist möglich, aber der ‘Move’ war im Grunde eine 1:1-Verschiebung aller Dateien im Bucket, hehe…
Du kannst also die alte Bucket-URL durch die neue ersetzen, und es funktioniert?
Siehen die Werte in Uploads korrekt aus?
Ich habe etwas Angst, dass das Zurückwechseln zum alten Bucket einen Job auslöst, der alles aufgrund der nun “alten” Daten in den Tombstone verschiebt. Aber ja, die Datenbank scheint auf die richtigen (neuen) Bilder zu verweisen. Es geht im Grunde nur darum, dass die alten Beiträge nicht auf das korrekte Bild verweisen (ich vermute…).
Nachdem ich die Rake-Aufgabe zur Tombstone-Wiederherstellung und anschließend die Rake-Aufgabe zum Beheben fehlender Uploads ausgeführt habe, hat es endlich angefangen, die Bilder zu „reparieren". Es scheint, als würden sie heruntergeladen und erneut hochgeladen werden. Das dauert sehr lange und verbraucht viele Ressourcen, aber zumindest erhalten die Benutzer ihre Bilder zurück!
Danke für die Hilfe @pfaffman 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.