초기 서버에서 가져온 Discourse 백업이 있고, 이를 새 시스템으로 이식하려고 하고 있습니다.
불행히도 두 가지 문제가 있습니다:
복원 과정에서 업로드 1,073개 중 71개가 S3로 마이그레이션되지 않았다고 표시되어 복원 프로세스가 치명적 오류로 중단됩니다.
메인 인스턴스에서 재베이킹(rebaking) 및 게시글 재처리 등을 통해 이를 수정하려고 시도했지만, uploads:migrate_to_s3 rake 메커니즘을 사용하더라도 일부 업로드가 여전히 S3로 마이그레이션되지 않은 것으로 나타납니다.
migrate_to_s3에서 어떤 업로드가 마이그레이션되지 않았는지 확인하기 위해 상세 정보를 얻을 수 있는 어떤 방법이 있을까요? 그러면 수동으로 수정할 수 있을 것 같습니다. 또한, 초기 업로드를 위해 사용했던 죽거나 실패한 S3 저장소를 가리키는 것일 수도 있습니다. 당시 상황이 악화되어 S3 메커니즘을 MinIO로 전환했지만, AWS S3 쪽에 여전히 구형 데이터가 남아 있는 상태였습니다. 이 데이터를 MinIO 인스턴스로 쉽게 마이그레이션할 수 있다고 생각하지는 않습니다.
대안으로, 업로드를 이미 직접 강제 마이그레이션했으므로 복원 메커니즘의 S3 업로드 체크 기능을 비활성화하는 방법이 있을까요?
OK, 결국 DB를 깊이 파고들어서 해결했습니다. 원래는 오래전에 폐기된 S3 환경(사실상 폐기된 것이 아니라, 비용 효율성이 없어 주로 사용하지는 않았지만 사용 가능한 S3 환경)에서 남은 잔재(71개의 업로드)였던 것으로 보입니다.
결국 이렇게 해결했습니다:
원본 서버에서:
./launcher enter app
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%ExpectedS3DomainGoesHere%
(ExpectedS3DomainGoesHere를 S3 설정에 사용하는 실제 URL로 대체하세요)
작업에 필요한 URL을 가져오기 위한 단계입니다. 몇 가지 처리가 필요하기 때문입니다.
URL이 다른 URL의 오래된 버킷에서 온 경우, Amazon S3 클라이언트(또는 S3 스토리지 백엔드 클라이언트)를 사용하여 다음을 수행합니다:
a. 사용 가능한 경우 예상치 못한 URL의 버킷을 로컬 스토리지로 동기화합니다.
b. 로컬에서 새 버킷으로 항목을 동기화합니다.
discourse remap OLD-URL-FROM-DB NEW-URL-FROM-DB 여기에서 DbHelper.remap 사용을 제안했지만, discourse의 remap 기능이 잘 작동했습니다.
데이터가 마이그레이션되었는지 확인합니다. rails uploads:migrate_to_s3
Rebake 시간! rails posts:rebake
‘origin’ 머신/서버에서 사이트를 다시 백업합니다. 최신 업데이트를 다운로드합니다.
새 대상 서버에서:
Discourse를 예상대로 설정하고, 재빌드 시 필요한 플러그인 등이 적절히 적용되도록 원본 서버의 app.yml 등을 새 서버의 /var/discourse/containers/로 복사합니다.
로컬 백업 복사본을 작업하고 있다면 app.yml의 DISCOURSE_BACKUP_LOCATION: s3 항목을 주석 처리하도록 하세요. S3에서 백업 파일이 잘리는 이상 현상이 있어 복원을 위해 로컬 방식을 채택했습니다.