재해 복구의 주된 용도는 계획되지 않은 중단이 발생했을 때 비즈니스 연속성을 보장하는 것이지만, 계획된 페일오버와 함께 사용하면 긴 다운타임 없이 리전 간에 GitLab 인스턴스를 마이그레이션하는 데에도 활용할 수 있습니다.

Geo 사이트 간 복제는 비동기이므로, 계획된 페일오버에는 기본 사이트에 대한 업데이트가 차단되는 유지 관리 기간이 필요합니다. 이 기간의 길이는 보조 사이트를 기본 사이트와 완전히 동기화하는 데 걸리는 시간에 따라 달라집니다. 동기화가 완료되면 데이터 손실 없이 페일오버할 수 있습니다.

이 문서는 이미 완전히 구성되어 동작하는 Geo 설정이 있다고 가정합니다. 진행하기 전에 이 문서와 재해 복구 페일오버 문서를 전부 읽습니다. 계획된 페일오버는 중대한 작업이며, 잘못 수행하면 데이터 손실 위험이 큽니다. 필요한 단계에 익숙해지고 정확하게 수행할 수 있다는 확신이 높아질 때까지 절차를 리허설합니다.

페일오버 권장 사항#

다음 권장 사항을 따르면 페일오버 과정이 원활하게 진행되고 데이터 손실이나 장기 다운타임의 위험이 줄어듭니다.

동기화 및 검증 오류 해결#

사전 점검 중에(수동 검증이든 gitlab-ctl promotion-preflight-checks 실행이든) Failed 또는 Queued 항목이 있으면, 다음 중 하나가 이루어질 때까지 페일오버가 차단됩니다.

• 해결: 성공적으로 동기화하고(필요하면 보조 사이트로 직접 복사해) 검증합니다.
• 허용 가능한 것으로 문서화: 다음과 같은 명확한 근거를 남깁니다.
  • 해당 특정 실패에 대해 수동 체크섬 비교가 통과합니다.
  • 리포지터리가 더 이상 사용되지 않아 제외할 수 있습니다.
  • 항목이 중요하지 않은 것으로 확인되어 페일오버 후에 복사할 수 있습니다.

동기화 및 검증 실패의 진단에 관한 도움말은 Geo 동기화 및 검증 오류 문제 해결을 참고합니다.

데이터 무결성 해결 계획#

Geo 복제를 처음 설정한 뒤에 흔히 드러나는 데이터 무결성 문제를 해결하려면 페일오버 완료까지 4~6주를 확보합니다. 이런 문제에는 고아 데이터베이스 레코드나 일관성 없는 파일 참조가 포함될 수 있습니다. 지침은 일반적인 Geo 오류 문제 해결을 참고합니다.

유지 관리 기간 중에 어려운 결정을 내리지 않도록 동기화 문제를 일찍 해결하기 시작합니다.

1. 4~6주 전: 남아 있는 동기화 문제를 파악하고 해결을 시작합니다.
2. 1주 전: 남아 있는 모든 동기화 문제의 해결 또는 문서화를 목표로 합니다.
3. 1~2일 전: 새로 발생한 실패를 해결합니다.
4. 몇 시간 전: 새로 발생한 실패가 있는지 마지막으로 확인합니다.

성공을 위해, 해결되지 않은 동기화 오류 때문에 페일오버를 중단할 시점에 대한 명확한 기준을 만듭니다.

Geo 환경에서 백업 타이밍 테스트#

백업 절차를 미리 테스트하고 다음 전략을 고려합니다.

• 기본 사이트에서 직접 백업합니다. 성능에 영향을 줄 수 있습니다.
• 백업 중에 복제에서 격리할 수 있는 전용 읽기 복제본을 사용합니다.
• 활동이 적은 시간대에 백업을 예약합니다.

포괄적인 폴백 절차 준비#

원래 기본 사이트로 되돌리는 구체적인 단계를 문서화합니다. 여기에는 다음이 포함됩니다.

