• 이전 기본 사이트를 보조 사이트로 구성하기
• 보조 사이트를 기본 사이트로 승진시키기
• 보조 사이트를 복원하기
  • 추가적인 보조 사이트 복원
• 보조 사이트에서 데이터 재전송 건너뛰기
  • Blob 또는 파일 재전송 건너뛰기

복귀된 기본 사이트를 온라인으로 다시 실행하기

페일오버 이후에 원래 구성을 복원하기 위해 기본적으로 강등된 기본 사이트로 다시 실패할 수 있습니다. 이 프로세스는 두 단계로 구성됩니다.

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에 설정을 무시합니다.
   

   그렇다면, 이후 Sidekiq, PostgreSQL, Gitaly 및 Rails 노드의 모든 곳에서 /etc/gitlab/gitlab-cluster.json을 다시 /etc/gitlab/gitlab.rb를 단일 진실의 원천으로 만들기 위해 삭제해야 합니다.

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 리포지토리는 누락된 ref만 전송하는 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의 경우, 이 피쳐를 사용할 수 없습니다.

기존 파일 데이터가 있는 보조 사이트를 추가하면, 해당 보조 Geo 사이트는 해당 데이터를 다시 전송하지 않습니다. 이는 다음을 포함합니다:

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

만약 보조 사이트의 복사본이 실제로 손상된 경우, 백그라운드 검증이 최종적으로 실패하고 파일은 다시 동기화됩니다.

이러한 방식으로 파일은 Geo 추적 데이터베이스에 해당 레지스트리 레코드가 없는 경우에만 건너뛰어집니다. 재동기화는 거의 항상 의도적이기 때문에 잘못된 전송을 위험하게 만들 수 없습니다.