장애 조치 후 강등된 기본 사이트를 새 보조 사이트로 되돌리거나 원래 기본 사이트를 복원할 수 있습니다. 이 프로세스는 두 단계로 구성됩니다:

1. 이전 기본 사이트를 보조 사이트로 만들기.
2. 보조 사이트를 기본 사이트로 승격.

이전 기본 사이트를 보조 사이트로 구성#

이전 기본 사이트는 현재 기본 사이트와 동기화되지 않으므로, 첫 번째 단계는 이전 기본 사이트를 최신 상태로 만드는 것입니다. 참고로, 이전 기본 사이트를 다시 동기화할 때 리포지토리 및 업로드와 같이 디스크에 저장된 데이터의 삭제는 재생되지 않으므로 디스크 사용량이 증가할 수 있습니다. 대안으로 이를 방지하려면 새 보조 GitLab 인스턴스 설정을 할 수 있습니다.

이전 기본 사이트를 최신 상태로 만들려면:

1. 뒤처진 이전 기본 사이트에 SSH 접속합니다.

2. 존재하는 경우 /etc/gitlab/gitlab-cluster.json을 제거합니다. (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.rb를 다시 단일 진실 소스로 만들기 위해 사이트의 모든 Sidekiq, PostgreSQL, Gitaly, Rails 노드(다중 노드 설정을 사용하는 경우)에서 /etc/gitlab/gitlab-cluster.json을 삭제해야 합니다.

3. 모든 서비스가 실행 중인지 확인합니다:

   sudo gitlab-ctl start
   

   [!note]

   • 기본 사이트를 영구적으로 비활성화한 경우 이제 해당 단계를 취소해야 합니다. Debian/Ubuntu/CentOS7+와 같은 systemd를 사용하는 배포의 경우 sudo systemctl enable gitlab-runsvdir를 실행해야 합니다. CentOS 6과 같은 systemd가 없는 배포의 경우 처음부터 GitLab 인스턴스를 설치하고 설정 지침에 따라 보조 사이트로 설정해야 합니다. 이 경우 다음 단계를 따를 필요가 없습니다.
   • 재해 복구 절차 중에 이 사이트의 DNS 레코드를 변경한 경우 이 절차 중에 이 사이트에 대한 모든 쓰기를 차단해야 할 수 있습니다.

4. Geo 설정. 이 경우 보조 사이트는 이전 기본 사이트를 가리킵니다.

   1. 현재 보조 사이트에서 PgBouncer가 활성화된 경우 (기본 사이트였을 때) /etc/gitlab/gitlab.rb를 편집하고 sudo gitlab-ctl reconfigure를 실행하여 비활성화합니다.

   2. 그런 다음 보조 사이트에서 데이터베이스 복제를 설정할 수 있습니다.

   3. OpenBao에 대한 JWT 대상을 구성합니다. GitLab Secrets Manager를 활성화했고 기본 사이트와 보조 사이트가 동일한 JWT 대상을 공유하지 않는 경우, 재추가된 보조 사이트의 Helm 값에서 jwt_audience를 새 기본 사이트의 OpenBao URL로 설정합니다:

      global:
        openbao:
          enabled: true
          url: https://openbao.old-primary.example.com:8200
          jwt_audience: https://openbao.promoted.example.com:8200
      

원래 기본 사이트를 잃어버린 경우 설정 지침에 따라 새 보조 사이트를 설정합니다.

보조 사이트를 기본 사이트로 승격#

초기 복제가 완료되고 기본 사이트와 보조 사이트가 긴밀하게 동기화된 경우 계획된 장애 조치를 수행할 수 있습니다.

보조 사이트 복원#

두 사이트를 다시 갖추는 것이 목표라면 첫 번째 단계를 반복하여 (이전 기본 사이트를 보조 사이트로 구성) 보조 사이트도 다시 온라인 상태로 만들어야 합니다.

추가 보조 사이트 복원#

두 개 이상의 보조 사이트가 있는 경우 나머지 사이트를 지금 온라인 상태로 만들 수 있습니다. 나머지 각 사이트에 대해 기본 사이트와 복제 프로세스 시작을 수행합니다.

보조 사이트에서 데이터 재전송 건너뛰기#

보조 사이트가 추가될 때 기본 사이트에서 동기화되는 데이터가 포함된 경우 Geo는 데이터 재전송을 방지합니다.

• Git 리포지토리는 누락된 참조만 전송하는 git fetch로 전송됩니다.
• Geo의 컨테이너 레지스트리 동기화 코드는 태그 및 다이제스트의 튜플을 비교하고 누락된 것만 가져옵니다.
• 블롭은 첫 번째 동기화 시 존재하면 건너뜁니다.

사용 사례:

• 계획된 장애 조치를 수행하고 이전 기본 사이트를 재구성 없이 보조 사이트로 연결합니다.
• 여러 보조 Geo 사이트가 있습니다. 계획된 장애 조치를 수행하고 다른 보조 Geo 사이트를 재구성 없이 다시 연결합니다.
• 보조 사이트를 승격 및 강등시켜 장애 조치 테스트를 수행하고 재구성 없이 다시 연결합니다.
• 백업을 복원하고 사이트를 보조 사이트로 연결합니다.
• 동기화 문제를 해결하기 위해 보조 사이트에 수동으로 데이터를 복사합니다.
• 문제를 해결하기 위해 Geo 추적 데이터베이스의 레지스트리 테이블 행을 삭제하거나 잘라냅니다.
• 문제를 해결하기 위해 Geo 추적 데이터베이스를 재설정합니다.

블롭 재전송 건너뛰기#

기존 블롭 데이터가 있는 보조 사이트를 추가하면 보조 Geo 사이트가 해당 데이터의 재전송을 방지합니다. 이는 다음에 적용됩니다:

• CI 작업 아티팩트
• CI 파이프라인 아티팩트
• CI 보안 파일
• LFS 객체
• 머지 리퀘스트 diff
• 패키지 파일
• Pages 배포
• Terraform 상태 버전
• 업로드
• 의존성 프록시 매니페스트
• 의존성 프록시 블롭

보조 사이트의 복사본이 실제로 손상된 경우 백그라운드 검증이 결국 실패하고 블롭이 다시 동기화됩니다.

블롭은 Geo 추적 데이터베이스에 해당 레지스트리 레코드가 없는 경우에만 이런 방식으로 건너뜁니다. 조건이 엄격한 이유는 재동기화가 거의 항상 의도적이며 실수로 전송을 건너뛸 위험을 감수할 수 없기 때문입니다.