• 페일오버를 중단할 시점에 대한 판단 기준입니다.
• DNS 되돌리기 절차입니다.
• 원래 기본 사이트를 다시 활성화하는 과정입니다. 강등된 기본 사이트를 다시 온라인으로 전환을 참고합니다.
• 사용자 커뮤니케이션 계획입니다.

스테이징 환경에서 페일오버 런북 개발#

성공을 위해 이 수작업이 많은 작업을 아주 상세하게 연습하고 문서화합니다.

1. 프로덕션과 유사한 환경이 아직 없다면 프로비저닝합니다.
2. 스모크 테스트를 수행합니다. 예를 들어 그룹 추가, 프로젝트 추가, 러너 추가, git push 사용, 이슈에 이미지 추가가 있습니다.
3. 보조 사이트로 페일오버합니다.
4. 스모크 테스트를 실행합니다. 문제가 있는지 살펴봅니다.
5. 이 단계들을 진행하면서 수행한 모든 작업, 수행자, 기대 결과, 리소스 링크를 기록합니다.
6. 런북과 스크립트를 다듬기 위해 필요한 만큼 반복합니다.

모든 데이터가 자동으로 복제되지는 않음#

Geo가 지원하지 않는 GitLab 기능을 사용하고 있다면, 해당 기능과 연관된 데이터의 최신 사본을 보조 사이트가 갖도록 별도의 조치를 마련해야 합니다. 이로 인해 유지 관리 기간이 크게 길어질 수 있습니다. Geo가 지원하는 기능 목록은 복제되는 데이터 유형 표를 참고합니다.

파일로 저장된 데이터에서 이 기간을 최대한 짧게 유지하는 일반적인 전략은 rsync로 데이터를 전송하는 것입니다. 최초 rsync는 유지 관리 기간 전에 수행할 수 있습니다. 유지 관리 기간 안의 최종 전송을 포함한 이후의 rsync 절차는 기본 사이트와 보조 사이트 사이의 변경 사항만 전송합니다.

rsync를 효과적으로 사용하는 Git 리포지터리 중심 전략은 리포지터리 이동을 참고합니다. 이 전략은 파일 기반 데이터 전반에 맞게 응용할 수 있습니다.

컨테이너 레지스트리#

기본적으로 컨테이너 레지스트리는 보조 사이트로 자동 복제되지 않습니다. 이는 수동으로 구성해야 합니다. 자세한 내용은 보조 사이트의 컨테이너 레지스트리를 참고합니다.

페일오버에서 레지스트리에 요구되는 것은 서로 다른 두 가지, 즉 레지스트리가 사용하는 메타데이터 백엔드와 이미지가 저장되는 위치에 따라 달라집니다. 두 가지 설정은 사이트가 가진 역할에 따라서도 달라지며, 어떤 백엔드와 스토리지를 쓰든 승격 후에 변경해야 합니다.

승격 시 이어지지 않는 구성#

