재해 복구(Geo) 승격 런북

요약

이 런북은 실험입니다. 이 런북은 하나의 보조 사이트가 있는 다중 노드 Geo 사이트의 계획된 장애 조치를 안내합니다. 이제 새 기본 사이트가 된 승격된 보조 사이트. 이러한 단계를 따르기 전에 Geo 복제본을 승격하고 장애 조치를 수행하는 자동화된 방법이 제공되지 않으므로 승격하려면 보조에 대한 root 액세스 권한이 있는지 확인하세요.

재해 복구(Geo) 승격 런북.

Warning

이 런북은 실험입니다. 완전하고 프로덕션 준비된 문서는 재해 복구 문서를 참조하세요.

다중 노드 구성을 위한 Geo 계획된 장애 조치#

구성 요소	구성
PostgreSQL	Linux 패키지로 관리
Geo 사이트	다중 노드
보조 사이트	하나

이 런북은 하나의 보조 사이트가 있는 다중 노드 Geo 사이트의 계획된 장애 조치를 안내합니다. 다음 40 RPS / 2,000 사용자 참조 아키텍처를 가정합니다:

기본 사이트(다중 노드):

Rails 노드 1
Rails 노드 2
PostgreSQL 노드
Gitaly 노드
Redis 노드
모니터링 노드

보조 사이트:

Rails 노드 1
Rails 노드 2
PostgreSQL 노드
Gitaly 노드
Redis 노드
모니터링 노드

이 가이드의 결과:

오프라인 기본 사이트.
이제 새 기본 사이트가 된 승격된 보조 사이트.

다루지 않는 사항:

이전 기본을 보조로 다시 추가.
새 보조 추가.

준비#

Note

이러한 단계를 따르기 전에 Geo 복제본을 승격하고 장애 조치를 수행하는 자동화된 방법이 제공되지 않으므로 승격하려면 보조에 대한 root 액세스 권한이 있는지 확인하세요.

보조 사이트에서:

오른쪽 상단 모서리에서 Admin을 선택합니다.
왼쪽 사이드바에서 Geo > Sites를 선택하여 상태를 확인합니다. 복제된 객체(녹색으로 표시)는 100%에 가까워야 하며 실패(빨간색으로 표시)가 없어야 합니다. 많은 비율의 객체가 복제되지 않은 경우(회색으로 표시), 사이트에 더 많은 시간을 주는 것을 고려하세요.

[

](/19.2/administration/geo/disaster_recovery/img/geo_dashboard_v14_0.png)

복제에 실패하는 객체가 있는 경우, 유지 보수 기간을 예약하기 전에 이를 조사해야 합니다. 계획된 장애 조치 후 복제에 실패한 항목은 손실됩니다.

복제 실패의 일반적인 원인은 기본 사이트에서 누락된 데이터입니다. 백업에서 데이터를 복원하거나 누락된 데이터에 대한 참조를 제거하여 이러한 실패를 해결할 수 있습니다.

유지 보수 기간은 Geo 복제 및 검증이 완전히 완료될 때까지 종료되지 않습니다. 기간을 최대한 짧게 유지하려면 활성 사용 중에 이러한 프로세스를 가능한 100%에 가깝게 유지해야 합니다.

보조 사이트가 여전히 기본 사이트에서 데이터를 복제하고 있는 경우, 불필요한 데이터 손실을 방지하기 위해 다음 단계를 따르세요:

기본 사이트에서 유지 보수 모드를 활성화하고 백그라운드 작업을 반드시 중지합니다.
모든 데이터 복제 및 검증 완료:

[!warning] 모든 데이터가 자동으로 복제되지는 않습니다. 제외되는 항목에 대해 자세히 읽어보세요.

Geo에서 관리하지 않는 데이터를 수동으로 복제하는 경우, 지금 최종 복제 프로세스를 트리거합니다.
기본 사이트에서:

