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

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

재해 복구(Geo) 프로모션 런북. Warning 이 런북은 실험적 입니다. 완전한 프로덕션 준비 문서는 재해 복구 문서 를 참조하세요. 단일 노드 구성에 대한 Geo 계획된 페일오버 # 구성 요소 구성 PostgreSQL Linux 패키지로 관리됨 Geo 사이트 단일 노드 보조 사이트 하나 이 런북은 하나의 보조 사이트가 있는 단일 노드 Geo 사이트의 계획된 페일오버를 안내합니다. 다음 일반 아키텍처를 가정합니다: 기본 사이트: GitLab 노드 보조 사이트: GitLab 노드 이 가이드의 결과: 오프라인 기본 사이트. 이제 새 기본 사이트인 프로모션된 보조 사이트. 다루지 않는 내용: 이전 기본 사이트를 보조 사이트로 다시 추가. 새 보조 사이트 추가. 준비 # Note 이 단계를 따르기 전에 Geo 복제본을 프로모션하고 페일오버를 수행하는 자동화된 방법이 없으므로 보조 사이트에 root 접근 권한이 있는지 확인하세요. 보조 사이트에서 관리자 영역 > Geo 대시보드로 이동하여 상태를 검토합니다. 복제된 객체(녹색으로 표시됨)가 100%에 가까워야 하며 실패(빨간색으로 표시됨)가 없어야 합니다. 아직 복제되지 않은 객체(회색으로 표시됨)의 비율이 크면 사이트가 완료할 수 있도록 더 많은 시간을 고려하세요. 복제에 실패하는 객체가 있으면 유지 관리 기간을 예약하기 전에 조사해야 합니다. 계획된 페일오버 후에는 복제에 실패한 모든 항목이 손실됩니다 . 복제 실패의 일반적인 원인은 기본 사이트에 데이터가 없는 것입니다. 백업에서 데이터를 복원하거나 누락된 데이터에 대한 참조를 제거하여 이러한 실패를 해결할 수 있습니다. 유지 관리 기간은 Geo 복제 및 확인이 완전히 완료될 때까지 끝나지 않습니다. 기간을 최대한 짧게 유지하려면 활성 사용 중에 이 프로세스가 가능한 한 100%에 가까워야 합니다. 보조 사이트가 여전히 기본 사이트에서 데이터를 복제하는 경우 불필요한 데이터 손실을 방지하려면 다음 단계를 따르세요: 읽기 전용 모드 가 구현될 때까지 기본 사이트에서 수동으로 업데이트가 발생하지 않도록 해야 합니다. 보조 사이트는 유지 관리 기간 동안 기본 사이트에 대한 읽기 전용 접근이 필요합니다: 예약된 시간에 클라우드 제공업체 또는 사이트의 방화벽을 사용하여 사용자 IP 및 보조 사이트 IP를 제외한 기본 사이트와의 모든 HTTP, HTTPS 및 SSH 트래픽을 차단합니다. 예를 들어 기본 사이트에서 다음 명령을 실행할 수 있습니다: sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --destination-port 22 -j ACCEPT sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 22 -j ACCEPT sudo iptables -A INPUT --destination-port 22 -j REJECT sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --d