재해 복구(Geo) 승격 런북

재해 복구(Geo) 승격 런북에 대해 설명합니다.

재해 복구(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%에 가까워야 하며 실패(빨간색으로 표시)가 없어야 합니다. 많은 비율의 객체가 복제되지 않은 경우(회색으로 표시), 사이트에 더 많은 시간을 주는 것을 고려하세요. 복제에 실패하는 객체가 있는 경우, 유지 보수 기간을 예약하기 전에 이를 조사해야 합니다. 계획된 장애 조치 후 복제에 실패한 항목은 손실 됩니다. 복제 실패의 일반적인 원인은 기본 사이트에서 누락된 데이터입니다. 백업에서 데이터를 복원하거나 누락된 데이터에 대한 참조를 제거하여 이러한 실패를 해결할 수 있습니다. 유지 보수 기간은 Geo 복제 및 검증이 완전히 완료될 때까지 종료되지 않습니다. 기간을 최대한 짧게 유지하려면 활성 사용 중에 이러한 프로세스를 가능한 100%에 가깝게 유지해야 합니다. 보조 사이트가 여전히 기본 사이트에서 데이터를 복제하고 있는 경우, 불필요한 데이터 손실을 방지하기 위해 다음 단계를 따르세요: 기본 사이트에서 유지 보수 모드 를 활성화하고 백그라운드 작업 을 중지합니다. 모든 데이터 복제 및 검증 완료: [!warning] 모든 데이터가 자동으로 복제되지는 않습니다. 제외되는 항목 에 대해 자세히 읽어보세요. Geo에서 관리하지 않는 데이터 를 수동으로 복제하는 경우 지금 최종 복제 프로세스를 트리거합니다. 기본 사이트에서: 오른쪽 상단 모서리에서 Admin 을 선택합니다. 왼쪽 사이드바에서 Monitoring > Background jobs 를 선택합니다. Sidekiq 대시보드에서 Queues 를 선택하고 이름에 geo 가 있는 것을 제외한 모든 큐가 0으로 떨어질 때까지 기다립니다. 이러한 큐에는 사용자가 제출한 작업이 포