InfoGrab DocsInfoGrab Docs

Geo에 강등된 사이트 재도입

요약

장애 조치 이후에는 강등된 기본 사이트를 새 보조 사이트로 다시 투입하거나 원래 기본 사이트를 복원할 수 있습니다. 이 사이트의 데이터 일관성이 조금이라도 의심스럽다면 처음부터 새로 구성해야 합니다. 강등된 기본 사이트는 더 이상 Geo와 동기화되지 않는 독립형 GitLab 서버로 간주됩니다.

장애 조치 이후에는 강등된 기본 사이트를 새 보조 사이트로 다시 투입하거나 원래 기본 사이트를 복원할 수 있습니다. 이 과정은 두 단계로 구성됩니다:

  1. 이전 기본 사이트를 보조 사이트로 만듭니다.
  2. 보조 사이트를 기본 사이트로 승격합니다.
Warning

  • 이 사이트의 데이터 일관성이 조금이라도 의심스럽다면 처음부터 새로 구성해야 합니다.

  • 강등된 기본 사이트는 더 이상 Geo와 동기화되지 않는 독립형 GitLab 서버로 간주됩니다.

    새 보조 사이트로 다시 추가하기 전에 이전 기본 사이트로서 남아 있는 구성을 모두 제거해야 합니다.

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

이전 기본 사이트는 현재 기본 사이트와 동기화되어 있지 않으므로, 첫 단계는 이전 기본 사이트를 최신 상태로 만드는 것입니다. 이전 기본 사이트를 다시 동기화할 때 리포지터리와 업로드처럼 디스크에 저장된 데이터의 삭제는 재생되지 않으며, 그 결과 디스크 사용량이 늘어날 수 있습니다. 이를 피하려면 대신 새 보조 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를 다시 단일 진실 공급원(Single Source Of Truth, SSOT)으로 만들려면 (다중 노드 구성인 경우) 해당 사이트의 모든 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. 다시 투입한 보조 사이트에서 Geo 추적 데이터베이스 스키마를 초기화합니다.

      gitlab-ctl replicate-geo-database는 메인 gitlabhq_production 데이터베이스만 복제합니다. Geo 추적 데이터베이스(gitlabhq_geo_production)는 보조 사이트에 로컬로 존재하며 보통 geo_secondary['auto_migrate']를 통해 sudo gitlab-ctl reconfigure가 마이그레이션합니다. auto_migrate가 비활성화되어 있거나 추적 데이터베이스가 외부에 있거나 마지막 reconfigure 실행 시점에 비어 있었다면 Geo Log Cursor가 멈추고 모든 동기화 유형이 0% 에 머무릅니다.

      그런 경우에는 보조 사이트의 Rails 또는 Sidekiq 노드에서 다음을 수행합니다:

      1. 추적 데이터베이스 마이그레이션을 수동으로 실행합니다.

      2. Geo Log Cursor가 새 스키마를 인식하도록 재시작합니다:

        sudo gitlab-ctl restart geo-logcursor

      3. 계속하기 전에 추적 데이터베이스가 올바르게 구성되었는지 확인합니다:

        # Confirm the tracking database has tables
sudo gitlab-geo-psql -d gitlabhq_geo_production -c "\dt"

# Confirm all tracking database migrations are applied
sudo gitlab-rake db:migrate:status:geo | grep -w down

# Run the full Geo check
sudo gitlab-rake gitlab:geo:check

      db:migrate:status:geo 명령은 down 마이그레이션을 반환하지 않아야 하며, gitlab:geo:check는 출력에 GitLab Geo tracking database is correctly configured ... yes를 보고해야 합니다.

    4. OpenBao의 JWT 대상(audience)을 구성합니다. 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 리포지터리는 누락된 ref만 전송하는 git fetch로 전송됩니다.
  • Geo의 컨테이너 레지스트리 동기화 코드는 태그와 다이제스트의 튜플을 비교해 누락된 것만 가져옵니다.
  • Blob은 첫 동기화 시점에 이미 존재하면 건너뜁니다.

활용 사례는 다음과 같습니다:

  • 계획된 장애 조치를 수행한 뒤 이전 기본 사이트를 다시 구축하지 않고 보조 사이트로 붙여 강등합니다.
  • 보조 Geo 사이트가 여러 개 있습니다. 계획된 장애 조치를 수행한 뒤 다른 보조 Geo 사이트를 다시 구축하지 않고 재연결합니다.
  • 보조 사이트를 승격했다가 강등하는 방식으로 장애 조치를 테스트한 뒤 다시 구축하지 않고 재연결합니다.
  • 백업을 복원한 뒤 해당 사이트를 보조 사이트로 붙입니다.
  • 동기화 문제를 우회하려고 데이터를 보조 사이트로 수동 복사합니다.
  • 문제를 우회하려고 Geo 추적 데이터베이스의 레지스트리 테이블 행을 삭제하거나 비웁니다.
  • 문제를 우회하려고 Geo 추적 데이터베이스를 초기화합니다.

Blob 재전송 건너뛰기#

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

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

보조 사이트의 사본이 실제로 손상되었다면 백그라운드 검증이 결국 실패하고 해당 blob은 다시 동기화됩니다.

Blob은 Geo 추적 데이터베이스에 해당 레지스트리 레코드가 없을 때만 이런 방식으로 건너뜁니다. 재동기화는 거의 항상 의도된 동작이고 전송을 잘못 건너뛰는 위험을 감수할 수 없으므로 조건이 엄격합니다.

