재해 복구(DR)는 자동 페일오버 도움이 되지 않을 때 수동 절차를 사용하여 배포서버 복구하는 회복 탄력성 전략입니다. 인프라 장애에 대한 자동 자가 복구를 제공하는 고가용성과 달리 재해 복구에서는 백업에서 복원 위해 사람의 개입이 필요합니다.
참고
MongoDB Atlas 공동 책임 모델은 안전하고 복원력이 뛰어난 데이터 환경을 유지 관리하는 데 있어 MongoDB 와 MongoDB 고객의 보완 의무를 정의합니다. 이 프레임워크 에서 MongoDB 기본 플랫폼의 보안 및 운영 무결성을 관리하고 고객은 특정 배포의 구성, 관리 및 데이터 정책을 책임집니다. 보안 및 운영 우수성에 대한 소유권에 대한 자세한 분석은 공유 책임 모델을 참조하세요.
재해 복구를 사용해야 하는 경우
중요
가능하면 고가용성 선호합니다. 고가용성 실현 가능하지 않은 경우에만 재해 복구를 프라이머리 회복 탄력성 전략으로 사용합니다.
재해 복구는 다음과 같은 상황에서 프라이머리 회복 탄력성 전략으로 적합합니다.
- 지리적 제약 조건
- 가용영역이 충분한 여러 리전에 배포 수 없습니다. 예시 들어 캐나다에 배포 해야 하는 경우 2 리전만 사용할 수 있으므로 자동 페일오버 쿼럼 요구 사항이 적용되지 않습니다.
- 비용 최적화
- 예산에 따라 인프라 비용을 최소화해야 합니다. 멀티 리전 또는 멀티 클라우드 고가용성 배포서버는 백업이 포함된 단일 리전 배포서버보다 비용 더 많이 듭니다.
- 수동 복구 허용 범위
- 사용자의 애플리케이션 수동 개입 및 백업 복원에 필요한 시간(초가 아닌 분에서 몇 시간의 RTO)을 허용할 수 있습니다.
참고
고가용성 사용하더라도 데이터 손상이나 실수로 삭제되는 등 자동 페일오버 로 주소 수 없는 시나리오의 경우 재해 복구 절차를 통해 도움을 받을 수 있습니다. 두 접근 방식을 결합하는 방법에 대해 자세히 학습하려면 Atlas 비즈니스 연속성 계획을 위한 지침을 참조하세요.
백업이 재해 복구를 지원하는 방법
백업은 재해 복구를 구현하기 위한 프라이머리 도구입니다. Atlas 자동 페일오버 도움이 되지 않을 때 수동 복구가 활성화 완전 관리형 사용자 지정 가능한 백업을 제공합니다.
클라우드 백업
클러스터 에 대해 클라우드 백업을 활성화 Atlas cloud 제공자의 네이티브 스냅샷 기능을 사용하여 기본값 으로 변경되지 않는 증분 백업을 생성하며 복원 시간이 빠릅니다.
DR을 지원하는 방법:
RPO 요구 사항 을 충족하도록 스냅샷 빈도(시간별, 매일, 매주, 매월, 매년)를 구성합니다.
컴플라이언스 및 복구 요구 사항을 충족하도록 스냅샷 보존 기간을 설정합니다.
스냅샷을 복원하여 데이터 손상 또는 삭제를 복구합니다.
사용 시기: 스냅샷 빈도와 동일한 데이터 손실을 허용할 수 있는 표준 재해 복구 시나리오입니다. 예시 들어, 시간별 스냅샷을 사용하면 최대 1 시간의 데이터 손실이 발생할 수 있습니다.
지속적인 클라우드 백업을 통한 특정 시점 복구
클라우드 백업과 함께 연속 클라우드 백업을 활성화 Atlas 클라우드 백업 스냅샷과 함께 oplog 데이터를 저장하여 Atlas 구성 가능한 특정 시점(PIT) 복원 창 내의 특정 시점으로 클러스터 복원 수 있도록 합니다.
DR을 지원하는 방법:
구성 가능한 PIT 복원 창 내에서 원하는 시점으로 복원합니다. Atlas 복원 창 동안 oplog 데이터를 유지하고, 가장 가까운 클라우드 백업 스냅샷 위에 oplog 항목을 재생하여 지정한 정확한 순간으로 복원 .
1 분까지 낮은 RPO를 달성하십시오.
데이터 손상 또는 삭제가 발생하기 전의 순간을 정확하게 타겟팅합니다.
사용 시기: 데이터 손실을 최소화하거나(낮은 RPO) 특정 타임스탬프로의 정확한 복구가 필요한 경우.
멀티 리전 스냅샷 배포
스냅샷 복사 정책으로 클라우드 백업을 활성화하면 스냅샷 및 oplog의 복사본을 다른 지역의 추가 클라우드 공급자 리전에 자동으로 배포하도록 Atlas 구성할 수 있습니다.
DR을 지원하는 방법:
지리적으로 분산된 백업에 대한 컴플라이언스 요구 사항을 충족합니다.
프라이머리 리전 완전히 실패하더라도 백업에 계속 액세스할 수 있도록 보장합니다.
멀티 리전 클러스터 의 경우 스냅샷 복사 정책에서 Automatically Sync Copy Regions with Cluster Regions 옵션을 활성화하면 Atlas 가 클러스터 배포된 모든 리전에 스냅샷을 자동으로 배포할 수 있으며, 리전을 추가하거나 제거 때 스냅샷 복사 정책을 동기화 상태로 유지합니다. 이를 통해 Atlas 더 빠른 직접 연결 복원을 사용하여 리전 장애 후 더 느린 리전 간 스트리밍 복원 대신 로컬 스냅샷 복사본을 사용하여 클러스터 리전을 복원 할 수 있습니다.
사용 시기: HA 구성을 초과하는 완전한 리전 손실 또는 제공자 중단으로부터 보호해야 하는 경우.
백업 전략 RTO/RPO 절충안
백업 전략은 자동 페일오버 주소 수 없는 데이터 무결성 장애(예: 데이터 손상, 우발적 삭제, 전체 배포서버 손실)로부터 보호합니다. 모든 백업 전략에는 일부 데이터 손실(RPO > 0)과 더 긴 복구 시간(분에서 몇 시간 단위의 RTO)이 포함됩니다. 손실될 수 있는 데이터의 양과 각 접근 방식의 운영 복잡성에 따라 장단점이 있습니다.
백업 전략 | 주요 사용 사례 | 일반 RTO | RPO | 운영 고려 사항 | 비용 고려 사항 |
|---|---|---|---|---|---|
주기적인 스냅샷 | 데이터 손상, 실수로 삭제, 완전한 배포서버 손실. | 분에서 시간까지 | > 0 (최대 스냅샷 간격). | 예정/보존을 정의합니다. 정기적으로 복원 절차를 테스트합니다. | 스토리지는 빈도와 유지율에 따라 증가합니다. 복원에는 컴퓨팅/이그레스 비용이 발생합니다. |
특정 시점 복원 통한 연속 백업 | '잘못된' 타임스탬프가 알려진 데이터 손상 또는 삭제입니다. | 분에서 시간까지 | > 0 (0에 가까움, 초 단위까지 감소). | 특정 시점(PIT) 복원 기간을 구성합니다. 장애를 모니터링합니다. | 스냅샷만 사용할 때보 저장 및 백업 비용 더 높습니다. |
멀티 리전 스냅샷 배포 | 로컬 백업에도 영향을 미치는 리전 또는 제공자 손실입니다. | 몇 분에서 몇 시간까지 소요됩니다(리전 간 속도는 더 느릴 수 있음). | > 0 ( 스냅샷 예정 에 연결). | 리전 간 복원을 계획하고 테스트합니다. 보존 정책을 관리합니다. | 여러 리전에 추가 저장 . 복원 시 리전 간 이그레스 . |
모든 배포서버 패러다임 권장사항
다음 권장사항은 모든 배포서버 패러다임에 적용됩니다.
이 섹션에서는 다음과 같은 재해 복구 절차에 대해 설명합니다.
단일 노드 중단
부분적인 지역 장애로 인해 복제본 세트의 단일 노드가 실패하더라도 권장사항을 따랐다면 배포서버를 계속해서 사용할 수 있습니다. 세컨더리 노드에서 읽는 경우 프로비저닝되지 않은 클러스터의 부하 증가로 인해 세컨더리 노드에 장애가 발생할 경우 성능이 저하되거나 중단될 가능성이 있습니다.
Atlas UI의 프라이머리 페일오버 테스트 기능 또는 페일오버 테스트 Atlas 관리 API 엔드포인트를 사용하여 Atlas 에서 프라이머리 노드 중단을 테스트할 수 있습니다.
리전 중단
리전 장애 이벤트 멀티 리전 클러스터가 자동으로 투표 실시하고 필요한 경우 새로운 프라이머리 노드 식별합니다. 이러한 토폴로지 변경 사항은 애플리케이션 에 자동으로 전달되어 필요한 수정 조치 취할 수 있습니다. 리전 장애 이벤트 애플리케이션 가동 시간을 유지하려면 애플리케이션 멀티 리전 토폴로지 로 배포되어야 합니다. 이 요구 사항은 애플리케이션 이 통합될 수 있는 모든 타사 서비스를 포함하도록 확장됩니다. 자세한 학습 은 멀티 리전 배포 패러다임을 참조하세요.
단일 리전 중단 또는 다중 리전 중단으로 인해 클러스터 상태 저하되는 경우 다음 단계를 따르세요.
식별한 지역에 노드 추가
중단 원인의 영향을 받을 가능성이 낮은 리전 전체에 걸쳐 정상 상태 에 필요한 노드 수를 추가합니다.
운영 중단 시 지역 또는 노드를 추가하여 복제본 세트를 재구성하려면 지역 장애 시 복제본 세트 재구성을 참조하세요.
Atlas UI의 중단 시뮬레이션 기능 또는 중단 시뮬레이션 시작하기 Atlas 관리 API 엔드포인트를 사용하여 Atlas 에서 리전 중단을 테스트할 수 있습니다.
클라우드 공급자 장애
멀티 클라우드 클러스터를 사용하면 클라우드 공급자 전체에서 투표 선택 가능 노드를 선택하여 고가용성을 유지할 수 있습니다. 프라이머리 노드 배포된 제공자 사용할 수 없게 되는 경우, Atlas 지속적인 운영을 보장하기 위해 자동으로 새로운 프라이머리 노드를 선택합니다. 예시 를 들어, AWS, Google Cloud 및 Microsoft Azure 에 투표 선택 가능 노드를 만들어 한 클라우드 공급자 에 장애가 발생하는 경우 별도의 제공자 의 투표 선택 가능 노드가 자동으로 클러스터의 프라이머리 노드 역할을 맡도록 할 수 있습니다. 자세한 내용은 멀티 클라우드 배포서버 패러다임을 참조하세요.
대부분의 멀티 리전 Atlas 클러스터는 단일 리전 장애 시 자동으로 복구됩니다. 자세한 학습 은 Atlas 고가용성 및 멀티 리전 배포서버 패러다임에 대한 지침을 참조하세요. 리전 중단으로 인해 대부분의 노드가 오프라인 상태가 된 경우, 대다수의 노드가 정상 상태가 되려면 얼마나 많은 노드를 추가해야 하는지 결정해야 합니다.
모든 클라우드 공급자가 사용 불가능인 경우 배포를 다시 온라인 상태로 전환하려면 다음 단계를 따릅니다.
새 클러스터 배포 하려는 대체 cloud 제공자 식별합니다.
cloud 제공자 목록 및 정보는 클라우드 제공자를 참조하세요.
백업을 여러 클라우드 공급자에 저장하면 클라우드 공급자에 장애가 발생하면 프라이머리 클라우드 공급자에 저장된 백업을 사용할 수 없게 되므로, 장애가 시작되기 전에 클러스터에서 캡처한 사용 가능한 최신 스냅샷을 찾습니다.
백업 스냅샷을 보는 방법을 알아보려면 M10+ 백업 스냅샷 보기를 참조하세요.
이전 클러스터 에 연결하는 모든 애플리케이션을 새로 생성된 클러스터 로 전환합니다.
새 연결 문자열 찾으려면 클라이언트 라이브러리를 통한 연결을 참조하세요. 새 클라우드 공급자 에 재배포해야 할 가능성이 높으므로 애플리케이션 스택 검토하십시오.
Atlas 중단
Atlas Control Plane과 Atlas UI가 매우 드물게 사용 불가능한 상황에서도 클러스터는 여전히 사용 가능하며 접근할 수 있습니다. 자세한 내용은 플랫폼 Reliability를 참조하세요. 우선순위가 높은 지원 티켓을 열어 추가 조사를 진행하세요.
리소스 용량 문제
디스크 공간, RAM 또는 CPU와 같은 컴퓨팅 리소스 용량 문제는 부실한 계획 또는 예기치 않은 데이터베이스 트래픽으로 인해 발생할 수 있습니다. 이러한 동작은 재해의 결과가 아닐 수 있습니다.
컴퓨팅 리소스가 최대 할당량에 도달하여 재해를 초래할 경우 다음 단계를 따릅니다.
실시간 성능 패널 또는 Atlas 지표 사용하여 최대로 활용되는 계산 리소스 식별합니다.
Atlas UI 에서 리소스 사용률을 보려면 실시간 성능 모니터링을 참조하세요.
Atlas 관리 API 사용하여 지표 보려면 모니터링 및 로그를 참조하세요.
리소스 장애
중요
이는 전체 시스템 다운타임을 줄이기 위한 임시 솔루션입니다. 기본 문제가 해결되면 새로 생성된 클러스터 의 데이터를 원래 클러스터 에 병합하고 모든 애플리케이션이 원래 클러스터 를 가리키 점 .
컴퓨팅 리소스가 실패하여 클러스터를 사용할 수 없게 되면 다음 단계를 따릅니다.
높은 우선순위 지원 티켓
프로덕션 데이터 삭제
프로덕션 데이터는 인적 오류나 데이터베이스 위에 구축된 애플리케이션의 버그로 인해 실수로 삭제될 수 있습니다. 클러스터 자체가 실수로 삭제된 경우 Atlas는 볼륨을 일시적으로 보관할 수 있습니다.
컬렉션이나 데이터베이스의 내용이 삭제된 경우 다음 단계에 따라 데이터를 복원합니다.
컬렉션 또는 데이터베이스 에 데이터가 포함된 경우 현재 상태 의 복사본을 만듭니다.
mongoexport 를 사용하여 사본을 만들 수 있습니다.
데이터 사본을 만든 경우 내보낸 새 데이터를 가져옵니다.
mongoimport를 업서트 모드로 사용하여 데이터를 가져오고 수정 및 추가된 데이터가 컬렉션이나 데이터베이스에 올바르게 반영되도록 할 수 있습니다.
드라이버 장애
드라이버가 실패하면 다음 단계를 따르세요.
데이터 손상
중요
이는 전체 시스템 다운타임을 줄이기 위한 임시 솔루션입니다. 기본 문제가 해결되면 새로 생성된 클러스터 의 데이터를 원래 클러스터 에 병합하고 모든 애플리케이션이 원래 클러스터 를 가리키 점 .
기본 데이터가 손상되면 다음 단계를 따르세요.