• 승격된 사이트는 자체 API로 레지스트리 알림을 보내기 시작해야 합니다. 보조 사이트로만 운영된 사이트에는 registry['notifications'] 블록이 없으므로, 승격 후에는 이미지가 푸시되었다는 사실을 GitLab에 알리는 것이 없고, 남아 있는 보조 사이트로의 복제도 시작되지 않습니다. 기본 사이트 구성에 설명된 대로 구성합니다.

  이 상태는 오류를 보고하지 않습니다. 엔드포인트가 구성되어 있지 않으면 레지스트리가 알릴 대상이 없으므로 레지스트리 로그와 api_json.log 모두에 아무것도 기록되지 않고, 보조 사이트의 컨테이너 리포지터리는 마지막으로 성공한 동기화의 타임스탬프와 함께 계속 동기화됨으로 보고됩니다. 승격 후 알림이 전달되고 있는지 확인하려면 승격된 사이트에서 이 점검을 실행해 보고되는 타임스탬프를 기록하고, 이미지를 푸시한 다음 즉시 다시 실행합니다.

  sudo gitlab-rake gitlab:geo:check
  

  GitLab 18.9 이상에서는 Container Registry replication enabled 점검이 Container Registry Geo events ... last event at <timestamp>도 보고합니다. 푸시보다 나중의 타임스탬프는 승격된 사이트가 알림을 보내고 있음을 확인해 줍니다. 타임스탬프가 진행되지 않은 것만으로는 문제의 증거가 되지 않습니다. 남아 있는 보조 사이트가 없으면 이벤트가 생성되지 않고, Geo::PruneEventLogWorker가 5분마다 실행되어 남아 있는 모든 보조 사이트가 처리한 이벤트를 제거하므로, 정상인 사이트에서도 점검이 none found나 더 오래된 타임스탬프를 보고할 수 있습니다. 그런 경우에는 승격된 사이트의 api_json.log에서 푸시 이후 /api/v4/container_registry_event/events에 대한 요청을 확인합니다. 200은 알림이 수락되었다는 뜻입니다. 401은 알림 시크릿이 일치하지 않는다는 뜻이므로 레지스트리 이벤트 로그 응답 상태 401 Unauthorized unaccepted를 참고합니다. gitlab_rails['geo_registry_replication_enabled']가 설정되어 있지 않으면 이 점검은 전부 건너뛰므로, 먼저 그 설정을 확인합니다. 보조 사이트에서 승격된 사이트는 gitlab_rails['geo_registry_replication_primary_api_url']와 함께 이 설정을 그대로 가지고 있으며, 둘 다 그대로 두어도 됩니다. 두 설정 모두 기본 사이트의 복제에는 영향을 주지 않으며, 승격이 이를 변경하지도 않습니다.

• 보조 사이트로 남는 사이트는 보조 사이트 구성에 설명된 대로 gitlab_rails['geo_registry_replication_primary_api_url']이 승격된 사이트를 가리키도록 해야 합니다.

메타데이터 데이터베이스#

레지스트리가 컨테이너 레지스트리 메타데이터 데이터베이스를 사용하면, 태그와 매니페스트 메타데이터는 Geo가 복제하지 않고 승격할 필요도 없는 PostgreSQL 데이터베이스에 있습니다. 이미지 스토리지만 복사하면 다른 사이트의 레지스트리에는 그 메타데이터가 없게 됩니다. 이는 오브젝트 스토리지의 이미지와 로컬 파일 시스템 스토리지의 이미지의 모든 절차에 적용됩니다. Geo 컨테이너 레지스트리 복제는 보조 사이트 자체의 레지스트리 데이터베이스와 스토리지를 채우므로, 레지스트리를 복제하는 보조 사이트는 이미지와 메타데이터를 모두 보유합니다.

각 사이트는 자체 레지스트리 데이터베이스와 자체 스토리지를 운영하므로, 승격 후에도 레지스트리는 이미 사용하던 리소스에서 계속 서비스합니다. 승격은 사이트를 재구성하지만, 레지스트리의 데이터베이스 구성과 스토리지는 그대로 둡니다.

Geo가 복제하는 이미지#

Geo가 컨테이너 레지스트리를 복제한다면 보조 사이트는 이미 자체 스토리지에 이미지를 보유하고 있습니다. 오브젝트 스토리지의 이미지와 로컬 파일 시스템 스토리지의 이미지의 절차는 필요하지 않습니다. 유지 관리 기간 전에 보조 사이트가 이미지를 보유하고 있는지 컨테이너 레지스트리 확인에 설명된 대로 확인합니다.

오브젝트 스토리지의 이미지#

유지 관리 기간 전에 오브젝트 스토리지 공급자의 자체 도구로 버킷을 복제합니다.

버킷을 복사하면 이미지만 복사됩니다. 메타데이터 데이터베이스를 사용하는 레지스트리에는 메타데이터도 필요하지만, 이 절차는 메타데이터를 복사하지 않습니다. 메타데이터 데이터베이스를 참고합니다.

로컬 파일 시스템 스토리지의 이미지#

현재 기본 사이트에서 컨테이너 레지스트리에 로컬 스토리지를 사용한다면, 페일오버할 보조 사이트로 컨테이너 레지스트리 객체를 rsync할 수 있습니다. rsync는 이미지만 복사합니다. 메타데이터 데이터베이스를 사용하는 레지스트리에는 메타데이터도 필요하므로 메타데이터 데이터베이스를 참고합니다.