오른쪽 상단 모서리에서 Admin을 선택합니다.
- 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
- Sidekiq 대시보드에서 Queues를 선택하고 이름에 geo가 있는 것을 제외한 모든 큐가 0으로 떨어질 때까지 기다립니다. 이러한 큐에는 사용자가 제출한 작업이 포함되어 있으며, 완료되기 전에 장애 조치를 수행하면 작업이 손실됩니다.
- 왼쪽 사이드바에서 Geo > Sites를 선택하고 장애 조치할 보조 사이트의 다음 조건이 충족될 때까지 기다립니다:
  
  모든 복제 미터가 100% 복제됨, 0% 실패에 도달합니다.
  - 모든 검증 미터가 100% 검증됨, 0% 실패에 도달합니다.
  - 데이터베이스 복제 지연이 0ms입니다.
  - Geo 로그 커서가 최신 상태입니다(0 이벤트 뒤처짐).
- 보조 사이트에서:
  
  오른쪽 상단 모서리에서 Admin을 선택합니다.
  - 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
  - Sidekiq 대시보드에서 Queues를 선택하고 모든 geo 큐가 0 대기 및 0 실행 중인 작업으로 떨어질 때까지 기다립니다.
  - 무결성 검사 실행으로 파일 스토리지의 CI 아티팩트, LFS 객체, 업로드의 무결성을 확인합니다.

이 시점에서 보조 사이트는 기본 사이트의 모든 것의 최신 복사본을 포함합니다. 이는 장애 조치 시 아무것도 손실되지 않음을 의미합니다.

이 최종 단계에서는 기본 사이트를 영구적으로 비활성화해야 합니다.

[!warning] 기본 사이트가 오프라인 상태가 되면 보조 사이트에 복제되지 않은 기본 사이트에 저장된 데이터가 있을 수 있습니다. 진행하면 이 데이터는 손실된 것으로 처리되어야 합니다.

기본 도메인 DNS 레코드를 업데이트할 계획이라면 전파 속도를 높이기 위해 지금 TTL을 낮추는 것이 좋습니다.

장애 조치를 수행할 때 두 개의 서로 다른 GitLab 인스턴스에서 쓰기가 발생할 수 있는 분리 뇌(split-brain) 상황을 피하려고 합니다. 따라서 장애 조치를 준비하기 위해 기본 사이트를 비활성화해야 합니다:

기본 사이트에 SSH 액세스가 있는 경우 GitLab을 중지하고 비활성화합니다:

sudo gitlab-ctl stop

서버가 예기치 않게 재부팅되는 경우 GitLab이 다시 시작되는 것을 방지합니다:

sudo systemctl disable gitlab-runsvdir

[!note]

CentOS 6 이하에서는 기계가 재부팅될 경우 GitLab이 시작되는 것을 방지하는 것이 어렵습니다(이슈 3058 참조). sudo yum remove gitlab-ee로 GitLab 패키지를 완전히 제거하는 것이 가장 안전할 수 있습니다.

14.04 LTS와 같은 이전 버전의 Ubuntu 또는 Upstart init 시스템을 기반으로 하는 다른 배포를 사용하는 경우, root로 initctl stop gitlab-runsvdir && echo 'manual' > /etc/init/gitlab-runsvdir.override && initctl reload-configuration을 사용하여 기계가 재부팅될 때 GitLab이 시작되는 것을 방지할 수 있습니다.
기본 사이트에 SSH 액세스가 없는 경우 기계를 오프라인 상태로 만들고 재부팅을 방지합니다. 이를 달성하는 방법은 여러 가지가 있으므로 단일 권장 사항은 제공하지 않습니다. 다음이 필요할 수 있습니다:

로드 밸런서를 재구성합니다.
- DNS 레코드를 변경합니다(예: 기본 DNS 레코드를 보조 사이트로 지정하여 기본 사이트 사용을 중지합니다).
- 가상 서버를 중지합니다.
- 방화벽을 통해 트래픽을 차단합니다.
- 기본 사이트에서 객체 스토리지 권한을 취소합니다.
- 기계를 물리적으로 분리합니다.

보조 사이트 승격#

보조 사이트의 모든 Sidekiq, PostgreSQL, Gitaly 노드에 SSH 접속하고 다음 명령 중 하나를 실행합니다:

보조 사이트를 기본으로 승격하려면:

sudo gitlab-ctl geo promote

추가 확인 없이 보조 사이트를 기본으로 승격하려면:

sudo gitlab-ctl geo promote --force

