Docs Menu
Docs Home
/
MongoDB Cloud Manager
/ /

스냅샷에서 샤딩된 클러스터 복원

이 페이지의 내용

  • 고려 사항
  • 스냅샷 복원

스냅샷에서 cluster를 복원하면 Cloud Manager가 선택한 점에 대한 복원 파일을 제공합니다.

복원 프로세스에 대해 알아보려면 복원 개요를 참조하세요.

BSON 사양 BSON 바이너리 데이터 유형(BinData)의 기본값 하위 유형을 2 에서 0 로 변경했습니다. 스냅샷 에 저장된 일부 바이너리 데이터는 BinData 하위 유형 2 일 수 있습니다. 백업은 BinData 하위 유형 2 의 스냅샷 데이터를 자동으로 감지하고 BinData 하위 유형 0 로 변환합니다. 애플리케이션 코드에 BinData 하위 유형 2 가 예상되는 경우 BinData 하위 유형 0 과 함께 작동하도록 애플리케이션 코드를 업데이트 해야 합니다.

다음도 참조하세요.

BSON 사양 에 대한 참고 사항 이 변경의 구체적인 내용을 설명합니다.

백업 복원 파일에는 restoreInfo.txt 이라는 메타데이터 파일이 포함되어 있습니다. 이 파일은 스냅샷을 생성할 때 데이터베이스에서 사용된 옵션을 캡처합니다. 데이터베이스를 복원한 후에는 나열된 옵션을 사용하여 데이터베이스를 실행해야 합니다. 이 파일에는 다음이 포함됩니다.

  • groupName

  • 복제본 세트 이름

  • 클러스터 ID (해당되는 경우)

  • 스냅샷 타임스탬프 (UTC의 타임스탬프)

  • 타임스탬프 복원 (UTC의 BSON 타임스탬프로)

  • 마지막 oplog 적용 되었습니다(UTC에서 BSON 타임스탬프로).

  • MongoDB 버전

  • storage engine 유형

  • mongod 스냅샷을 생성할 때 데이터베이스에 사용된 시작 옵션

Cloud Manager 는 밸런서 가 활성화된 상태에서 생성된 클러스터 스냅샷 옆에 경고를 표시합니다. 이러한 스냅샷 에서 복원 하면 데이터가 손실되거나 고아가 될 위험이 실행 . 자세한 내용은 에이전트가 밸런서를 중지할 수 없는 경우의 스냅샷 을 참조하세요.

모든 FCV 데이터베이스는 적절한 백업 고려 사항을 충족해야 합니다.

복원 중에는 MongoDB deployment가 클라이언트 요청을 받지 않도록 해야 합니다. 다음 중 하나를 수행해야 합니다.

  • 새 호스트 이름을 사용하여 새 시스템으로 복원하고 새 배포가 실행되면 애플리케이션 코드를 재구성합니다. 또는

  • 데이터를 복원하는 동안 MongoDB deployment가 클라이언트 요청을 수신 하지 않는지 확인합니다.

Cloud Manager 가 스냅샷 을 자동으로 복원 하도록 하려면 다음을 수행합니다.

1
  1. 이미 표시되어 있지 않은 경우 탐색 모음의 Organizations 메뉴에서 원하는 프로젝트가 포함된 조직을 선택합니다.

  2. 아직 표시되지 않은 경우 탐색 표시줄의 Projects 메뉴에서 원하는 프로젝트를 선택합니다.

  3. 사이드바에서 Continuous Backup를 클릭합니다.

    연속 백업 페이지가 표시됩니다.

2
3
4
  1. 백업을 복원할 지점을 선택합니다.

    복원 유형
    설명
    작업
    Snapshot
    복원할 기존 스냅샷 을 선택합니다.
    Point In Time

    선택한 시간까지의 모든 작업을 포함하지만 포함하지 않는 사용자 지정 스냅샷을 생성합니다. 기본적으로 oplog 스토어는 24시간 분량의 데이터를 저장합니다.

    예를 예시 12:00 을 선택하는 경우 복원 의 마지막 작업은 11:59:59 이하입니다.

    중요: FCV 4.0 에서는 최신 백업 재동기화 이전의 기간을 포함하는 PIT 복원 을 수행할 수 없습니다. 재동기화가 발생하는 조건 은 백업 재동기화를 참조하세요. 이 참고 사항은 FCV 4.2 이상에는 적용 되지 않습니다.

    DateTime 을(를) 선택합니다.
    Oplog Timestamp

    입력 oplog 타임스탬프를 포함하여 해당 시점까지의 모든 작업을 포함하는 사용자 지정 스냅샷을 생성합니다. oplog 타임스탬프에는 두 개의 필드가 포함되어 있습니다.

    Timestamp

    UNIX epoch 이후경과된 시간(초)의 타임스탬프

    Increment
    해당 초에 32비트 서수로 적용되는 작업 순서입니다.

    oplog TimestampIncrement를 입력합니다.

    복제본 세트 에서 local.oplog.rs 에 대한 쿼리를 실행하여 원하는 타임스탬프를 찾습니다.

  2. Next를 클릭합니다.