# Run from the secondary site
rsync --archive --perms --delete root@<geo-primary>:/var/opt/gitlab/gitlab-rails/shared/registry/. /var/opt/gitlab/gitlab-rails/shared/registry

또는 기본 사이트에서 컨테이너 레지스트리를 백업한 뒤 보조 사이트에 복원할 수도 있습니다.

1. 기본 사이트에서 레지스트리만 백업하고 백업에서 특정 디렉터리를 제외합니다.

   # Create a backup in the /var/opt/gitlab/backups folder
   sudo gitlab-backup create SKIP=db,uploads,builds,artifacts,lfs,terraform_state,pages,repositories,packages
   

2. 기본 사이트에서 생성된 백업 tarball을 보조 사이트의 /var/opt/gitlab/backups 폴더로 복사합니다.

3. 보조 사이트에서 GitLab 복원 문서에 따라 레지스트리를 복원합니다.

고급 검색 데이터 복구#

고급 검색은 Elasticsearch 또는 OpenSearch로 구동됩니다. 고급 검색 데이터는 보조 사이트로 자동 복제되지 않습니다.

새로 승격된 기본 사이트에서 고급 검색 데이터를 복구하려면:

사전 점검#

계획된 페일오버를 예약하기 전에, 다음 사전 점검을 확인해 과정이 원활하게 진행되도록 합니다. 각 단계는 이어지는 섹션에서 더 자세히 설명합니다.

실제 페일오버 과정에서는 기본 사이트가 중단된 뒤에 다음 명령을 실행해 보조 사이트를 승격하기 전에 최종 검증 점검을 수행합니다.

gitlab-ctl promotion-preflight-checks

gitlab-ctl promotion-preflight-checks 명령은 페일오버 과정의 일부이며 기본 사이트가 중단된 상태를 요구합니다. 기본 사이트가 아직 실행 중인 동안에는 유지 관리 전 검증 도구로 사용할 수 없습니다. 이 명령을 실행하면 기본 사이트가 중단되었는지 묻는 프롬프트가 표시됩니다. No로 답하면 ERROR: primary node must be down 오류가 표시됩니다.

기본 사이트가 아직 운영 중인 동안의 유지 관리 전 검증에는 이어지는 섹션의 수동 점검을 사용합니다.

DNS TTL#

기본 도메인 DNS 레코드를 업데이트할 계획이라면, DNS 변경이 빠르게 전파되도록 낮은 TTL(time-to-live) 설정을 고려합니다.

오브젝트 스토리지#

GitLab 설치 규모가 크거나 다운타임을 감당할 수 없다면, 계획된 페일오버를 예약하기 전에 오브젝트 스토리지로 마이그레이션하는 것을 고려합니다. 이렇게 하면 유지 관리 기간의 길이와, 계획된 페일오버를 제대로 수행하지 못했을 때의 데이터 손실 위험을 모두 줄일 수 있습니다.

GitLab이 보조 사이트의 오브젝트 스토리지 복제를 관리하도록 하려면 오브젝트 스토리지 복제를 참고합니다.

각 보조 사이트의 구성 검토#

데이터베이스 설정은 보조 사이트로 자동 복제됩니다. 그러나 /etc/gitlab/gitlab.rb 파일은 수동으로 설정해야 하며, 사이트마다 다릅니다. Mattermost, OAuth, LDAP 통합 같은 기능이 기본 사이트에서는 활성화되어 있고 보조 사이트에서는 그렇지 않으면, 페일오버 중에 손실됩니다.

두 사이트의 /etc/gitlab/gitlab.rb 파일을 검토합니다. 계획된 페일오버를 예약하기 전에 보조 사이트가 기본 사이트의 모든 기능을 지원하는지 확인합니다. GitLab Geo 역할이 올바르게 구성되어 있는지 확인합니다.

시스템 점검 실행#

기본 사이트와 보조 사이트 양쪽에서 다음을 실행합니다.

gitlab-rake gitlab:check
gitlab-rake gitlab:geo:check

어느 한쪽 사이트라도 실패를 보고하면, 계획된 페일오버를 예약하기 전에 해결합니다.