Geo에 강등된 사이트 재도입

GitLab v19.4
Tier: Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기

요약

장애 조치 이후에는 강등된 기본 사이트를 새 보조 사이트로 다시 투입하거나 원래 기본 사이트를 복원할 수 있습니다. 이 사이트의 데이터 일관성이 조금이라도 의심스럽다면 처음부터 새로 구성해야 합니다. 강등된 기본 사이트는 더 이상 Geo와 동기화되지 않는 독립형 GitLab 서버로 간주됩니다.

장애 조치 이후에는 강등된 기본 사이트를 새 보조 사이트로 다시 투입하거나 원래 기본 사이트를 복원할 수 있습니다. 이 과정은 두 단계로 구성됩니다:

  1. 이전 기본 사이트를 보조 사이트로 만듭니다.
  2. 보조 사이트를 기본 사이트로 승격합니다.
Warning

  • 이 사이트의 데이터 일관성이 조금이라도 의심스럽다면 처음부터 새로 구성해야 합니다.

  • 강등된 기본 사이트는 더 이상 Geo와 동기화되지 않는 독립형 GitLab 서버로 간주됩니다.

    새 보조 사이트로 다시 추가하기 전에 이전 기본 사이트로서 남아 있는 구성을 모두 제거해야 합니다.

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

이전 기본 사이트는 현재 기본 사이트와 동기화되어 있지 않으므로, 첫 단계는 이전 기본 사이트를 최신 상태로 만드는 것입니다. 이전 기본 사이트를 다시 동기화할 때 리포지터리와 업로드처럼 디스크에 저장된 데이터의 삭제는 재생되지 않으며, 그 결과 디스크 사용량이 늘어날 수 있습니다. 이를 피하려면 대신 새 보조 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를 다시 단일 진실 공급원(Single Source Of Truth, SSOT)으로 만들려면 (다중 노드 구성인 경우) 해당 사이트의 모든 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. 다시 투입한 보조 사이트에서 Geo 추적 데이터베이스 스키마를 초기화합니다.

      gitlab-ctl replicate-geo-database는 메인 gitlabhq_production 데이터베이스만 복제합니다. Geo 추적 데이터베이스(gitlabhq_geo_production)는 보조 사이트에 로컬로 존재하며 보통 geo_secondary['auto_migrate']를 통해 sudo gitlab-ctl reconfigure가 마이그레이션합니다. auto_migrate가 비활성화되어 있거나 추적 데이터베이스가 외부에 있거나 마지막 reconfigure 실행 시점에 비어 있었다면 Geo Log Cursor가 멈추고 모든 동기화 유형이 0% 에 머무릅니다.

      그런 경우에는 보조 사이트의 Rails 또는 Sidekiq 노드에서 다음을 수행합니다:

      1. 추적 데이터베이스 마이그레이션을 수동으로 실행합니다.

      2. Geo Log Cursor가 새 스키마를 인식하도록 재시작합니다:

        sudo gitlab-ctl restart geo-logcursor

      3. 계속하기 전에 추적 데이터베이스가 올바르게 구성되었는지 확인합니다:

        # Confirm the tracking database has tables
sudo gitlab-geo-psql -d gitlabhq_geo_production -c "\dt"

# Confirm all tracking database migrations are applied
sudo gitlab-rake db:migrate:status:geo | grep -w down

# Run the full Geo check
sudo gitlab-rake gitlab:geo:check

      db:migrate:status:geo 명령은 down 마이그레이션을 반환하지 않아야 하며, gitlab:geo:check는 출력에 GitLab Geo tracking database is correctly configured ... yes를 보고해야 합니다.

    4. OpenBao의 JWT 대상(audience)을 구성합니다. 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 리포지터리는 누락된 ref만 전송하는 git fetch로 전송됩니다.
  • Geo의 컨테이너 레지스트리 동기화 코드는 태그와 다이제스트의 튜플을 비교해 누락된 것만 가져옵니다.
  • Blob은 첫 동기화 시점에 이미 존재하면 건너뜁니다.

활용 사례는 다음과 같습니다:

  • 계획된 장애 조치를 수행한 뒤 이전 기본 사이트를 다시 구축하지 않고 보조 사이트로 붙여 강등합니다.
  • 보조 Geo 사이트가 여러 개 있습니다. 계획된 장애 조치를 수행한 뒤 다른 보조 Geo 사이트를 다시 구축하지 않고 재연결합니다.
  • 보조 사이트를 승격했다가 강등하는 방식으로 장애 조치를 테스트한 뒤 다시 구축하지 않고 재연결합니다.
  • 백업을 복원한 뒤 해당 사이트를 보조 사이트로 붙입니다.
  • 동기화 문제를 우회하려고 데이터를 보조 사이트로 수동 복사합니다.
  • 문제를 우회하려고 Geo 추적 데이터베이스의 레지스트리 테이블 행을 삭제하거나 비웁니다.
  • 문제를 우회하려고 Geo 추적 데이터베이스를 초기화합니다.

Blob 재전송 건너뛰기#

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

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

보조 사이트의 사본이 실제로 손상되었다면 백그라운드 검증이 결국 실패하고 해당 blob은 다시 동기화됩니다.

Blob은 Geo 추적 데이터베이스에 해당 레지스트리 레코드가 없을 때만 이런 방식으로 건너뜁니다. 재동기화는 거의 항상 의도된 동작이고 전송을 잘못 건너뛰는 위험을 감수할 수 없으므로 조건이 엄격합니다.