강등된 기본 사이트를 다시 온라인 상태로 만들기

Tier: Premium, Ultimate Offering: Self-managed

Failover 이후, 원래의 설정을 복원하기 위해 추방된 기본 사이트로 다시 실패할 수 있습니다. 이과정은 두 단계로 이뤄집니다:

  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'가 'true'로 정의되었으며 /etc/gitlab/gitlab.rb의 설정을 재정하는 /etc/gitlab/gitlab-cluster.json에 있습니다.

    그렇다면, 이전 기본 사이트의 모든 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를 실행해야합니다. CentOS 6과 같은 systemd가없는 배포에서는 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 또는 파일 재전송 건너뛰기

Self-managed GitLab에서 이 기능은 기본적으로 사용할 수 있습니다. GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다.

부차 Geo 사이트에 사전에 존재하는 파일 데이터가 포함 된 부차 사이트를 추가 할 때 부차 사이트는 해당 데이터를 다시 전송하지 않습니다. 이것은 다음에 적용됩니다:

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

부차 사이트의 사본이 실제로 손상된 경우, 백그라운드 확인이 최종적으로 실패하고 파일이 다시 동기화됩니다.

파일은이 방식으로 건너 뜀 처리됩니다, 만약 Geo 추적 데이터베이스에 해당하는 레지스트리 레코드가없는 경우입니다. 동기화는 거의 항상 의도 적이기 때문에 전송을 잘못 건너 뛰는 것을 위험하게하지 않기 위해 조건이 엄격합니다.