강등된 주 사이트를 다시 온라인 상태로 복구하기

Tier: Premium, Ultimate Offering: Self-Managed

장애 조치(failover) 후, 원래 구성을 복원하려면 강등된 주 사이트로 다시 강등할 수 있습니다. 이 프로세스는 두 단계로 이루어져 있습니다.

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

경고: 이 사이트의 데이터 일관성에 의문이 들 경우, 처음부터 설정하는 것이 좋습니다.

이전 주 사이트를 보조 사이트로 설정하기

이전 주 사이트가 현재 주 사이트와 동기화되지 않았기 때문에, 첫 번째 단계는 이전 주 사이트를 최신 상태로 가져오는 것입니다. 디스크에 저장된 데이터(예: 저장소 및 업로드) 삭제는 이전 주 사이트를 다시 동기화할 때 다시 재생되지 않으므로, 디스크 사용량이 증가할 수 있습니다. 대안으로 새로운 보조 GitLab 인스턴스를 설정하여 이를 피할 수도 있습니다.

이전 주 사이트를 최신 상태로 가져오려면:

  1. 동기화가 뒤처진 이전 주 사이트에 SSH로 로그인합니다.

  2. /etc/gitlab/gitlab-cluster.json을 삭제합니다.

    이 사이트를 보조 사이트로 다시 추가할 때 gitlab-ctl geo promote 명령어로 승격된 경우, /etc/gitlab/gitlab-cluster.json 파일이 포함되어 있을 수 있습니다. 예를 들어, gitlab-ctl reconfigure 중에 다음과 같은 출력을 볼 수 있습니다: 

    'geo_primary_role'는 '/etc/gitlab/gitlab-cluster.json'에서 'true'로 정의되어 있어 '/etc/gitlab/gitlab.rb'의 설정을 무효화합니다.

    이 경우, /etc/gitlab/gitlab-cluster.json은 이제 ‘/etc/gitlab/gitlab.rb’가 다시 참조할 수 있도록 사이트의 모든 Sidekiq, PostgreSQL, Gitaly 및 Rails 노드에서 삭제해야 합니다.

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

    sudo gitlab-ctl start

    참고: 주 사이트를 영구적으로 비활성화한 경우, 이제 해당 단계를 되돌려야 합니다. Debian/Ubuntu/CentOS7+와 같이 systemd로 동작하는 배포판의 경우, sudo systemctl enable gitlab-runsvdir를 실행해야 합니다. systemd가 없는 CentOS 6과 같은 배포판의 경우, GitLab 인스턴스를 처음부터 설치하고 설치 지침에 따라 보조 사이트로 설정해야 합니다. 이 경우, 다음 단계를 따를 필요가 없습니다.

    참고: 재해 복구 절차 중에 이 사이트의 DNS 레코드를 변경했다면, 이 절차 중에 해당 사이트로의 모든 쓰기 작업을 차단해야 할 수 있습니다.

  4. Geo 설정을 합니다. 이 경우, 보조 사이트는 이전 주 사이트를 가리킵니다.
    1. 현재 보조 사이트(주 사이트일 때)에서 PgBouncer가 활성화된 경우, /etc/gitlab/gitlab.rb를 편집하고 sudo gitlab-ctl reconfigure를 실행하여 비활성화합니다.
    2. 그런 다음 보조 사이트에 데이터베이스 복제를 설정할 수 있습니다.

원래 주 사이트를 분실한 경우, 설치 지침을 따라 새로운 보조 사이트를 설정해야 합니다.

보조 사이트를 주 사이트로 승격하기

초기 복제가 완료되고 주 사이트와 보조 사이트가 동기화되면, 계획된 장애 조치(플랜드 페이러버)를 수행할 수 있습니다.

보조 사이트 복원하기

더 이상의 목표가 두 개의 사이트를 갖는 것이라면, 처음 단계를 반복하여 보조 사이트를 다시 온라인 상태로 가져와야 합니다. (이전 주 사이트를 보조 사이트로 설정)

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

보조 사이트를 추가할 때, 주 사이트에서 동기화될 데이터가 이미 있는 경우, Geo는 데이터의 재전송을 피합니다.

  • Git 저장소는 누락된 참조만 전송하는 git fetch로 전송됩니다.
  • Geo의 컨테이너 레지스트리 동기화 코드는 태그를 비교하고 누락된 태그만 가져옵니다.
  • Blob/파일은 첫 번째 동기화에서 이미 존재하는 경우 건너뜁니다.

사용 사례:

  • 계획된 장애 조치를 수행하고 이전 주 사이트를 강등시켜 다시 빌드하지 않고 보조 사이트로 첨부합니다.
  • 여러 개의 보조 Geo 사이트가 있는 경우, 계획된 장애 조치를 수행하고 다른 보조 Geo 사이트를 다시 첨부하고 다시 빌드하지 않습니다.
  • 보조 사이트를 승격하고 강등시켜 재첨부하고 다시 빌드하지 않는 장애 조치 테스트를 수행합니다.
  • 백업을 복원하고 사이트를 보조 사이트로 첨부합니다.
  • 동기화 문제를 해결하기 위해 보조 사이트로 수동 데이터를 복사합니다.
  • 문제를 해결하기 위해 Geo 추적 데이터베이스의 레지스트리 테이블 행을 삭제하거나 잘라냅니다.
  • 문제를 해결하기 위해 Geo 추적 데이터베이스를 재설정합니다.

블롭이나 파일의 다시 전송 건너뛰기

플래그: 자체 관리형 GitLab에서는 기본적으로 이 기능을 사용할 수 있습니다. GitLab.com 및 전용 GitLab에서는 이 기능을 사용할 수 없습니다.

기존 파일 데이터가 있는 보조 사이트를 추가하면 해당 보조 Geo 사이트는 해당 데이터를 다시 전송하지 않습니다. 이는 다음에 적용됩니다:

  • CI 작업 아티팩트
  • CI 파이프라인 아티팩트
  • CI 보안 파일
  • LFS 객체
  • 머지 요청 차이
  • 패키지 파일
  • 페이지 배포
  • Terraform 상태 버전
  • 업로드
  • 종속성 프록시 매니페스트
  • 종속성 프록시 블롭

보조 사이트의 사본이 실제로 손상된 경우 배경 검증이 최종적으로 실패하고 파일이 다시 동기화됩니다.

해당 파일에 대응하는 레지스트리 레코드가 Geo 추적 데이터베이스에 없는 경우에만 이와 같은 방식으로 파일을 건너뛰게 됩니다. 이러한 조건은 거의 항상 의도적인 동기화이기 때문에 잘못된 전송 건너뛰기를 위험하게 생각해서는 안 됩니다.