백업 tar 파일에서 어떤 파일을 수정해야 하는지 안내해 주실 수 있을까요?
아카이브 안에 dump.sql 파일이 들어 있습니다. 이 파일을 수정한 후 수정된 버전을 다시 압축해야 합니다. 저는 다른 문제들도 이 파일을 수정해서 해결했습니다. 로그인 후 크래시를 일으키던 일부 부적절한 커스텀 필드를 제거했습니다.
감사합니다.
지시하신 대로 백업 파일을 다운로드하고 압축을 푼 뒤 해당 파일을 수정해 보겠습니다.
백업을 복원하기 위해 이 모든 작업을 해야 한다는 것은 꽤 무섭습니다.
새로운 릴리스의 버그인 것 같습니다.
하지만 백업과 복구는 재해 복구 계획의 핵심입니다.
이 과정은 최대한 견고해야 하며, 여기에 버그가 있으면 큰 영향을 미칩니다.
1개의 좋아요
결국 백업 파일을 수정하지 않고도 복구를 완료했습니다.
몇 번을 시도해 봤는데, 기묘하게도 한 번은 오류 없이 복구가 성공했습니다.
그 후 discourse에서 로그아웃이 되었는데, launcher에서 앱을 다시 빌드하기 전까지는 정상 작동하지 않았습니다.
하지만 지금은 정상적으로 작동하고 있습니다.
기묘한 문제였네요.
백업에서 포럼을 복원하는 데 여전히 문제가 발생하고 있습니다. 몇 주가 지났는데도 백업 복원 기능이 여전히 작동하지 않는 것 같습니다.
이 문제에 대한 해결책이 있을까요?
제가 볼 때, 업데이트를 하고, 테이블의 포맷팅을 확인하고, 소스와 호스트 간에 모든 것이 일치하는지 확인하고, 여러 번 실패하는 것을 지켜보는 것 사이를 반복하고 있으며, 이는 약간의 데이터베이스 편집 없이 작동할 수도 있고 아닐 수도 있습니다.
저는 3개 사이트 중 2개를 성공적으로 마이그레이션했으며, 정신 건강을 위해 하루에 1시간 미만만 이 작업에 할애하고 있습니다. 앞으로 비슷한 상황에서 이 문제가 어떤 영향을 미칠 수 있는지 고객들과 논의하기 시작했습니다. 어깨 으쓱
저는 단순히 복구를 계속 진행했고, 결국 작동하게 만들었습니다.
에러 메시지는 사용자 프로필 테이블에 존재하지 않는 열(column)에 대해 경고합니다.
하지만 데이터베이스 쪽에서 타임아웃 오류나 비슷한 문제가 발생했거나, postgres 쪽의 버그일 수 있습니다. 해당 열이 없다면, 복구를 계속 시도한다고 해서 자동으로 생성되지 않습니다.
Jaromir는 스크립트를 수정하면 문제가 해결된다고 말합니다.
여기서 discourse 개발자 중 누구도 이 문제에 대해 관심을 보이지 않는 것 같지만, 이는 재난 복구 계획에 영향을 미치기 때문에 매우 이상적이고 불안정한 오류입니다.
아마도 다른 주제들 사이에서 이 토픽이 주목받지 못했을 수 있습니다.
그것이 눈에 안 띄었다는 건 아닙니다. 내일 가장 먼저 살펴볼 일입니다.
또한 백업과 복원 기능을 개선하는 작업도 시작하고 있습니다. 재해가 발생했을 때나 단순히 새 서버로 이전하고 싶을 때, 이런 것 때문에 걱정해야 할 필요가 없어야 하니까요.
11개의 좋아요
좋아요. 감사합니다.
그렇게 들으니 기쁩니다.
감사합니다, Gerhard. 지금 신경 쓰시는지는 모르겠지만, 저도 GCP에서 PG 11을 사용하는 사이트에서 문제를 겪고 있습니다. 이번 가을에 PG12로의 마이그레이션이 진행될 예정이라고 알고 있는데, 그 영향을 받을 수 있으니 해당 부분도 확인해 보시는 것이 좋을 것 같습니다.
S3 백업 버킷을 공유하는 두 인스턴스를 업그레이드했습니다. 한 인스턴스에서 백업을 실행한 후 다른 인스턴스에서 복원을 시도했는데 다음 오류가 발생합니다.
No migration with version number 20191007140446.
PostgreSQL 11과 12는 현재 지원되지 않습니다.
4개의 좋아요
최신 버전의 Discourse(tests-passed)를 Droplet에 설치하고, 백업 복원(업로드 포함, 업로드는 S3 미사용)을 진행했는데 문제가 없이 잘 작동했습니다.
백업 복원 중에도 문제가 발생하고 있다면, 다음 사항을 수행해 주세요:
-
컨테이너를 다시 빌드하세요:
cd /var/discourse git pull ./launcher rebuild app -
웹 인터페이스 또는 명령줄을 통해 백업을 복원하세요:
cd /var/discourse ./launcher enter app discourse enable_restore discourse restore <filename>
아직 문제가 해결되지 않으면, 복원하려는 백업 파일의 버전 번호와 복원 중 확인되는 오류 메시지를 게시해 주세요.
6개의 좋아요
두 사이트 모두 2.4.0.beta6 (8fc0cc9aaa) 버전입니다. 백업 파일(업로드 제외)은 S3에 있습니다.
discourse restore 명령을 실행하면 다음과 같은 결과가 반환됩니다.
Starting restore: wonderful-community-2019-10-10-184822-v20191007140446.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2019-10-10-211121 exists...
Downloading archive to tmp directory...
Unzipping archive, this may take a while...
EXCEPTION: Compression::Strategy::ExtractFailed
/var/www/discourse/lib/compression/gzip.rb:49:in `block in extract_file'
/var/www/discourse/lib/compression/gzip.rb:45:in `open'
/var/www/discourse/lib/compression/gzip.rb:45:in `extract_file'
물론 그렇습니다. 그리고 저는 해당 사이트가 어쨌든 GCP의 직접 데이터베이스 백업으로 만족할 것이라고 생각하지만, Sam이 자신의 개발 사이트에서 PG 11을 실행 중이며 PG11 관련 문제에 대해 알고 싶다는 말을 한 적이 있습니다.
@pfaffman decompressed_file_max_size_mb 사이트 설정(숨겨진 설정입니다)을 증가시켜 주세요. 현재 기본값은 1GB로 설정되어 있습니다.
기본값을 100GB로 올리는 PR을 준비해 두었지만 아직 병합되지 않았습니다:
7개의 좋아요
고맙습니다, @Roman. 그 문제를 해결했습니다.
하지만 지금은 invalid command \N 오류가 여러 개 발생했습니다 (이전 내용을 확인하기 전에 버퍼가 가득 찼습니다). 아마도
ERROR: syntax error at or near "Shiny"
LINE 1: Shiny contest submission 2019-01-07 20:00:05.570573 2019-01-...
^
EXCEPTION: psql failed
/var/www/discourse/lib/backup_restore/restorer.rb:324:in `restore_dump'
/var/www/discourse/lib/backup_restore/restorer.rb:75:in `run'
이 정도면 파악하시기에 충분할 것 같습니다.
네, PG11 때문에 그런 것 같습니다.
2개의 좋아요
pg11 인스턴스라면 동의했을 겁니다! 하지만 이건 표준 2컨테이너 설치 환경입니다.
잠깐! 버전 불일치가 있네요.
root@community:/var/discourse# ./launcher enter data root@staging-data:/# psql --version
psql (PostgreSQL) 10.7 (Ubuntu 10.7-1.pgdg16.04+1)
복원하려는 대상은 10.9입니다! 아마 그게 원인일 것 같습니다. (pg11의 경우에도 비슷한 실패가 발생하지만, 그쪽은 동일한 인스턴스에 복원하려고 시도 중입니다.)
내일 데이터 컨테이너를 업그레이드하고 결과를 알려드리겠습니다. 도움 주셔서 감사합니다.
3개의 좋아요
음, 양쪽 모두 10.10으로 업그레이드했습니다(표준 데이터 템플릿 사용) 하지만 여전히 invalid command 관련 오류가 발생했습니다.
invalid command 오류가 시작되자 복원 스크립트를 강제 종료했습니다. 이후 복원을 다시 시도해 invalid command 메시지 전에 발생하는 첫 번째 오류를 확인하려 했을 때 다음과 같은 결과가 나왔습니다:
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "theme_fields" does not exist
그 후 두 인스턴스 모두에서 rake db:migrate를 실행하고 다시 백업한 뒤 복원을 시도했더니 성공했습니다. 어딘가에서 마이그레이션이 누락된 것이 아닐까요?
(위에서 언급한 설정을 변경한 후–더 이상 필요 없어지기 전까지의 짧은 시간 내에 이 설정이 필요한 분들을 위한 완전한 안내입니다)
./launcher enter app
rails c
SiteSetting.decompressed_file_max_size_mb=1000000
1개의 좋아요
또 다른 하나가 실패했습니다. 이번에는 두 개 모두 2.4.0.beta6 버전입니다(하나는 2c011252f1, 다른 하나는 약간 최신 버전일 수 있습니다).
S3를 통해 복원하고 있습니다. 업로드 포함/미포함 두 가지 방식을 모두 시도해 보았습니다. 둘 다 정상적으로 작동하는 것처럼 보이다가 다음과 같은 방식으로 실패했습니다:
...
COPY 11871
COPY 3689
COPY 0
COPY 36550
COPY 0
COPY 14736
/usr/local/bin/discourse: line 2: 3232 Killed RAILS_ENV=production sudo -H -E -u discourse bundle exec script/discourse "$@"
이 메시지만 받고 있나요?
s3 의존성을 제거하고 백업 파일을 먼저 로컬로 복사해 보면 어떻게 될까요?
@pfaffman 이 주제에서 게시하신 두(또는 세) 가지 복구 문제가 이 주제가 원래 다루고 있던 버그(PG::UndefinedColumn: ERROR 문제)의 발생 사례가 아님을 알아두는 것이 좋을 수 있습니다. 이들은 명확히 다른 문제들이므로, 새 주제를 여는 것을 고려해 보세요.
4개의 좋아요