5
  1. Choose Cluster to Restore to를 클릭합니다.

  2. 다음 필드를 작성합니다.

    필드
    작업
    Project
    스냅샷을 복원 할 프로젝트 를 선택합니다 .
    Cluster to Restore to

    스냅샷 을 복원 할 클러스터 를 선택합니다.

    Cloud Manager는 대상 샤드 cluster를 managed 해야 합니다.

    경고: 자동화는 클러스터 에서 기존 데이터를 모두 제거합니다. 기존 클러스터 의 모든 백업 데이터와 스냅샷을 보존합니다.

  1. Restore를 클릭합니다.

    Cloud Manager는 복원에 필요한 저장 공간의 양을 UI에 표시합니다.

6

중요

AES256-GCM으로 암호화된 스냅샷을 복원한 후 마스터 키 순환

Cloud Manager가 AES256-GCM으로 암호화된 암호화 스냅샷을 복원하는 경우, 복원을 완료한 후마스터 키를 순환시키십시오.

수동 복원 프로세스 에서는 다음을 가정합니다.

경고

자동 복원 을 실행 수 없는 경우에만 스냅샷 을 수동으로 복원합니다. 수동 복원 을 사용해야 한다고 판단되면 MongoDB 문의 에 도움을 요청하세요. 이 섹션에서는 수동 복원 절차의 각 단계에 대한 높은 수준의 개요를 제공합니다.

수동 복원 프로세스 에는 MongoDB 지원의 도움을 받아 다음과 같은 높은 수준의 단계를 수행할 수 있습니다.

  1. 레거시 mongo shell 또는 mongosh를 사용하여 각 복제본 세트 와 구성 서버 복제본 세트(CSRS)에 연결합니다.

  2. (선택 사항). 각 복제본 세트 및 CSRS 의 구성 파일 을 검토합니다. 복원 프로세스 를 완료한 후에는 저장된 구성 파일을 사용하여 복원된 복제본 세트에서 구성을 재구성할 수 있습니다.

  3. 대상 호스트를 준비합니다.

    • 대상 호스트에서 실행 모든 mongod 프로세스를 중지합니다.

    • 복원된 데이터를 저장할 수 있는 충분한 저장 공간을 프로비저닝합니다.

    • 데이터 및 로그를 위한 디렉토리를 준비합니다.

    • 대상 호스트의 저장 및 로그 경로, 복제본 및 샤딩 역할에 대한 구성이 포함된 구성 파일 을 MongoDB Server 디렉토리 에 추가합니다.

  4. CSRS를 복원합니다.

  5. 각 샤드의 복제본 세트 를 복원합니다.

  6. 대상 클러스터 에서 각 mongos 프로세스 를 다시 시작합니다.

  7. 클러스터 에 연결할 수 있는지 확인합니다.

전체 수동 복원 절차는 MongoDB Server 4.2 문서에서 확인할 수 있습니다. MongoDB 4.4 이상 배포의 경우 해당 버전의 매뉴얼을 참조하세요.

Cloud Manager 가 스냅샷 을 자동으로 복원 하도록 하려면 다음을 수행합니다.

1
  1. 이미 표시되어 있지 않은 경우 탐색 모음의 Organizations 메뉴에서 원하는 프로젝트가 포함된 조직을 선택합니다.

  2. 아직 표시되지 않은 경우 탐색 표시줄의 Projects 메뉴에서 원하는 프로젝트를 선택합니다.

  3. 사이드바에서 Continuous Backup를 클릭합니다.

    연속 백업 페이지가 표시됩니다.

