「게시물이 새 S3 업로드 URL로 재매핑되지 않음」에 대한 오탐

기여 버그
1

Discourse 인스턴스를 한 서버에서 다른 서버로 마이그레이션하던 중 흥미로운 문제를 마주쳤습니다.

우리는 포럼의 업로드 파일을 S3에 저장하고 있습니다. 몇 년 전에 이 기능을 활성화했기 때문에, 이번 마이그레이션에서 새로 도입한 것이 아닙니다.
다른 문제 몇 가지를 수정한 후, 백업 가져오기를 성공적으로 수행할 수 있었습니다. 하지만 S3 관련 단계에서 다음과 같은 오류가 발생했습니다:

Updating the URLs in the database...
Removing old optimized images...
Flagging all posts containing lightboxes for rebake...
72038 posts were flagged for a rebake
EXCEPTION: 257 posts are not remapped to new S3 upload URL. S3 migration failed for db 'default'.

조사를 좀 더 진행한 결과, 문제를 다음 코드 라인에서 찾아낼 수 있었습니다:

그 후, rails 콘솔로 가서 다음 코드로 쿼리를 재현해 보았습니다:

discourse(prod)> SiteSetting.cdn_path("/uploads/#{@current_db}/original").sub(/https?:/, "")
=> "/uploads//original"
discourse(prod)> RailsMultisite::ConnectionManagement.current_db
=> "default"
discourse(prod)> cdn_path = SiteSetting.cdn_path("/uploads/default/original").sub(/https?:/, "")
=> "/uploads/default/original"
discourse(prod)> Post.where("cooked LIKE '%#{cdn_path}%'")
=> ...

그리고 해당 게시글들을 확인해 보니,它们是 Performance Reports의 일부였습니다(스크린샷은 find-and-replace 스크립트를 실행한 후의 것입니다):

The image shows HTTP GET requests targeting various endpoints on a Keroiod.io educational technology community website. (Captioned by AI)
The image shows HTTP GET requests targeting various endpoints on a Keroiod.io educational technology community website. (Captioned by AI)866×685 36.9 KB

표면적으로, 해당 체크는 cooked 필드에 /uploads/default/original을 포함하는 모든 게시글을 검색하고 있지만, 이것이 반드시 합법적인 자산이 아닐 수도 있습니다. 이 경우 /uploads/default/original은 "일반 텍스트"로 사용되었기 때문에 마이그레이션 작업에서 놓치지 않았습니다.

이것이 의도된 동작인지 확실하지 않습니다?
감사합니다!

Migrate to s3 failed - but only check fails
2

요리된 게시글(cooked posts)에서도 비슷한 문제가 발생했던 것 같습니다.

데이터베이스만 복원하면 해당 검사를 건너뛰게 될지도 모르겠네요.

다음에는 그렇게 시도해 볼 것입니다.

3

해당 게시물의 텍스트를 필터와 일치하지 않도록만 교체해도 실제로 완전히 복원할 수 있었습니다. 제게는 문제가 되지 않았지만, 혹시 같은 문제를 겪는 사람이 있을까 봐 언급합니다. Discourse에서 이 문제를 수정할 가치가 있을 수도 있으니까요.

2개의 좋아요
4

그래. 아마 코드에서 조리된 게시물을 확인하지 않는 게 맞을지도 모르겠어.

1개의 좋아요
5

백업 복구를 시도할 때 저도 비슷한 문제를 겪은 것 같습니다. 백업을 생성할 때 “업로드 포함” 옵션을 비활성화 상태로 설정했었는데요. 데이터베이스만 복구하는 방식에서 제가 놓치고 있는 다른 부분이 있을까요?

저는 discourse를 처음 사용하는 사용자라 우회 방법을 찾아보려 하지만, S3 버킷을 업로드 저장소로 사용하는 사용자에게 백업/복구가 올바르게 작동하지 않는다면 이는 더 높은 우선순위로 처리되어야 할 문제인 것 같습니다.

실패한 복구 시도의 로그 파일 일부입니다.

[2025-06-22 16:02:24] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:81:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:385:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:352:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:69:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:49:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:167:in `restore_uploads'
/var/www/discourse/lib/backup_restore/restorer.rb:71:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:20:in `restore'
/var/www/discourse/script/spawn_backup_restore.rb:33:in `block in <main>'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>'
[2025-06-22 16:02:24] Trying to rollback...
6

제 상황에 대한 업데이트… 저의 경우 S3로 스토리지를 전환했음에도 불구하고 /var/discourse/shared/standalone/uploads 디렉토리에 여전히 파일들이 남아 있었습니다. 해당 업로드 디렉터리 안의 ‘default’ 디렉토리를 삭제한 후 백업을 다시 생성하자, 데이터베이스만 포함된 백업(…sql.gz)이 성공적으로 생성되었습니다.

어떤 이유인지(제 경우에는) 해당 디렉토리에 파일이 존재하면 업로드를 백업에 포함하지 않겠다는 설정을 무시하고, 어쨌든 업로드 파일을 백업에 포함시켜 생성합니다.

제 상황에 대해 더 많은 정보나 설명이 필요하시면 말씀해 주세요. 원 포스터(OP)의 상황과는 약간 다른 것 같습니다.

어쨌든 저는 이 문제를 우회할 수 있었고, 이제 성공적으로 복원할 수 있습니다.