내리고 된 기본 사이트를 온라인으로 복구하기
장애 조치 후, 내리고 된 기본 사이트로 다시 전환하여 원래 구성을 복구할 수 있습니다. 이 과정은 두 단계로 구성됩니다:
- 이전 기본 사이트를 보조 사이트로 전환합니다.
- 보조 사이트를 기본 사이트로 승격합니다.
이전 기본 사이트를 보조 사이트로 구성하기
이전 기본 사이트가 현재 기본 사이트와 동기화되지 않으므로, 첫 번째 단계는 이전 기본 사이트를 최신 상태로 가져오는 것입니다. 디스크에 저장된 데이터, 예를 들어 저장소 및 업로드의 삭제는 이전 기본 사이트를 동기화하는 동안 재재생되지 않으므로 디스크 사용량이 증가할 수 있습니다.
대신, 새로운 보조 GitLab 인스턴스를 설정하여 이를 피할 수 있습니다.
이전 기본 사이트를 최신 상태로 가져오려면:
- 뒤처진 이전 기본 사이트에 SSH로 접속합니다.
-
/etc/gitlab/gitlab-cluster.json이 존재하면 제거합니다.보조 사이트로 재추가될 사이트가
gitlab-ctl geo promote명령으로 승격되었다면,/etc/gitlab/gitlab-cluster.json파일이 포함되어 있을 수 있습니다. 예를 들어gitlab-ctl reconfigure중에 다음과 같은 출력이 나타날 수 있습니다:The 'geo_primary_role' is defined in /etc/gitlab/gitlab-cluster.json as 'true' and overrides the setting in the /etc/gitlab/gitlab.rb이 경우,
/etc/gitlab/gitlab-cluster.json파일은 사이트의 모든 Sidekiq, PostgreSQL, Gitaly, Rails 노드에서 삭제되어야 하며,/etc/gitlab/gitlab.rb이 다시 진실의 단일 출처가 되어야 합니다. -
모든 서비스가 실행 중인지 확인합니다:
sudo gitlab-ctl start이 재해 복구 절차 중에 이 사이트의 DNS 레코드를 변경한 경우, 이 절차 중에 이 사이트로의 모든 쓰기를 차단해야 할 수 있습니다. -
Geo 설정을 합니다. 이 경우, 보조 사이트는 이전 기본 사이트를 나타냅니다.
- 현재 보조 사이트에서 기본 사이트였던 경우에 PgBouncer가 활성화된 경우,
/etc/gitlab/gitlab.rb를 편집하고sudo gitlab-ctl reconfigure를 실행하여 비활성화합니다. - 이후 보조 사이트에서 데이터베이스 복제를 설정할 수 있습니다.
- 현재 보조 사이트에서 기본 사이트였던 경우에 PgBouncer가 활성화된 경우,
원래의 기본 사이트를 잃어버린 경우, 새로운 보조 사이트를 설정하기 위해 설정 지침을 따르세요.
보조 사이트를 주 사이트로 승격
초기 복제가 완료되고 주 사이트와 보조 사이트가 긴밀하게 동기화되면, 계획된 장애 조치를 수행할 수 있습니다.
보조 사이트 복원
두 개의 사이트를 다시 갖는 것이 목표라면, 보조 사이트를 다시 온라인 상태로 만들기 위해 첫 번째 단계인 (이전 주 사이트를 보조 사이트로 구성)를 반복해야 합니다.
추가 보조 사이트 복원
보조 사이트가 하나 이상인 경우, 나머지 사이트를 지금 온라인 상태로 만들 수 있습니다. 나머지 각 사이트에 대해 복제 프로세스를 시작합니다 주 사이트와 함께.
보조 사이트에서 데이터 재전송 건너뛰기
보조 사이트가 추가되면, 해당 사이트에 주에서 동기화될 데이터가 포함되어 있는 경우 Geo는 데이터를 재전송하는 것을 피합니다.
- Git 리포지토리는
git fetch를 통해 전송되며, 이는 누락된 refs만 전송합니다. - Geo의 컨테이너 레지스트리 동기화 코드는 태그를 비교하고 누락된 태그만 끌어옵니다.
- Blob/파일은 첫 번째 동기화에서 존재하는 경우 건너뜁니다.
사용 사례:
- 계획된 장애 조치를 수행하고, 이전 주 사이트를 보조 사이트로 첨부하여 재구성하지 않고 격하합니다.
- 여러 개의 보조 Geo 사이트가 있습니다. 계획된 장애 조치를 수행하고, 다른 보조 Geo 사이트를 재구성하지 않고 다시 연결합니다.
- 보조 사이트를 승격 및 격하하여 장애 조치 테스트를 수행하고 재구성하지 않고 다시 연결합니다.
- 백업을 복원하고 사이트를 보조 사이트로 첨부합니다.
- 동기화 문제를 해결하기 위해 보조 사이트로 데이터를 수동으로 복사합니다.
- 문제를 해결하기 위해 Geo 추적 데이터베이스에서 레지스트리 테이블 행을 삭제하거나 잘라냅니다.
- 문제를 해결하기 위해 Geo 추적 데이터베이스를 재설정합니다.
Blob 또는 파일의 재전송 건너뛰기
- GitLab 16.8에서 도입됨 플래그
geo_skip_download_if_exists라는 이름으로. 기본적으로 비활성화되어 있습니다.- GitLab 16.9에서 일반적으로 사용 가능. 기능 플래그
geo_skip_download_if_exists가 제거되었습니다.
자체 관리 GitLab에서는 기본적으로 이 기능이 제공됩니다.
GitLab.com 및 GitLab Dedicated에서는 이 기능이 제공되지 않습니다.
사전 존재하는 파일 데이터가 있는 보조 사이트를 추가하면, 해당 보조 Geo 사이트는 데이터를 재전송하는 것을 피합니다. 이는 다음에 적용됩니다:
- CI 작업 아티팩트
- CI 파이프라인 아티팩트
- CI 보안 파일
- LFS 객체
- 병합 요청 차이
- 패키지 파일
- 페이지 배포
- Terraform 상태 버전
- 업로드
- 종속성 프록시 매니페스트
- 종속성 프록시 blobs
만약 보조 사이트의 복사본이 실제로 손상되었다면, 백그라운드 검증은 결국 실패하고 파일이 다시 동기화됩니다.
파일은 Geo 추적 데이터베이스에 해당하는 레지스트리 레코드가 없는 경우에만 이 방식으로 건너뛰어집니다. 조건이 엄격한 것은 재동기화가 거의 항상 의도적이며, 전송 건너뛰기를 잘못하는 위험을 감수할 수 없기 때문입니다.
도움말