長年にわたり、バックアップの復元時の暗黙的な移行を含め、S3への移行に関して多くの問題を見てきました。
EXCEPTION: 8件の投稿が新しいS3アップロードURLに再マッピングされていません。'default'データベースのS3移行が失敗しました。
多くの例の一部を以下に示します。
- False positives on "posts are not remapped to new S3 upload URL"
- Restore process cancelled at migrating uploads to S3 step
- Restore to New Host
本日、またこれらの問題の1つに遭遇し、金曜日だったので、チェックをコメントアウトするのではなく、深く掘り下げることにしました。
したがって、次のような状況です。
- マルチサイトを使用している
- この例ではデータベース名を
dbnameとする S3_CDN_URLが設定されているCDN_URLは設定されていない
/lib/file_store/to_s3_migration.rb で起こることは次のとおりです。
最初に、プレフィックスが決定されます。First
prefix = @migrate_to_multisite ? "uploads/#{@current_db}/original/" : "original/"
次に、ファイルがS3にアップロードされ、then 再マッピングが行われます。これは基本的に次のとおりで、いくつかのバリエーションがあります。
from = "/uploads/#{@current_db}/original/"
to = "#{SiteSetting.Upload.s3_base_url}/#{prefix}"
したがって、マルチサイトでは次のように再マッピングされます。
/uploads/dbname/original/からhttps://bucket-location-url.com/uploads/dbname/original/へ
そして、finally チェックが実行されます。
cdn_path = SiteSetting.cdn_path("/uploads/#{@current_db}/original").sub(/https?:/, "")
count = Post.where("cooked LIKE '%#{cdn_path}%'").count
if count > 0
error_message = "#{count} posts are not remapped to new S3 upload URL. #{failure_message}"
raise_or_log(error_message, should_raise)
success = false
end
ここで、SiteSetting.cdn_path は lib/global_path.rb から来ており、次のようになります。
def cdn_path(p)
GlobalSetting.cdn_url.blank? ? p : "#{GlobalSetting.cdn_url}#{path(p)}"
end
したがって、S3 CDNは存在するが通常のCDNがない場合、SiteSetting.cdn_path("/uploads/#{@current_db}/original") は単に /uploads/dbname/original になります。
そして、私たちの再マッピングによると、新しいパスは https://bucket-location-url.com/uploads/dbname/original/ です。
これは次のことを意味します。
cdn_pathは新しい宛先パスの部分文字列である- したがって、
Post.where("cooked LIKE '%#{cdn_path}%'").countは常に投稿を見つける - 誤報して処理を中止する
