이와 비슷한 문제를 겪고 있습니다. Contribute > Bug :
https://meta.discourse.org/t/missing-user-profile-pictures/93844
실종된 아바타를 복구할 방법이 있을까요?
p.s.: 이 가이드를 참고하여 rake avatars:refresh를 실행해 보았지만 아무런 변화가 없었습니다.
이와 비슷한 문제를 겪고 있습니다. Contribute > Bug :
https://meta.discourse.org/t/missing-user-profile-pictures/93844
실종된 아바타를 복구할 방법이 있을까요?
p.s.: 이 가이드를 참고하여 rake avatars:refresh를 실행해 보았지만 아무런 변화가 없었습니다.
이 문제는 바이러스처럼 더 많은 아바타로 번지고 있습니다! 기이한 관찰 결과는 다음과 같습니다:
파이어폭스에서는 일부 아바타가 표시되지만, 크롬에서는 누락되어 있습니다. 이는 파이어폭스에서 아바타가 누락되지 않는다는 뜻은 아닙니다. 파이어폭스에서도 누락된 아바타가 있습니다!
이 버그는 정말로 수정되었습니까?
저도 동일한 문제를 겪었고 현재 조사 중입니다. 제가 조사 중인 사례에서는 외부 저장소와 관련이 있습니다.
@Pad_Pors 이 문제를 여전히 겪고 계신가요? 또한, S3에 업로드를 저장했거나 저장하고 계신가요?
전문가가 조사 중이라는 소식은 반갑습니다 ![]()
네, 여전히 이 문제를 겪고 있으며, 예전에는 업로드된 파일을 S3에 저장했지만 지금은 그렇지 않습니다.
저희도 마찬가지입니다, @angus. 저희에게 S3가 있습니다. 로그나 기타 자료가 필요하시면 알려주세요. 감사합니다
제가 확인 중인 사례에서는, 커맨드 라인 업그레이드와 PostgreSQL 10에서 12로의 수동 업그레이드 이후 누락된 아바타 이미지가 s3의 tombstone 폴더로 이동되었습니다. 정확한 이유는 아직 불분명합니다.
@Jeremie_Leroy @Pad_Pors 본인 사례에서도 동일한 문제가 발생하는지 확인하고 싶으시다면, 제가 s3 tombstone 폴더에서 누락된 아바타를 확인했던 방법은 다음과 같습니다.
마이그레이션 후 깨진 것으로 확인된 아바타 업로드의 sha1(업로드 URL에 포함된 16자 문자열)을 구했습니다. 깨진 아바타 업로드 URL에서 업로드 ID를 가져와서 수행했습니다(파일名の 첫 부분입니다. 예를 들어 6254_2.png의 경우 ID는 6254입니다). 이 ID를 사용하여 최근 데이터베이스 덤프에서 해당 업로드의 sha1을 조회했습니다. 커맨드 라인에 익숙하지 않으시다면, Postico 2 와 같은 PostgreSQL GUI 도구를 사용하여 덤프 데이터를 시각적으로 확인하실 수 있습니다.
AWS CLI를 사용하여 관련 s3 버킷의 tombstone 폴더에서 해당 sha1을 검색했습니다.
aws s3api list-objects --bucket <bucket_name> --query "Contents[?contains(Key, <sha1>)]" --prefix "tombstone"
(<bucket_name>와 <sha1>은 실제 값으로 변경해야 합니다)
정상적으로 작동하면 다음과 같은 결과 목록이 표시됩니다.
{
"Key": "tombstone/original/2X/d/d7b553ff276fca054c7090e859ef5339fd1f936e.jpg",
"LastModified": "2020-05-16T11:45:03+00:00",
"ETag": ## 문자와 숫자의 조합,
"Size": 64580,
"StorageClass": "STANDARD",
"Owner": {
"ID": ## 문자와 숫자의 조합
}
}
참고로, 5월 16일은 제가 업그레이드를 수행한 날짜입니다. 잘못 tombstone 처리된 모든 아바타의 타임스탬프는 그 무렵의 것입니다. 캐싱의 영향으로 인해 이 문제가 프로덕션 환경에서 간헐적으로 나타나며, 증상이 드러나기까지 시간이 걸렸을 것으로 추정합니다.
제 이해 범위 내에서 UploadRecovery(및 관련 rake 태스크)는 게시물 업로드에 특화되어 있으며, tombstone 처리된 아바타를 처리하지 않습니다.
현재 UploadRecovery에 recover_from_s3를 사용하여 아바타 업로드를 복구하는 새로운 메서드를 추가(패치)하는 방안을 검토 중입니다.
s3에서 잘못 tombstone 처리된 아바타를 복구하는 더 쉬운 방법을 알고 계신 분이라면 기꺼이 듣겠습니다.
@tgxworld 아이디어가 있으신가요?
이건 내게 좀 까다로운 문제인데, 우리와 같은 상황에 있는 다른 사람이 있을까요? 그렇다면 업데이트를 진행할 가치가 있을까요? @sam @codinghorror
@angus 님, 확인 경로를 공유해 주셔서 감사합니다. 하지만 저희는 더 이상 AWS나 S3를 사용하지 않습니다. 오히려 제가 착각이 아니라면, AWS에서 마이그레이션한 이후에 문제가 시작되었습니다.
문제가 해결되면 좋겠지만, 현재로서는 그 몇몇 사용자에게 아바타를 다시 업로드하도록 요청하는 것이 훨씬 쉽습니다. 그리고 이 문제가 새로운 사용자에게까지 확산되지 않기를 바랍니다!
관리 중인 사이트에서 동일한 로직의 변형 버전을 사용하여 게시글에 잘못 삭제 처리(tombstoned)된 이미지를 복구하는 방식으로 이 문제를 성공적으로 해결했습니다: discourse/lib/upload_recovery.rb at main · discourse/discourse · GitHub.
@Jeremie_Leroy 위에서 언급한 단계들을 공유한 이유 중 하나는 아바타가 누락되는 원인이 다양할 수 있기 때문입니다. 이 해결책이 여러분에게 적용되는지 알기 위해서는 먼저 아바타가 잘못 삭제 처리되었는지, 즉 여러분 사례에서 문제의 원인이 무엇인지 확인해야 합니다.
Discourse의 기술적인 측면에 익숙하지 않다면 해당 분석을 수행하는 것이 매우 어렵다는 점도 이해하고 있습니다. 제가 사용한 해결책을 플러그인으로 만들어 여러분 사이트에서 직접 시도해 볼 수 있도록 했습니다. 아래 지침을 참고하세요.
@Pad_Pors 단순히 사람들에게 아바타를 다시 업로드하도록 요청하는 것이라면, 이 수정을 시도하지 않고 그렇게 하는 것이 좋습니다.
다음 조건에 해당하는 경우의 누락된 아바타를 위한 수정 방법임을 유의하세요:
이 작업을 수행하기 전에 포럼의 활동량이 적은 시간을 선택하고, 먼저 전체 백업을 수행하세요.
이 플러그인은 UploadRecovery에 recover_avatars를 추가하며, 게시글에서 누락된 업로드를 복구하는 데 사용되는 메인 recover 메서드와 동일한 복구 메서드의 변형 버전을 사용합니다.
이 플러그인은 중복성을 위해 복구된 아바타의 사본을 삭제 처리(tombstone) 폴더에 유지합니다. 이러한 사본은 purge_deleted_uploads_grace_period_days 사이트 설정에 따라 기간이 설정된 purge_deleted_uploads 백그라운드 잡에 의해 제거됩니다.
메서드를 사용하려면 먼저 서버에 ssh로 접속하고, docker 인스턴스에 진입한 후 rails 콘솔을 시작해야 합니다:
./launcher enter app
rails c
해당 메서드가 삭제 처리 폴더에서 복구하려고 시도할 업로드를 확인하려면 먼저 테스트 실행을 수행하세요:
UploadRecovery.new(dry_run: true, stop_on_error: false).recover_avatars
이 명령은 사용자 이름과 s3 파일 링크 목록을 제공합니다. 실제 실행 시 메서드가 삭제 처리 폴더에서 이동하려고 시도할 아바타 파일들입니다:
예시 출력
user1 tombstone/original/2X/b/bc84397936074854226f1c6e9016099b7fc0aca7.jpeg
user2 tombstone/original/2X/b/b8588e7e45804406f2cbe86f2362c2ccf7f13155.jpg
user3 tombstone/original/2X/8/81a4e3b70cdc35e8f61bca87d276d0253152804a.jpeg
이 목록을 여러분의 사이트에서 아바타가 누락된 사용자들과 비교해 보세요.
dry_run을 true로 변경하여 실제 실행을 수행하세요
UploadRecovery.new(dry_run: false, stop_on_error: false).recover_avatars
작업이 완료되면 캐싱 문제를 피하기 위해 새로운 시크릿(비공개) 창에서 라이브 사이트를 확인하세요. 작업을 마친 후에는 서버에 대한 활성 ssh 연결을 반드시 종료하세요. 열린 rails 콘솔에서 실수로 잘못된 명령을 입력하는 것을 원치 않으실 테니요.