프라이머리 MongoDB Ops Manager를 잃은 경우 세컨더리 MongoDB Ops Manager에서 데이터베이스 백업 을 복원한 후 새 프라이머리 MongoDB Ops Manager를 시작합니다. 업그레이드 실패, 우연한 데이터 삭제 또는 인프라스트럭처 실패와 같은 이벤트 후에 이 절차를 사용합니다. 프라이머리 MongoDB Ops Manager가 다시 시작되면 일반 작업이 재개되기 전에 에이전트 구성을 조정하기 위해 자동으로 복원 모드에 진입합니다. 이 패턴에 대한 개요는 세컨더리 인스턴스를 사용하여 MongoDB Ops Manager 백업 및 복원을 참조하세요. 이 패턴을 구성하려면 MongoDB Ops Manager 백업을 위한 세컨더리 MongoDB Ops Manager 구성을 참조하세요.
고려 사항
순서 복원
데이터베이스 백업을 복원하고 프라이머리 MongoDB Ops Manager를 시작하는 순서가 매우 중요합니다.
경고
프라이머리 MongoDB Ops Manager를 시작하기 전에 데이터베이스 백업을 복원합니다. 데이터베이스 백업을 복원하기 전에 프라이머리 MongoDB Ops Manager를 시작하면 프라이머리 MongoDB Ops Manager가 일관성이 없는 상태를 쓰고 이전 배포와 새 배포 간에 분할 노드 시나리오가 발생할 수 있습니다.
세컨더리 MongoDB Ops Manager가 스냅샷 메타데이터 저장소와 oplog 메타데이터 저장소를도 백업하는 경우 프라이머리 MongoDB Ops Manager를 시작하기 전에 세 데이터베이스 백업을 동일한 시점으로 복원하거나 메타데이터 저장소를 애플리케이션 데이터베이스보다 약간 늦은 시점으로 복원합니다. 메타데이터 저장소를 애플리케이션 데이터베이스보다 이전 시점으로 복원하면 프라이머리 MongoDB Ops Manager가 HTTP 409 (스냅샷 블록 누락)로 영향을 받은 복원 작업을 거부합니다.
복구 시점
특정 시점 복원은 재해 발생 시점에 대한 것이 아니라 선택한 시점에 대한 애플리케이션 데이터베이스를 복원합니다. 재해 이전 oplog slice에서 백업이 캡처하지 못한 작업은 복원할 수 없을 수 있습니다. 특정 시점 복구 창이 허용하는 한도 내에서 재해에 가장 가까운 복구 지점을 선택합니다.
프라이머리 MongoDB Ops Manager가 다시 시작되면 조정이 MongoDB 에이전트에서 배포 자동화 구성을 복구합니다. 기타 최근 애플리케이션 데이터베이스 변경 사항에는 선택한 복원 시점이 반영됩니다.
버전 호환성
프라이머리 및 세컨더리 MongoDB Ops Manager 버전은 호환이 유지되어야 합니다.
경고
스냅샷을 촬영한 원본 프라이머리 MongoDB Ops Manager와 동일한 버전 또는 더 높은 버전을 실행하는 프라이머리 MongoDB Ops Manager에 애플리케이션 데이터베이스를 복원합니다. 대체 바이너리가 애플리케이션 데이터베이스의 기록된 버전보다 오래된 경우 MongoDB Ops Manager가 "다운그레이드는 허용되지 않습니다" 오류로 시작을 거부합니다.
전제 조건
복원 모드는 MongoDB Ops Manager 8.0.24 이상에서 기본적으로 활성화됩니다. 비활성화했은 경우 복원하기 전에 프라이머리 MongoDB Ops Manager에서 다시 활성화합니다. 자세한 단계는 MongoDB Ops Manager 백업을 위한 세컨더리 MongoDB Ops Manager 구성을 참조하세요.
세컨더리 MongoDB Ops Manager에 완료된 스냅샷과 데이터베이스 백업을 위한 연속적인 시점 복구 창이 있는지 확인합니다.
원래 프라이머리 MongoDB Ops Manager 설치에서
gen.key파일을 포함하여 복구에 필요한 호스트 별 상태가 유지되었는지 확인합니다.
호스트 별 상태 유지
프라이머리 MongoDB Ops Manager 복구에는 애플리케이션 데이터베이스 이상이 필요합니다. 세컨더리 MongoDB Ops Manager 백업이 지원하는 애플리케이션 데이터베이스 외에 각 호스트에서 다음 상태를 유지합니다.
item | 위치 | 설명 |
|---|---|---|
암호화 키 |
| 애플리케이션 데이터베이스 내용을 암호화합니다. 초기 설치에 사용된 키와 일치해야 합니다. 그렇지 않으면 프라이머리 Ops Manager가 스타트업 시 복원된 애플리케이션 데이터베이스를 복호화할 수 없습니다. |
Ops Manager 구성 |
| 데이터베이스 URL, 블록 저장소 구성, 라이센스 키 및 TLS 인증서를 저장합니다. 이것이 없으면 프라이머리 Ops Manager를 수동으로 다시 구성해야 합니다. |
에이전트 구성 |
|
|
중요
gen.key 파일이 없거나 복원된 애플리케이션 데이터베이스와 일치하지 않으면 프라이머리 MongoDB Ops Manager가 스타트업 사전 확인에 실패하고 gen.key 이 이 MongoDB Ops Manager 설치에 이미 사용된 키와 일치하지 않는 오류가 발생합니다. 재해 복구 백업에서 애플리케이션 데이터베이스 데이터와 함께 gen.key 를 보관합니다.
프라이머리 MongoDB Ops Manager 복원
데이터베이스 백업 복원
세컨더리 MongoDB Ops Manager에서 선택한 시점의 프라이머리 MongoDB Ops Manager의 애플리케이션 데이터베이스를 복원합니다.
Continuous Backup을 클릭한 다음 애플리케이션 데이터베이스 복제본 세트를 선택합니다.
메뉴를 클릭한 다음 Restore을 클릭합니다.
Point in Time을 선택한 다음 대상 날짜 및 시간을 입력합니다.
Choose Cluster to Restore to을 클릭하고 애플리케이션 데이터베이스 복제본 세트 호스트를 선택한 후 Restore을 클릭합니다.
세컨더리 MongoDB Ops Manager의 MongoDB Agent가 애플리케이션 데이터베이스 프로세스를 중지하고 데이터를 복원된 스냅샷으로 대체한 다음 타겟 시간까지 oplog를 재생하고 프로세스를 다시 시작합니다.
경고
세컨더리 MongoDB Ops Manager도 스냅샷과 oplog 메타데이터 저장소를 백업하는 경우 프라이머리 MongoDB Ops Manager를 시작하기 전에 애플리케이션 데이터베이스와 동일한 시점 또는 약간 늦은 시점으로 복원합니다. 메타데이터 저장소를 이전 시점으로 복원하면 프라이머리 MongoDB Ops Manager가 HTTP 409 ("스냅샷 블록 누락")로 영향을 받은 복원 작업을 거부합니다.
애플리케이션 데이터베이스만 복원하면 세컨더리 MongoDB Ops Manager가 메타데이터 저장소를 그대로 두업니다. 이는 일반적인 작업에는 안전하지만 프라이머리 MongoDB Ops Manager가 복원 시점과 지금 사이에 수행한 백업 스냅샷은 사용할 수 없을 수 있습니다.
프라이머리 Ops Manager 시작
프라이머리 MongoDB Ops Manager를 시작합니다. 프라이머리 MongoDB Ops Manager가 복원된 애플리케이션 데이터베이스에 연결하여 복원된 상태를 읽고 복구를 시작합니다. 자세한 내용은 MongoDB Ops Manager 애플리케이션 시작 및 중지를 참조하세요.
복원 모드 및 조정
애플리케이션 데이터베이스를 복원하고 프라이머리 MongoDB Ops Manager를 시작하면 프라이머리 MongoDB Ops Manager가 각 MongoDB Agent의 구성 버전을 복원된 구성 버전과 비교합니다. 에이전트가 나중 버전을 보고하면 프라이머리 MongoDB Ops Manager가 해당 프로젝트에 대해 복원 모드로 진입하고 구성을 자동으로 조정합니다.
프라이머리 MongoDB Ops Manager가 프로젝트를 경리합니다. 복원 모드 배너를 표시하고, 에이전트 폴에 대해 변경되지 않은 응답을 반환하며, 조정이 완료될 때까지 사용자 인터페이스와 API 에서의 배포 변경을 차단합니다.
프라이머리 MongoDB Ops Manager는 각 에이전트에서 구성 버전을 수집하고 최신 구성을 가진 에이전트를 선택하여 해당 구성을 정식 구성으로 애플리케이션 데이터베이스에 쓰기합니다.
프라이머리 MongoDB Ops Manager가 프로젝트에 대한 Restoration Mode를 종료하고 일반 작업을 다시 시작합니다. 백업이 자동으로 다시 시작됩니다.
이 조정은 분할 노드 시나리오를 방지합니다. 모든 에이전트가 새 구성을 수신하기 전에 단일 권한 구성에 대해 모든 에이전트를 집중합니다.
애플리케이션 데이터베이스를 이전 시점으로 복원하면 복원 시점 이후에 수행한 배포 변경 사항이 복원된 구성에 더 이상 포함되지 않습니다. 조정이 없으면 에이전트는 이전 구성을 받아 구성에서 더 이상 참조하지 않는 프로세스를 중지합니다. 영향은 배포 변경에 따라 달라집니다.
배포서버 변경 | 화해 없이 위험 |
|---|---|
새 복제본 세트 노드 | 데이터가 다른 노드에 존재하므로 데이터를 읽지 않습니다. |
마이그레이션된 청크가 있는 새 샤드 | 마이그레이션된 청크는 새 샤드에만 존재합니다. 이를 중지하면 데이터에 액세스할 수 없게 되어 데이터 손실이 발생합니다. |
새 프로세스 버전 | 이 프로세스는 롤백된 바이너리 버전에서 실행될 수 없으며 이로 인해 운영 편차가 발생합니다. |
새 인덱스 | MongoDB Ops Manager가 인덱스를 다시 빌드할 때까지 인덱스 쿼리가 저하됩니다. |
조정은 이러한 결과를 방지합니다. 프라이머리 Ops Manager는 복구 모드를 종료하기 전에 모든 에이전트를 최신 구성으로 일치시키고 온디맨드 스냅샷을 큐에 추가하여 일관된 백업 점을 제공합니다.
복원된 MongoDB Ops Manager 유효성 검사
복원된 프라이머리 MongoDB Ops Manager가 정상인지 확인합니다.
MongoDB 에이전트가 다시 연결되고 정상적인 상태로 보고되는지 확인합니다.
managed 배포서버에 대한 자동화, 백업 및 모니터링이 다시 시작되는지 확인합니다.
프라이머리 MongoDB Ops Manager가 복원 모드를 종료했는지 확인합니다. 복원 모드 상태를 확인하려면
Project Read Only역할을 가진 사용자로 다음 엔드포인트에GET요청을 보냅니다. 응답에는 프로젝트의 현재 상태, trigger 원인 및 타임스탬프가 표시됩니다.GET /api/public/v1.0/groups/{PROJECT-ID}/restorationMode
조정 중단에서 복구
복원 모드에 있는 동안 프라이머리 MongoDB Ops Manager가 다시 시작되면 다음 MongoDB Agent 폴에서 재조정을 트리거합니다. 다시 시작하는 경우 별도의 조치를 취할 필요가 없습니다.
에이전트에 액세스할 수 없는 등의 이유로 조정이 완료되지 않을 수 있습니다. 이런 경우 역할을 Project Owner 가진 사용자로 다음 API 엔드포인트 중 하나를 사용하세요.
재정산을 다시 시도하려면 다음 엔드포인트로
POST요청을 보냅니다. 재시도를 하면 재정산 실패 카운터가 초기화되고 복원 모드를 종료하지 않고 재정산이 다시 실행됩니다.POST /api/public/v1.0/groups/{PROJECT-ID}/restorationMode/retry 프라이머리 MongoDB Ops Manager가 복원 모드를 종료하고 복원된 구성을 승인하도록 강제하려면 다음 엔드포인트로
DELETE요청을 보냅십시오.DELETE /api/public/v1.0/groups/{PROJECT-ID}/restorationMode
경고
프라이머리 MongoDB Ops Manager가 복원 모드를 강제로 종료되면 복원된 구성을 승인하고 이후 에이전트 구성을 화해하지 않습니다. 화해가 완료되지 않을 경우에만 이 엔드포인트를 사용합니다. 강제 종료 후 프라이머리 MongoDB Ops Manager가 프로젝트의 모든 에이전트에 복원된 구성을 제공하고 모든 에이전트가 이에 대해 일치할 때까지 복원 모드에 다시 진입하지 않습니다.
복원된 Ops Manager로 인수인계
이 패턴은 프라이머리 MongoDB Ops Manager를 제자리에서 복원합니다. 세컨더리 MongoDB Ops Manager를 프라이머리 MongoDB Ops Manager를 대체하도록 승격하지 않습니다.
복원된 프라이머리 MongoDB Ops Manager를 검증한 후 인수를 완료합니다.
URL to Access Ops Manager설정 및 모든 DNS 기록을 업데이트하여 복원된 프라이머리 MongoDB Ops Manager를 가리킵니다.MongoDB 에이전트가 복원된 프라이머리 MongoDB Ops Manager에 연결되는지 확인합니다. 에이전트의 구성에서
mmsGroupId와mmsApiKey이 복원된 프로젝트 기록과 일치하면 재등록 없이 재연결됩니다.
운영 지침
다음 예시를 사용하여 시간이 지남에 따라 이 패턴을 운영하고 유효성을 검증합니다.
백업 및 복원 경로 테스트
테스트되지 않은 복원은 운영 위험입니다. 이 백업 및 복원 경로를 정기적으로 테스트합니다. 다음 런북은 선택 지침이 아니라 필수 사항으로 간주합니다.
예정에 따라 테스트 복원을 수행합니다. 백업 데이터베이스를 산드박스 MongoDB Ops Manager로 복원하고 시작되고 조정되는지 확인합니다.
스냅샷이 예정대로 표시되고 시점 복구 창이 연속적으로 유지되는지 확인합니다.
백업 및 복원 오류에 대해 프라이머리 MongoDB Ops Manager 및 세컨더리 MongoDB Ops Manager 로그를 검토합니다.
세컨더리 MongoDB Ops Manager 모니터링
세컨더리 MongoDB Ops Manager와 이가 백업하는 데이터베이스 백업을 모니터링합니다.
MongoDB Ops Manager 백업 경고를 사용하여 데이터베이스 백업의 누락되거나 실패한 스냅샷을 주시합니다.
시점 복구 창이 연속성을 유지하고 계속 진행됩니다.
세컨더리 MongoDB Ops Manager의 애플리케이션 데이터베이스와 백업 디먼의 상태를 모니터링합니다.
장애 시나리오
다음 표에서는 이 패턴이 일반적인 실패 시나리오에서 작동하는 방식을 설명합니다.
Scenario | 영향 | 복구 |
|---|---|---|
세컨더리 Ops Manager를 일시적으로 사용할 수 없습니다. | 새 백업 및 복원이 일시 중지됩니다. 프라이머리 MongoDB Ops Manager와 모든 managed 에이전트는 계속 실행됩니다. | 세컨더리 MongoDB Ops Manager를 복원합니다. 백업 에이전트는 자동으로 다시 시작됩니다. |
복원 후 세컨더리 MongoDB Ops Manager가 실패합니다. | 없음. 애플리케이션 데이터베이스를 복원한 후, 프라이머리 MongoDB Ops Manager가 복원 모드에 진입하여 세컨더리 MongoDB Ops Manager 없이 조정합니다. | 조치 필요 없음. |
MongoDB Ops Manager 인스턴스 두 개 모두 손실 | 프라이머리 MongoDB Ops Manager의 애플리케이션 데이터베이스에 대한 시점 복구는 사용할 수 없습니다. | 세컨더리 MongoDB Ops Manager를 다시 빌드하고 애플리케이션 데이터베이스를 다시 가져오거나 프라이머리 MongoDB Ops Manager를 다시 빌드하고 클러스터를 수동으로 다시 가져오십시오. |
성능, 저장 및 비용 고려 사항
전용 세컨더리 MongoDB Ops Manager를 실행할 때 다음 사항을 고려하세요.
세컨더리 MongoDB Ops Manager는 생산 프라이머리 MongoDB Ops Manager보다 훔씬 작게 사이징합니다. 백업 및 복원을 위한 프라이머리 MongoDB Ops Manager의 백업 데이터베이스만 관리하며 MongoDB 클러스터는 관리하지 않습니다.
데이터베이스 백업의 스냅샷 저장 용량을 스냅샷 예정 및 보유 정책에 따라 계획합니다.
전용 세컨더리 MongoDB Ops Manager를 실행하는 데 필요한 예비 인프라스트럭처 및 운영 비용을 고려합니다.