노드 간에 시크릿과 SSH 호스트 키가 일치하는지 확인#

SSH 호스트 키와 /etc/gitlab/gitlab-secrets.json 파일은 모든 노드에서 동일해야 합니다. 모든 노드에서 다음을 실행하고 출력을 비교해 확인합니다.

sudo sha256sum /etc/ssh/sshhost /etc/gitlab/gitlab-secrets.json

파일이 다르면 필요에 따라 GitLab 시크릿을 수동으로 복제하고 SSH 호스트 키를 복제해 보조 사이트에 반영합니다.

HTTPS를 위한 올바른 인증서 설치 확인#

기본 사이트와 기본 사이트가 액세스하는 모든 외부 사이트가 공인 CA가 발급한 인증서를 사용한다면 이 단계는 건너뛰어도 됩니다.

다음 중 하나에 해당하면 보조 사이트에 올바른 인증서를 설치해야 합니다.

• 기본 사이트가 인바운드 연결을 보호하기 위해 사용자 지정 또는 자체 서명 TLS 인증서를 사용합니다.
• 기본 사이트가 사용자 지정 또는 자체 서명 인증서를 사용하는 외부 서비스에 연결합니다.

자세한 내용은 보조 사이트에서 사용자 지정 인증서 사용을 참고합니다.

Geo 복제가 최신 상태인지 확인#

Geo 복제와 검증이 완전히 끝나기 전에는 유지 관리 기간이 종료되지 않습니다. 이 기간을 최대한 짧게 유지하려면, 활발히 사용되는 동안에 이 과정들이 가능한 한 100%에 가깝도록 해야 합니다.

보조 사이트에서 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.

2. 왼쪽 사이드바에서 Geo > Sites를 선택합니다. 복제된 객체(녹색으로 표시)는 100%에 가까워야 하고, 실패(빨간색으로 표시)는 없어야 합니다. 아직 복제되지 않은 객체(회색으로 표시)의 비중이 크다면, 사이트가 완료할 시간을 더 주는 것을 고려합니다.

   

객체 복제가 실패하면 유지 관리 기간을 예약하기 전에 원인을 조사합니다. 복제에 실패한 객체는 계획된 페일오버 후에 손실됩니다.

복제 실패의 흔한 원인은 기본 사이트에 데이터가 없는 것입니다. 이런 실패를 해결하려면 다음 중 하나를 수행합니다.

• 백업에서 데이터를 복원합니다.
• 없는 데이터에 대한 참조를 제거합니다.

복제된 데이터의 무결성 확인#

페일오버를 진행하기 전에 검증이 완료되었는지 확인합니다. 검증에 실패한 손상된 데이터는 페일오버 중에 손실될 수 있습니다.

자세한 내용은 자동 백그라운드 검증을 참고합니다.

컨테이너 레지스트리 확인#

보조 사이트가 컨테이너 레지스트리를 복제한다면, 유지 관리 기간 전에 보조 사이트가 이미지를 보유하고 있고 두 사이트가 예상하는 메타데이터 백엔드에서 서비스하고 있는지 확인합니다.

1. 카탈로그를 비교합니다. 카탈로그를 읽으려면 registry:catalog:* 스코프를 가진 토큰이 필요하며, 이 토큰은 관리자에게만 발급됩니다. 개인 액세스 토큰에는 최소한 read_registry 스코프가 있어야 합니다. 각 사이트에서 토큰을 생성하고 카탈로그를 나열합니다.

   token=$(curl --silent --user "<administrator-username>:<personal-access-token>" \
     "https://<gitlab-host>/jwt/auth?service=container_registry&scope=registry:catalog:*" \
     | grep --only-matching '"token":"[^"]*"' | cut --delimiter='"' --fields=4)
   
   curl --silent --header "Authorization: Bearer ${token}" \
     "https://<registry-host>/v2/_catalog?n=1000"
   

   카탈로그 요청에서 401이 반환되면 보통 해당 계정이 관리자가 아니라는 뜻입니다. 토큰 요청은 인증된 사용자라면 성공하지만, 관리자가 아닌 경우 반환되는 토큰에는 액세스 권한이 없습니다.

   카탈로그는 페이지로 나뉩니다. 기본적으로 100개의 리포지터리를 반환하며, n으로 페이지 크기를 설정할 수 있으나 1000을 넘을 수 없고, 그보다 큰 값을 요청하면 페이지 대신 오류가 반환됩니다. 리포지터리가 더 남아 있으면 응답에 다음 페이지의 URL이 담긴 Link 헤더가 포함됩니다. Link 헤더가 반환되지 않을 때까지 따라가며, 첫 페이지가 아니라 전체 목록을 비교합니다.

   Geo의 컨테이너 리포지터리 동기화 상태만 신뢰하지 않습니다. 태그 실패는 레지스트리에 기록되지 않고 로그로만 남기 때문에, 개별 태그 전송이 실패했는데도 리포지터리는 동기화됨으로 기록될 수 있습니다. 보조 사이트의 geo.log에서 Error while syncing tag 항목을 확인합니다.

