재해 복구(Geo) 프로모션 런북

재해 복구(Geo) 프로모션 런북에 대해 설명합니다.

Disaster Recovery (Geo) 프로모션 런북 # - Tier: Premium, Ultimate - Offering: GitLab Self-Managed # Status: Experiment Disaster Recovery (Geo) 프로모션 런북입니다. 이 런북은 [실험](/19.1/policy/development_stages_support/#experiment) 기능입니다. 완전한 프로덕션 준비 문서는 재해 복구 문서 를 참조하세요. 단일 노드 구성에 대한 Geo 계획된 장애 조치 # 구성 요소 구성 PostgreSQL Linux 패키지로 관리됨 Geo 사이트 단일 노드 보조 사이트 1개 이 런북은 하나의 보조 사이트를 가진 단일 노드 Geo 사이트의 계획된 장애 조치를 안내합니다. 다음과 같은 일반적인 아키텍처를 가정합니다: 기본 사이트: GitLab 노드 보조 사이트: GitLab 노드 이 가이드를 따르면 다음과 같은 결과를 얻을 수 있습니다: 오프라인 상태의 기본 사이트. 새 기본 사이트로 프로모션된 보조 사이트. 다루지 않는 내용: 이전 기본 사이트를 보조 사이트로 다시 추가하는 방법. 새 보조 사이트 추가 방법. 준비 # 다음 단계를 수행하기 전에, 보조 사이트를 프로모션할 수 있는 `root` 액세스 권한이 있는지 확인하세요. Geo 복제본을 프로모션하고 장애 조치를 수행하는 자동화된 방법은 없습니다. 보조 사이트에서 관리자 영역 > Geo 대시보드로 이동하여 상태를 검토하세요. 복제된 오브젝트(녹색으로 표시됨)가 100%에 가까워야 하며, 오류(빨간색으로 표시됨)가 없어야 합니다. 아직 복제되지 않은 오브젝트(회색으로 표시됨)의 비율이 크다면, 사이트가 완료할 수 있도록 더 많은 시간을 주는 것을 고려하세요. [ ](/19.1/administration/geo/disaster_recovery/img/geo_dashboard_v14_0.png) 복제에 실패하는 오브젝트가 있다면, 유지 보수 창을 예약하기 전에 이를 조사해야 합니다. 계획된 장애 조치 후에는 복제에 실패한 항목이 손실됩니다 . 복제 실패의 일반적인 원인은 기본 사이트에서 데이터가 누락된 경우입니다. 백업에서 데이터를 복원하거나 누락된 데이터에 대한 참조를 제거하여 이러한 실패를 해결할 수 있습니다. 유지 보수 창은 Geo 복제 및 검증이 완전히 완료될 때까지 종료되지 않습니다. 창을 최대한 짧게 유지하려면, 활성 사용 중에 이러한 프로세스가 가능한 한 100%에 가깝도록 해야 합니다. 보조 사이트가 기본 사이트에서 데이터를 아직 복제하고 있는 경우, 불필요한 데이터 손실을 방지하기 위해 다음 단계를 따르세요: 읽기 전용 모드 가 구현될 때까지, 기본 사이트에서 업데이트가 수동으로 발생하지 않도록 방지해야 합니다. 유지 보수 창 동안 보조 사이트는 기본 사이트에 대한 읽기 전용 액세스 권한이 필요합니다: 예정된 시간에, 클라우드 제공업체 또는 사이트의 방화벽을 사용하여, 귀하의 IP 및 보조 사이트의 IP를 제외하고 기본 사이트로/에서의 모든 HT