@schleifer ねえ、これ以降のガイダンスをいただけますか？
了解しました。それなら対応可能です。まず、/default/* 内のすべてのファイルを /original/1X/* へ移動させてください。
それは 私たち には分かっていますが、データベースには認識されていません。次のステップで、DB 内のすべてのアップロードのパスを修正します。ただし、他の変更を行う前に、まず整合性を確認しましょう。
データベースコンソールを起動します：
cd /var/discourse
./launcher enter
rails db
次のクエリを実行して確認してください：
select id,url from uploads where id > 0 and url not like '//PREFIX/original/%'
PREFIX には BUCKET + '.s3.dualstack.' + REGION + '.amazonaws.com' を代入する必要があります。例えば //pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/% のようになります。
これで (0 rows) が出力されるはずです。もしそうでない場合は、追加の手順が必要になります。
クエリに対してアップロードされたファイルは7件あり、それらはすべてS3由来ではありません。
つまり、すべてのS3リンクは元ファイルのみを指しているということでしょうか？この7件のアップロードは、2018年10月にアップロード用にS3の運用を開始する以前に行われたものです。
S3リンク（2614件）の内訳は以下の通りです。
2368件が //pesioforum.s3.dualstack.ap-south-1.amazonaws.com を使用
246件が //pesioforum.s3.ap-south-1.amazonaws.com を使用
両方のリンクは動作しますが、今後使用する可能性のある正規表現に影響する可能性があるため、ここに記載しました。
@schleifer どうかこれを完了させてください。
はい、/default/から/original/1Xへファイルを移動して問題ありません。
rake s3:upload_assets を実行することで、それらを S3 へ移行できます。
Dualstack エンドポイントは IPv6 と IPv4 の両方に対応していますが、もう一方は IPv4 のみに対応しています。
データベース内の文字列を書き換えるスクリプトがイメージに含まれています。実行する前に、必ず /admin/backups（ハンバーガーメニュー → Admin → Backups）経由でバックアップを取得してください。
これで 246 件の問題は解決するはずです：
discourse remap '//pesioforum.s3.ap-south-1.amazonaws.com/original/' '//pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/'
/default/ 内のすべてを /original/1X/ へ移動した後、DB 内でそれらのファイルを再マップできます。ただし、その前に /original/2X 内のすべてのファイルが実際に存在することを確認する必要があります。
このクエリは、バケット内のそのパス下の実際のオブジェクトの数と同じ行数を返しますか？
select url from uploads where url like '//pesioforum.s3.dualstack.us-west-2.amazonaws.com/original/2X/%'
@schleifer さん、こんにちは
rake s3:upload_assetsを実行して、それらを S3 に移行できます
これを実行したところ、ウェブサイトのアセット（js、css など）がアップロードされました。ただし、7 つのファイルはアップロードされませんでした。
rake uploads:migrate_to_s3 というタスクを見つけましたが、これが正しいタスクかどうか確認したかったです。
イメージ内には、データベース内の文字列を再マッピングするスクリプトがあります
これはうまく機能し、uploads テーブルには古い非デュアルスタックリンクはもう残っていません。
しかしその前に、
/original/2X内のすべてのファイルが実際に存在することを確認すべきです
残念ながら、そうではありません。S3 バケットには 521 個のファイルがありますが、uploads テーブルには 2186 件のレコードがあります。
/original/2X/ に必要なファイルがないものをいくつかテストしたところ、それらはすべて /default/ に存在していました。
例：uploads テーブルから、
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/original/2X/8/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg は存在しませんが、同じファイルは
https://pesioforum.s3.dualstack.ap-south-1.amazonaws.com/default/806a660beb158e9f06d07ffcd2370b389bbd250b.jpeg にあります
現時点では、ワンタイムのハックとして、/original/2X/{}/ 内のすべてのファイルを /original/1X/ に移動し、投稿などを新しいリンクで更新することに問題ありません。
新しいアップロードはすでに正しく 2X に配置されています。
ああ、はい、それが私が意図していたものです。それによって最後の 7 つがアップロードされるはずです。
確かに、現時点ではそれが最善の選択肢です。/2X/ サブプレフィックスからすべてのファイルをコピーし、すべてを /1X/ に移動してください。
すべての準備が整ったら、以下のコマンドでデータベースエントリをすべて更新できます：
discourse remap --regex "//pesioforum\.doublestack\.s3\.ap-south-1\.amazonaws\.com/original/[1234]X/([0-9a-f]/){0,}" "//pesioforum.doublestack.s3.ap-south-1.amazonaws.com/original/1X/"
（バックアップを取るという以前の警告を忘れないでください。）
その後、一部の投稿はレンチメニューを通じて HTML バージョンの再構築が必要になる場合があります。数が少し多い場合は、rake posts:rebake ですべてを再構築できます。
@schleifer 助かりました！修正した正規表現を使って全投稿を再構築したところ、ほとんどの画像やアップロードが正常に動作するようになりました。
まだ /optimized/ へリンクしている画像（投稿以外のもの）がいくつかありますが、ロゴや異なるテーマの画像などは手動で修正できます。
ご協力いただき、本当にありがとうございました！
こんにちは、私たちの環境でもこれと類似の問題に直面しており、解決のご支援をいただければと願っております。
私たちの問題は、以下の点でこのケースと多くの共通点があります：
s3 upload bucketとs3 backup bucketの両方に同じ値が設定されています。- Discourse のアップグレード時にこの問題が発生しました：
旧バージョン: v2.3.0.beta3
新バージョン: v2.5.0.beta6
- Discourse コンテナに exec してデータベースをクエリしました：
SELECT id,url FROM uploads where id > 0 and url not like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/%';
id | url
----+----------------------------------------------------------------------------------------------------
1 | /uploads/default/original/1X/eb17xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxc33.png
2 | /uploads/default/original/1X/b87fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv21.png
78 | //acme-forum.s3-us-west-2.amazonaws.com/original/1X/1205xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv045.png
(3 rows)
- Discourse コンテナに exec してデータベースをクエリしました：
select url from uploads where url like '//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/%';
//acme-forum.s3.dualstack.us-west-2.amazonaws.com/original/3X/6/2/6267xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxf607c.jpeg
(7953 rows)
./original/3X/内のアイテム数を確認したところ、251個でした。
質問：
dualstackを使用しており、URL をdualstackを使用しないように再マッピングしたくありません。- フォルダ構造が異なり、
3X/X/Y（例：3X/7/a）のような形式になっています。したがって、default内のすべてを3X/*に移動しても、正しくマッピングされない可能性があります。
現在の考え方は、ステップ 4 の出力を参照して、ファイルを ./original/3X/X/Y フォルダに戻す場所を特定するスクリプトを作成することです。
問題は、その作業を行った際、dualstack がまだこのファイルをホストしていなかったことです。つまり、ファイルを original/3X/X/Y に置き換えても、以下の URL で表示できます：
更新：実は dualstack エンドポイントは私が思っていたように壊れておらず、最初に画像ファイルを ./original/3X/6/b にコピーする際に、全員からの読み取り権限を付与するのを忘れていたことが原因でした。
したがって、質問は以下の通りです：
./default 内の画像ファイルを ./original/3X/x/y に戻し、データベースは一切変更しないというアプローチは viable（実現可能）でしょうか？
了解しました、更新情報があります。
./original の画像がどこに配置されるかは予測できそうですが、./optimized/ の画像の修正方法がわかりません。
当フォーラムでは、投稿のいずれかに移動すると、./optimized の画像を表示しようとします。
optimized 画像を特定する方法はありますか？
私の考えでは、optimized 画像は _2_10x10.png で終わるはずですが、これは妥当な仮定でしょうか？もしそうなら、_2_10x10.png のような文字列を含むファイルを optimized フォルダに、含まないファイルを ./original フォルダにコピーするスクリプトを使用することは実現可能な解決策でしょうか？
例:
GET https://acme-forum.s3.dualstack.us-west-2.amazonaws.com/optimized/3X/c/c/ccaxxxxxxxxxxxxxxxxxxxxxxxxxxxx85_2_690x268.png
[HTTP/1.1 403 Forbidden 0ms]
よろしくお願いいたします！
@41821 uploads テーブル内の URL が 正しく動作している 場合でも、投稿がまだ最適化された画像の読み込みを試みている場合は、optimized_images テーブルをクリアしてすべての投稿を再構築すれば解決するはずです：discourse=> delete from optimized_images;
フィードバックをどうもありがとうございます。実は、ファイル名に基づいて画像を /default ディレクトリから /optimized ディレクトリへ移動させるスクリプトを作成することで（そう呼べるかどうかは別として）解決しました。これで問題が解消され、現在は何も困っていません。
もし今後再び同じことが起きた場合は、ご提案いただいたように optimized_images の中身をすべて削除して、再ベイクを行うつもりです。
ありがとうございました！