2. 각 사이트가 어떤 메타데이터 백엔드를 사용하고 있는지 활성 메타데이터 백엔드 확인에 설명된 대로 확인합니다. 레거시 메타데이터로 폴백한 사이트도 정상으로 보고되므로, 이는 Geo 대시보드에서 보이지 않습니다.

예약된 유지 관리를 사용자에게 알림#

기본 사이트에서 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Messages를 선택합니다.
3. 유지 관리 기간을 사용자에게 알리는 메시지를 추가합니다. 동기화 완료에 필요한 시간을 추정하려면 Geo > Sites로 이동합니다.
4. Add broadcast message를 선택합니다.

페일오버 중 러너 연결#

인스턴스 URL을 어떻게 구성했는지에 따라, 페일오버 후에 러너 플릿을 100%로 유지하기 위한 추가 단계가 필요할 수 있습니다.

러너를 등록하는 데 사용하는 토큰은 기본 인스턴스와 보조 인스턴스 모두에서 동작해야 합니다. 페일오버 후에 연결 문제가 보이면 보조 사이트 구성 중에 시크릿이 복사되지 않았을 수 있습니다. 러너 토큰을 재설정할 수 있습니다. 다만 시크릿이 동기화되지 않았다면 러너와 무관한 다른 문제도 겪을 수 있습니다.

러너가 GitLab 인스턴스에 반복해서 연결하지 못하면 일정 시간 동안 연결 시도를 중단합니다. 기본적으로 이 시간은 1시간입니다. 이를 피하려면 GitLab 인스턴스에 접근할 수 있게 될 때까지 러너를 종료합니다. check_interval 문서와 구성 옵션 unhealthy_requests_limit, unhealthy_interval을 참고합니다.

• Location aware URL을 사용하는 경우: 이전 기본 사이트가 DNS 구성에서 제거된 뒤에는 러너가 자동으로 가장 가까운 다음 인스턴스에 연결됩니다.
• 별도의 URL을 사용하는 경우: 현재 기본 사이트에 연결된 러너는 새 기본 사이트가 승격된 뒤에 그 사이트에 연결되도록 업데이트해야 합니다.
• 현재 보조 사이트에 연결된 러너가 있는 경우: 페일오버 중의 보조 사이트 러너 처리 방법을 참고합니다.

OpenBao 사전 요구 사항#

GitLab Helm 차트로 OpenBao를 설치했다면, 기본 클러스터에 아직 접근할 수 있는 동안 다음 점검을 완료합니다.

보조 사이트에 언실 시크릿이 있는지 확인#

gitlab-openbao-unseal Kubernetes 시크릿이 보조 클러스터에 있어야 합니다. 존재하는지 확인합니다.

kubectl --namespace gitlab get secret gitlab-openbao-unseal

시크릿이 없으면 진행하기 전에 기본 클러스터에서 복사합니다. 자세한 내용은 시크릿 백업을 참고합니다.

OpenBao 데이터베이스 복제 검증#

보조 OpenBao 데이터베이스는 openbao 스키마를 포함한 기본 PostgreSQL의 읽기 복제본입니다. 계획된 페일오버 전에 복제가 최신 상태이고 보조 사이트의 데이터가 기본 사이트와 일치하는지 확인합니다.

