복귀된 프라이머리 사이트 다시 온라인으로 전환

Tier: Premium, Ultimate Offering: Self-Managed

페일오버 후 복귀하여 원래의 구성을 복원하려면 이전 프라이머리 사이트를 세컨더리 사이트로 다시 전환할 수 있습니다. 이 과정은 두 단계로 구성됩니다.

  1. 이전 프라이머리 사이트를 세컨더리 사이트로 변경합니다.
  2. 세컨더리 사이트를 프라이머리 사이트로 승격합니다.
caution
이 사이트의 데이터 일관성에 의문이 있다면 처음부터 설정하는 것이 좋습니다.

이전 프라이머리 사이트를 세컨더리 사이트로 구성

이전 프라이머리 사이트가 현재 프라이머리 사이트와 동기화되지 않았으므로, 첫 번째 단계는 이전 프라이머리 사이트를 최신 상태로 업데이트하는 것입니다. 디스크에 저장된 리포지터리 및 업로드와 같은 데이터의 삭제는 이전 프라이머리 사이트를 다시 동기화할 때 다시 재생되지 않아 더 많은 디스크 사용량을 초래할 수 있습니다. 또는 이를 피하기 위해 새로운 세컨더리 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의 설정을 재정의합니다.

    그렇다면 사이트의 모든 Sidekiq, PostgreSQL, Gitaly, 및 Rails 노드에서 /etc/gitlab/gitlab-cluster.json을 삭제해야 합니다. 이렇게 함으로써 /etc/gitlab/gitlab.rb가 다시 진리의 단일 진실 공급원가 되도록 합니다.

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

    sudo gitlab-ctl start
    note
    프라이머리 사이트를 영구적으로 비활성화한 경우 이제 해당 단계를 복구해야 합니다. Debian/Ubuntu/CentOS7+와 같은 systemd를 사용하는 배포의 경우 sudo systemctl enable gitlab-runsvdir를 실행해야 합니다. systemd를 사용하지 않는 CentOS 6과 같은 배포의 경우 GitLab 인스턴스를 처음부터 설치하고 설치 지침에 따라 세컨더리 사이트로 설정해야 합니다. 이 경우, 다음 단계를 수행할 필요가 없습니다.
    note
    재해 복구 절차 동안 이 사이트의 DNS 레코드를 변경했다면, 이 절차 중에 이 사이트로의 모든 쓰기 작업을 차단해야 할 수 있습니다.
  4. Geo 설정을 구성합니다. 이 경우 세컨더리 사이트는 이전의 프라이머리 사이트를 가리킵니다.
    1. 현재의 세컨더리 사이트(이전 프라이머리 사이트로 승격된 경우)에서 PgBouncer가 활성화된 경우 /etc/gitlab/gitlab.rb를 편집하고 sudo gitlab-ctl reconfigure를 실행하여 비활성화합니다.
    2. 이후 세컨더리 사이트에서 데이터베이스 복제를 설정할 수 있습니다.

원래 프라이머리 사이트를 분실한 경우 설치 지침을 따라 새 세컨더리 사이트를 설정합니다.

세컨더리 사이트를 프라이머리 사이트로 승격

초기 복제가 완료되고 프라이머리 사이트와 세컨더리 사이트가 밀접하게 동기화될 때 계획된 페일오버를 수행할 수 있습니다.

세컨더리 사이트 복원

두 사이트를 가지고자 하는 경우, 세컨더리 사이트도 이전 단계를 반복하여 다시 온라인 상태로 가져와야 합니다 (이전 프라이머리 사이트를 세컨더리 사이트로 구성 참조).

세컨더리 사이트에서 데이터 재전송 건너뛰기

세컨더리 사이트가 추가된 경우, 해당 데이터가 기본적으로 동기화될 수 있는 경우 Geo는 데이터 재전송을 피합니다.

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

사용 사례:

  • 계획된 페일오버를 수행하고 이전의 프라이머리 사이트를 다시 빌드하지 않고 세컨더리 사이트로 추가합니다.
  • 여러 세컨더리 Geo 사이트가 있는 경우 계획된 페일오버를 수행하고 다시 빌드하지 않고 다른 세컨더리 Geo 사이트를 다시 추가합니다.
  • 세컨더리 사이트를 승격하고 다시 빌드하지 않고 이를 다시 추가합니다.
  • 백업을 복원하고 해당 사이트를 세컨더리 사이트로 추가합니다.
  • 동기화 문제를 해결하기 위해 매뉴얼으로 데이터를 복사하여 세컨더리 사이트에 추가합니다.
  • Geo 추적 데이터베이스의 레지스트리 테이블 행을 삭제하거나 잘라내어 문제를 해결하기 위해 사용합니다.
  • 문제를 해결하기 위해 Geo 추적 데이터베이스를 재설정합니다.

Blob 또는 파일의 재전송 건너뛰기

  • GitLab 16.8에서 도입되었습니다 플래그 이름: geo_skip_download_if_exists. 기본적으로 비활성화됨.
  • GitLab 16.9에서 일반적으로 사용 가능합니다. 피처 플래그 geo_skip_download_if_exists가 제거되었습니다.

플래그: Self-Managed GitLab의 경우 기본적으로 이 기능을 사용할 수 있습니다. GitLab.com 및 GitLab Dedicated의 경우 이 기능을 사용할 수 없습니다.

기존 파일 데이터가 있는 세컨더리 사이트를 추가하면 해당 파일이 다시 전송되지 않습니다. 이는 다음에 해당됩니다:

  • CI 작업 아티팩트
  • CI 파이프라인 아티팩트
  • CI 보안 파일
  • LFS 오브젝트
  • Merge Request 차이
  • 패키지 파일
  • 페이지 배포
  • 테라폼 상태 버전
  • 업로드
  • 의존성 프록시 매니페스트
  • 의존성 프록시 블롭

세컨더리 사이트의 복사본이 손상된 경우, 백그라운드 검증이 최종적으로 실패하고 파일이 다시 동기화됩니다.

파일은 Geo 추적 데이터베이스에서 해당 레지스트리 레코드가 없는 경우에만 이런 방식으로 건너뛰어집니다. 이러한 조건은 거의 항상 의도된 것으로, 잘못된 전송을 위험에 빠뜨릴 수 없기 때문에 엄격하게 설정됩니다.