2
3
4
  1. 백업을 복원할 지점을 선택합니다.

    복원 유형
    설명
    작업
    Snapshot
    복원할 기존 스냅샷 을 선택합니다.
    Point In Time

    스냅샷 의 복원 시간 목표로 날짜와 시간을 선택할 수 있습니다. 기본값 oplog 스토어는 24 시간 분량의 데이터를 저장합니다.

    예를 예시 12:00 을 선택하는 경우 복원 의 마지막 작업은 11:59:59 이하입니다.

    FCV4.0 이전 버전을 실행하는 샤딩된 클러스터 를 복원하는 경우, 샤딩된 클러스터 에서 PIT 복원 을 수행하려면 클러스터 체크포인트를 활성화 해야 합니다. 날짜 및 시간이 포함된 체크포인트를 사용할 수 없는 경우 Cloud Manager 는 choose another point in time에 요청합니다.

    중요: 최신 백업 재동기화 이전의 기간에 해당하는 PIT 복원 은 수행할 수 없습니다. 재동기화가 발생하는 조건 은 백업 재동기화를 참조하세요.

    DateTime 을(를) 선택합니다.
  2. Next를 클릭합니다.

  3. 이하에서 실행되는 샤딩된 클러스터 를 복원하고 FCV 4.0 를 선택한 경우:Point In Time

    1. 선택한 시간에 가장 가까운 Checkpoints 목록이 나타납니다.

    2. 점 복원 을 시작하려면 다음을 수행할 수 있습니다.

      • 나열된 체크포인트 중 하나를 선택하거나

      • Choose another point in time 를 클릭하여 체크포인트 목록을 제거 하고 메뉴에서 다른 날짜 및 시간을 선택합니다.

5
  1. Choose Cluster to Restore to를 클릭합니다.

  2. 다음 필드를 작성합니다.

    필드
    작업
    Project
    스냅샷을 복원 할 프로젝트 를 선택합니다 .
    Cluster to Restore to

    스냅샷 을 복원 할 클러스터 를 선택합니다.

    Cloud Manager는 대상 샤드 cluster를 managed 해야 합니다.

    경고: 자동화는 클러스터 에서 기존 데이터를 모두 제거합니다. 기존 클러스터 의 모든 백업 데이터와 스냅샷을 보존합니다.

  1. Restore를 클릭합니다.

    Cloud Manager 는 복원 에 필요한 저장 공간을 콘솔에 표시합니다.

6

중요

AES256-GCM으로 암호화된 스냅샷을 복원한 후 마스터 키 순환

Cloud Manager가 AES256-GCM으로 암호화된 암호화 스냅샷을 복원하는 경우, 복원을 완료한 후마스터 키를 순환시키십시오.

수동 복원 프로세스 에서는 다음을 가정합니다.

경고

자동 복원 을 실행 수 없는 경우에만 스냅샷 을 수동으로 복원합니다. 수동 복원 을 사용해야 한다고 판단되면 MongoDB 문의 에 도움을 요청하세요. 이 섹션에서는 수동 복원 절차의 각 단계에 대한 높은 수준의 개요를 제공합니다.

수동 복원 프로세스 에는 MongoDB 지원의 도움을 받아 다음과 같은 높은 수준의 단계를 수행할 수 있습니다.

  1. 레거시 mongo shell 또는 mongosh를 사용하여 각 복제본 세트 와 구성 서버 복제본 세트(CSRS)에 연결합니다.

  2. (선택 사항). 각 복제본 세트 및 CSRS 의 구성 파일 을 검토합니다. 복원 프로세스 를 완료한 후에는 저장된 구성 파일을 사용하여 복원된 복제본 세트에서 구성을 재구성할 수 있습니다.

  3. 대상 호스트를 준비합니다.

    • 대상 호스트에서 실행 모든 mongod 프로세스를 중지합니다.

    • 복원된 데이터를 저장할 수 있는 충분한 저장 공간을 프로비저닝합니다.

    • 데이터 및 로그를 위한 디렉토리를 준비합니다.

    • 대상 호스트의 저장 및 로그 경로, 복제본 및 샤딩 역할에 대한 구성이 포함된 구성 파일 을 MongoDB Server 디렉토리 에 추가합니다.

  4. CSRS를 복원합니다.

  5. 각 샤드의 복제본 세트 를 복원합니다.

  6. 대상 클러스터 에서 각 mongos 프로세스 를 다시 시작합니다.

  7. 클러스터 에 연결할 수 있는지 확인합니다.

전체 수동 복원 절차는 MongoDB Server 설명서에서 확인할 수 있습니다.

돌아가기

개요

이 페이지의 내용