기본 데이터베이스를 이미 사용할 수 없다면, 보조 사이트에는 마지막으로 복제된 트랜잭션까지의 데이터가 있습니다. 마지막 복제 이후에 기본 사이트에 기록된 시크릿은 손실됩니다.

기본 사이트에 대한 업데이트 방지#

모든 데이터가 보조 사이트로 복제되도록, 기본 사이트에서 업데이트(쓰기 요청)를 비활성화해 보조 사이트가 따라잡을 시간을 줍니다.

1. 기본 사이트에서 유지 관리 모드를 활성화합니다.

2. 오른쪽 상단에서 Admin을 선택합니다.

3. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.

4. Sidekiq 대시보드에서 Cron을 선택합니다.

5. Disable All을 선택해 Geo 이외의 주기적 백그라운드 job을 비활성화합니다.

6. 다음 cron job에 대해 Enable을 선택합니다.

   • geo_metrics_update_worker
   • geo_prune_event_log_worker
   • geo_verification_cron_worker
   • repository_check_worker

   이 cron job을 다시 활성화하는 것은 계획된 페일오버를 성공적으로 완료하는 데 필수입니다.

모든 데이터 복제 및 검증 완료#

1. Geo가 관리하지 않는 데이터를 수동으로 복제하고 있다면, 지금 최종 복제 과정을 트리거합니다.

2. 기본 사이트에서 다음을 수행합니다.

   1. 오른쪽 상단에서 Admin을 선택합니다.

   2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.

   3. Sidekiq 대시보드에서 Queues를 선택합니다. 이름에 geo가 들어간 큐를 제외한 모든 큐가 0으로 떨어질 때까지 기다립니다. 이 큐에는 사용자가 제출한 작업이 담겨 있습니다. 큐가 비기 전에 페일오버하면 그 작업이 손실됩니다.

   4. 왼쪽 사이드바에서 Geo > Sites를 선택합니다. 페일오버 대상 보조 사이트에서 다음 조건이 모두 충족될 때까지 기다립니다.

      • 모든 복제 계측값이 100% 복제, 실패 0%에 도달합니다.
      • 모든 검증 계측값이 100% 검증, 실패 0%에 도달합니다.
      • 데이터베이스 복제 지연이 0ms입니다.
      • Geo 로그 커서가 최신 상태입니다(이벤트 0개 지연).

3. 보조 사이트에서 다음을 수행합니다.

   1. 오른쪽 상단에서 Admin을 선택합니다.
   2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
   3. Sidekiq 대시보드에서 Queues를 선택합니다. 모든 geo 큐의 대기 job이 0, 실행 job이 0으로 떨어질 때까지 기다립니다.
   4. 무결성 점검을 실행해 파일 스토리지의 CI 아티팩트, LFS 객체, 업로드의 무결성을 확인합니다.

이 시점에서 보조 사이트는 기본 사이트가 가진 모든 것의 최신 사본을 보유하므로, 페일오버 시 데이터 손실이 없습니다.

보조 사이트 승격#

복제가 끝나면 보조 사이트를 기본 사이트로 승격합니다. 이 과정에서 보조 사이트에 짧은 중단이 발생하며, 사용자는 다시 로그인해야 할 수 있습니다. 단계를 올바르게 따르면 이전 기본 Geo 사이트가 비활성화되고, 사용자 트래픽은 새로 승격된 사이트로 흐릅니다.

승격이 완료되면 유지 관리 기간이 종료되고, 새 기본 사이트는 이제 이전 사이트와 달라지기 시작합니다.

페일오버가 완료된 뒤에는 브로드캐스트 메시지를 제거해야 합니다.

모든 것이 예상대로 동작한다면 이전 사이트를 보조 사이트로 되돌릴 수 있습니다.

이전 기본 사이트로 폴백#

새로 승격된 기본 사이트에 문제가 있으면 이전 사이트로 페일백할 수 있으나, 새 기본 사이트에서 만든 모든 변경 사항은 손실됩니다.