보조 사이트의 각 Rails 노드에 SSH 접속하고 다음 명령 중 하나를 실행합니다:

보조 사이트를 기본으로 승격하려면:

sudo gitlab-ctl geo promote

추가 확인 없이 보조 사이트를 기본으로 승격하려면:

sudo gitlab-ctl geo promote --force

이전에 보조 사이트에 사용했던 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면 보조 사이트가 이제 기본 사이트로 승격됩니다.

다음 단계#

지리적 중복성을 최대한 빨리 회복하려면 새 보조 사이트를 추가해야 합니다. 이를 위해 이전 기본을 새 보조로 다시 추가하고 온라인 상태로 만들 수 있습니다.

재해 복구(Geo) 승격 런북

GitLab v19.2

Tier: Premium, Ultimate
Offering: GitLab Self-Managed

원문 보기

번역일: 2026-06-19

요약

재해 복구(Geo) 승격 런북.

Warning

이 런북은 실험입니다. 완전하고 프로덕션 준비된 문서는 재해 복구 문서를 참조하세요.

다중 노드 구성을 위한 Geo 계획된 장애 조치#

구성 요소	구성
PostgreSQL	Linux 패키지로 관리
Geo 사이트	다중 노드
보조 사이트	하나

이 런북은 하나의 보조 사이트가 있는 다중 노드 Geo 사이트의 계획된 장애 조치를 안내합니다. 다음 40 RPS / 2,000 사용자 참조 아키텍처를 가정합니다:

기본 사이트(다중 노드):

Rails 노드 1
Rails 노드 2
PostgreSQL 노드
Gitaly 노드
Redis 노드
모니터링 노드

보조 사이트:

Rails 노드 1
Rails 노드 2
PostgreSQL 노드
Gitaly 노드
Redis 노드
모니터링 노드

이 가이드의 결과:

오프라인 기본 사이트.
이제 새 기본 사이트가 된 승격된 보조 사이트.

다루지 않는 사항:

이전 기본을 보조로 다시 추가.
새 보조 추가.

준비#

Note

보조 사이트에서:

오른쪽 상단 모서리에서 Admin을 선택합니다.
왼쪽 사이드바에서 Geo > Sites를 선택하여 상태를 확인합니다. 복제된 객체(녹색으로 표시)는 100%에 가까워야 하며 실패(빨간색으로 표시)가 없어야 합니다. 많은 비율의 객체가 복제되지 않은 경우(회색으로 표시), 사이트에 더 많은 시간을 주는 것을 고려하세요.

[

](/19.2/administration/geo/disaster_recovery/img/geo_dashboard_v14_0.png)

복제에 실패하는 객체가 있는 경우, 유지 보수 기간을 예약하기 전에 이를 조사해야 합니다. 계획된 장애 조치 후 복제에 실패한 항목은 손실됩니다.

보조 사이트가 여전히 기본 사이트에서 데이터를 복제하고 있는 경우, 불필요한 데이터 손실을 방지하기 위해 다음 단계를 따르세요:

기본 사이트에서 유지 보수 모드를 활성화하고 백그라운드 작업을 반드시 중지합니다.
모든 데이터 복제 및 검증 완료:

[!warning] 모든 데이터가 자동으로 복제되지는 않습니다. 제외되는 항목에 대해 자세히 읽어보세요.

Geo에서 관리하지 않는 데이터를 수동으로 복제하는 경우, 지금 최종 복제 프로세스를 트리거합니다.
기본 사이트에서:

오른쪽 상단 모서리에서 Admin을 선택합니다.
- 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
- Sidekiq 대시보드에서 Queues를 선택하고 이름에 geo가 있는 것을 제외한 모든 큐가 0으로 떨어질 때까지 기다립니다. 이러한 큐에는 사용자가 제출한 작업이 포함되어 있으며, 완료되기 전에 장애 조치를 수행하면 작업이 손실됩니다.
- 왼쪽 사이드바에서 Geo > Sites를 선택하고 장애 조치할 보조 사이트의 다음 조건이 충족될 때까지 기다립니다:
  
  모든 복제 미터가 100% 복제됨, 0% 실패에 도달합니다.
  - 모든 검증 미터가 100% 검증됨, 0% 실패에 도달합니다.
  - 데이터베이스 복제 지연이 0ms입니다.
  - Geo 로그 커서가 최신 상태입니다(0 이벤트 뒤처짐).
