계획된 페일오버를 위한 재해 복구

Geo를 사용하여 사전 점검 및 동기화 단계를 따라 데이터 손실 없이 보조 사이트를 승격하여 최소 다운타임으로 GitLab 인스턴스를 리전 간에 마이그레이션하는 방법을 설명합니다.

재해 복구의 주된 용도는 계획되지 않은 중단이 발생했을 때 비즈니스 연속성을 보장하는 것이지만, 계획된 페일오버와 함께 사용하면 긴 다운타임 없이 리전 간에 GitLab 인스턴스를 마이그레이션하는 데에도 활용할 수 있습니다. Geo 사이트 간 복제는 비동기이므로, 계획된 페일오버에는 기본 사이트에 대한 업데이트가 차단되는 유지 관리 기간이 필요합니다. 이 기간의 길이는 보조 사이트를 기본 사이트와 완전히 동기화하는 데 걸리는 시간에 따라 달라집니다. 동기화가 완료되면 데이터 손실 없이 페일오버할 수 있습니다. 이 문서는 이미 완전히 구성되어 동작하는 Geo 설정이 있다고 가정합니다. 진행하기 전에 이 문서와 재해 복구 페일오버 문서를 전부 읽습니다. 계획된 페일오버는 중대한 작업이며, 잘못 수행하면 데이터 손실 위험이 큽니다. 필요한 단계에 익숙해지고 정확하게 수행할 수 있다는 확신이 높아질 때까지 절차를 리허설합니다. 페일오버 권장 사항 # 다음 권장 사항을 따르면 페일오버 과정이 원활하게 진행되고 데이터 손실이나 장기 다운타임의 위험이 줄어듭니다. 동기화 및 검증 오류 해결 # 사전 점검 중에(수동 검증이든 gitlab-ctl promotion-preflight-checks 실행이든) Failed 또는 Queued 항목이 있으면, 다음 중 하나가 이루어질 때까지 페일오버가 차단됩니다. 해결: 성공적으로 동기화하고(필요하면 보조 사이트로 직접 복사해) 검증합니다. 허용 가능한 것으로 문서화: 다음과 같은 명확한 근거를 남깁니다. 해당 특정 실패에 대해 수동 체크섬 비교가 통과합니다. 리포지터리가 더 이상 사용되지 않아 제외할 수 있습니다. 항목이 중요하지 않은 것으로 확인되어 페일오버 후에 복사할 수 있습니다. 동기화 및 검증 실패의 진단에 관한 도움말은 Geo 동기화 및 검증 오류 문제 해결 을 참고합니다. 데이터 무결성 해결 계획 # Geo 복제를 처음 설정한 뒤에 흔히 드러나는 데이터 무결성 문제를 해결하려면 페일오버 완료까지 4~6주를 확보합니다. 이런 문제에는 고아 데이터베이스 레코드나 일관성 없는 파일 참조가 포함될 수 있습니다. 지침은 일반적인 Geo 오류 문제 해결 을 참고합니다. 유지 관리 기간 중에 어려운 결정을 내리지 않도록 동기화 문제를 일찍 해결하기 시작합니다. 4~6주 전: 남아 있는 동기화 문제를 파악하고 해결을 시작합니다. 1주 전: 남아 있는 모든 동기화 문제의 해결 또는 문서화를 목표로 합니다. 1~2일 전: 새로 발생한 실패를 해결합니다. 몇 시간 전: 새로 발생한 실패가 있는지 마지막으로 확인합니다. 성공을 위해, 해결되지 않은 동기화 오류 때문에 페일오버를 중단할 시점에 대한 명확한 기준을 만듭니다. Geo 환경에서 백업 타이밍 테스트 # Warning Geo 복제 데이터베이스의 백업은 데이터베이스 트랜잭션이 진행되는 동안 취소될 수 있습니다. 백업 절차를 미리 테스트하고 다음 전략을 고려합니다. 기본 사이트에서 직접 백업합니다. 성능에 영향을 줄 수 있습니다. 백업 중에 복제에서 격리할 수 있는