- 보조 사이트에서:
  
  오른쪽 상단 모서리에서 Admin을 선택합니다.
  - 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
  - Sidekiq 대시보드에서 Queues를 선택하고 모든 geo 큐가 0 대기 및 0 실행 중인 작업으로 떨어질 때까지 기다립니다.
  - 무결성 검사 실행으로 파일 스토리지의 CI 아티팩트, LFS 객체, 업로드의 무결성을 확인합니다.

이 시점에서 보조 사이트는 기본 사이트의 모든 것의 최신 복사본을 포함합니다. 이는 장애 조치 시 아무것도 손실되지 않음을 의미합니다.

이 최종 단계에서는 기본 사이트를 영구적으로 비활성화해야 합니다.

[!warning] 기본 사이트가 오프라인 상태가 되면 보조 사이트에 복제되지 않은 기본 사이트에 저장된 데이터가 있을 수 있습니다. 진행하면 이 데이터는 손실된 것으로 처리되어야 합니다.

기본 도메인 DNS 레코드를 업데이트할 계획이라면 전파 속도를 높이기 위해 지금 TTL을 낮추는 것이 좋습니다.

장애 조치를 수행할 때 두 개의 서로 다른 GitLab 인스턴스에서 쓰기가 발생할 수 있는 분리 뇌(split-brain) 상황을 피하려고 합니다. 따라서 장애 조치를 준비하기 위해 기본 사이트를 비활성화해야 합니다:

기본 사이트에 SSH 액세스가 있는 경우 GitLab을 중지하고 비활성화합니다:

sudo gitlab-ctl stop

서버가 예기치 않게 재부팅되는 경우 GitLab이 다시 시작되는 것을 방지합니다:

sudo systemctl disable gitlab-runsvdir

[!note]

CentOS 6 이하에서는 기계가 재부팅될 경우 GitLab이 시작되는 것을 방지하는 것이 어렵습니다(이슈 3058 참조). sudo yum remove gitlab-ee로 GitLab 패키지를 완전히 제거하는 것이 가장 안전할 수 있습니다.

14.04 LTS와 같은 이전 버전의 Ubuntu 또는 Upstart init 시스템을 기반으로 하는 다른 배포를 사용하는 경우, root로 initctl stop gitlab-runsvdir && echo 'manual' > /etc/init/gitlab-runsvdir.override && initctl reload-configuration을 사용하여 기계가 재부팅될 때 GitLab이 시작되는 것을 방지할 수 있습니다.
기본 사이트에 SSH 액세스가 없는 경우 기계를 오프라인 상태로 만들고 재부팅을 방지합니다. 이를 달성하는 방법은 여러 가지가 있으므로 단일 권장 사항은 제공하지 않습니다. 다음이 필요할 수 있습니다:

로드 밸런서를 재구성합니다.
- DNS 레코드를 변경합니다(예: 기본 DNS 레코드를 보조 사이트로 지정하여 기본 사이트 사용을 중지합니다).
- 가상 서버를 중지합니다.
- 방화벽을 통해 트래픽을 차단합니다.
- 기본 사이트에서 객체 스토리지 권한을 취소합니다.
- 기계를 물리적으로 분리합니다.

보조 사이트 승격#

보조 사이트의 모든 Sidekiq, PostgreSQL, Gitaly 노드에 SSH 접속하고 다음 명령 중 하나를 실행합니다:

보조 사이트를 기본으로 승격하려면:

sudo gitlab-ctl geo promote

추가 확인 없이 보조 사이트를 기본으로 승격하려면:

sudo gitlab-ctl geo promote --force

보조 사이트의 각 Rails 노드에 SSH 접속하고 다음 명령 중 하나를 실행합니다:

보조 사이트를 기본으로 승격하려면:

sudo gitlab-ctl geo promote

추가 확인 없이 보조 사이트를 기본으로 승격하려면:

sudo gitlab-ctl geo promote --force

이전에 보조 사이트에 사용했던 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면 보조 사이트가 이제 기본 사이트로 승격됩니다.