Docs Menu
Docs Home
/
MongoDB Ops Manager
/

FAQ: 백업 및 복원

이 페이지의 내용

이 FAQ는 Ops Manager에 대한 일반적인 FAQ와 데이터베이스 및 collection을 백업 및 복원하는 방법에 대한 답변을 제공합니다.

MongoDB Agent 의 도입과 FCV4.2 인 MongoDB 4.2 의 새로운 백업 프로세스 로 인해 이러한 답변 중 일부가 변경되었습니다. 해당 답변에는 이러한 새로운 기능이 기존 답변에 영향 을 설명하는 경고가 포함되어 있습니다.

Ops Manager 릴리스 시리즈
1.6 ~ 1.8
2.0에서 3.2
3.4
3.6
4.0
4.2

최소 MongoDB 2.4 버전

2.4.3

2.4.3

2.4.3

2.4.0 [1]

최소 MongoDB 2.6 버전

2.6.0

2.6.0

2.6.0

2.6.0

2.6.0

2.6.0 [2]

최소 MongoDB 3.0 버전

3.0.0

3.0.0

3.0.0

3.0.0

3.0.0

3.0.0 [2]

최소 MongoDB 3.2 버전

3.2.0

3.2.0

3.2.0

3.2.0

3.2.0

최소 MongoDB 3.4 버전

3.4.0

3.4.0

3.4.0

3.4.0

최소 MongoDB 3.6 버전

3.6.0

3.6.0

3.6.0

최소 MongoDB 4.0 버전

4.0.0

4.0.0

최소 MongoDB 4.2 버전

4.2.0

[1] 모니터링 전용
[2](1, 2) 모니터링 및 백업 전용

인증이 활성화된 MongoDB 인스턴스를 백업하는 경우, MongoDB Agent에는 MongoDB Agent 백업 기능에 대해 설명된 권한이 필요합니다.

다음도 참조하세요.

Ops Manager는 다음 변환을 사용하여 스냅샷 크기를 측정하고 처리된 oplog 데이터의 양을 측정합니다.

  • 1MB = 1024 2 바이트(1MiB)

  • 1GB = 1024 3 바이트(1GiB)

  • 1 TB = 1024 4 바이트(1TiB)

  • MongoDB 4.2 이상의 경우 데이터베이스에 대한 백업 고려 사항을 참조하세요.

  • FCV 및 이전 데이터베이스가 있는 MongoDB 의 경우 백업은 독립형 배포를 지원 하지 않습니다. 4.0 백업은 복제본 세트와 샤딩된 클러스터를 완벽하게 지원 합니다.

MongoDB Ops Manager 는 oplog 의 데이터를 복사하여 특정 시점 복구를 통한 지속적인 백업 을 제공합니다. MongoDB Ops Manager 는 독립형 호스트에는 oplog 가 없기 때문에 백업 을 지원 하지 않습니다. 단일 mongod 인스턴스 로 백업 을 지원 하려면 1명의 멤버로 구성된 복제본 세트 를 실행 수 있습니다.

다음도 참조하세요.

백업 기능에 대해 알아보려면 백업 프로세스를 참조하세요.

참고

이 답변 은 FCV 4.0 이하로 MongoDB 를 실행 하는 데이터베이스에만 적용됩니다.

백업 기능은 일반적으로 프로덕션 MongoDB 배포에 미치는 영향이 미미합니다. 이 영향은 복제본 세트 에 새 세컨더리 를 추가하는 것과 유사하게 수행됩니다.

기본값 에이전트 는 복제본 세트 의 세컨더리 멤버에 대해 백업에서 가장 리소스 를 많이 사용하는 작업인 초기 동기화 를 수행하여 영향 을 제한합니다. 선택적으로 백업 에이전트 를 구성하여 복제본 세트의 프라이머리 에 대해 초기 동기화 를 수행할 수 있지만, 이렇게 하면 초기 동기화 작업의 영향 이 커집니다.

복제본 세트에서 수행되는 대부분의 작업은 oplog를 통해 복제되므로 백업 프로세스에 의해 캡처됩니다. 그러나 일부 작업은 복제 되지 않은 변경을 수행합니다. 이러한 작업의 경우 변경 사항을 포함하려면 현재 복제본 세트에서 Ops Manager를 다시 동기화 해야 합니다 .

다음 작업은 복제되지 않으므로 다시 동기화해야 합니다.

  • 데이터 디렉토리 에서 데이터 파일을 삭제하여 데이터베이스 의 이름을 바꾸거나 데이터베이스를 삭제합니다. 또는 의 db.dropDatabase() 와 같이 MongoDB 가 복제할 작업을 사용하여 데이터베이스를 제거 mongosh 합니다.

  • 인스턴스 가 독립형으로 실행 되는 동안 데이터를 변경하는 경우.

  • 롤링 인덱스 빌드.

  • compact 또는 repairDatabase 를 사용하여 상당한 양의 공간을 확보합니다.

    재동기화는 compact 또는 repairDatabase 작업 후에 꼭 필요한 것은 아니지만 데이터의 MongoDB Ops Manager 복사본 크기가 조정되므로 복원이 빨라집니다.

백업 역량 이 백업이 활성화된 MongoDB Agent 로 이동되었습니다. 이는 개별 백업 에이전트 를 대체합니다. 이 정보는 레거시 백업 에이전트 고유의 문제를 다룹니다. 이 모든 정보는 FCV 이하 실행 하는 MongoDB 데이터베이스에 4.0 적용됩니다.

다음을 수행하는 호스트에서 백업 에이전트를 실행합니다.

  • MongoDB 인스턴스와는 별개입니다. 이렇게 하면 시스템 리소스 경합을 방지할 수 있습니다.

  • MongoDB 인스턴스에 연결할 수 있습니다. 에이전트와 MongoDB 호스트 간의 연결에 대한 네트워크 설정을 확인합니다. 필요한 포트 목록은 에이전트용 포트 열기를 참조하세요.

  • 플랫폼 요구 사항보다 최소 2개의 CPU 코어와 3GB의 RAM이 있어야 합니다. 백업 에이전트는 백업 작업을 실행할 때마다 호스트 성능에 더 많은 영향을 미칩니다.

백업 에이전트 및 모니터링이 단일 시스템 또는 호스트에서 실행되는 것을 방해하는 기술적 제한은 없습니다. 그러나 두 에이전트 모두 리소스 요구 사항이 있으며, 단일 시스템에서 둘 다 실행하면 Ops Manager에서 배포를 지원하는 이러한 에이전트의 기능에 영향을 미칠 수 있습니다.

백업 에이전트 에 필요한 리소스는 새 oplog 항목의 속도와 크기(즉, 생성된 총 oplog 기가바이트/시간)에 따라 달라집니다. 모니터링에 필요한 리소스는 모니터링되는 mongod 인스턴스의 수와 mongod 인스턴스에서 제공하는 총 데이터베이스 수에 따라 달라집니다.

고가용성을 위해 여러 백업 에이전트를 실행할 수 있습니다. 이 경우 백업 에이전트는 다른 호스트에서 실행되어야 합니다.

여러 백업 에이전트를 실행하는 경우 프로젝트당 하나의 에이전트만 프라이머리 에이전트 가 됩니다. 프라이머리 에이전트는 백업을 수행합니다. 나머지 에이전트는 상태를 대기로 기록하고 Ops Manager에게 프라이머리가 되어야 하는지 여부를 주기적으로 묻는 것을 제외하고는 완전히 유휴 상태입니다.

백업 에이전트 는 체크포인트 라는 작은 토큰을 정기적으로 소스 데이터베이스 의 oplog 에 기록합니다. 이러한 토큰은 백업에 하트비트를 제공하며 소스 배포서버 에는 영향을 주지 않습니다. 각 토큰은 100 바이트 미만입니다.

초기 백업 동기화의 영향은 새 보조 복제본 세트 구성원을 동기화하는 것과 유사해야 합니다. 백업 에이전트는 활동을 제한하지 않고 가능한 한 빨리 동기화를 수행하려고 시도합니다.

참고

네임스페이스 필터링은 Ops Manager 버전 6.0.8 이상에서만 지원됩니다. MongoDB deployment의 featureCompatibilityVersion 값이 4.0 이하이거나 6.0.1 이상이어야 합니다.

Ops Manager는 백업할 collection 또는 데이터베이스를 지정할 수 있는 네임스페이스 필터 를 제공합니다.

필터를 편집하려면 백업 설정 편집 을 참조하세요. 네임스페이스 필터 를 변경하면 재동기화가 필요할 수 있습니다. 이 경우 Ops Manager가 재동기화를 처리합니다.

작업이 백업 디먼에 바인딩되지 않는 가장 일반적인 이유는 데몬에 백업된 복제본 세트의 로컬 복사본을 위한 공간이 없기 때문입니다.

백업 작업 을 바인딩할 수 있도록 용량 을 늘리려면 다음을 수행합니다.

백업 로그의 applyOps 명령에 지속적인 오류가 발생하면 데몬의 공간이 부족했을 수 있습니다 .

지속적인 작업을 지원 하기 위해 데몬 의 공간을 늘리려면 다음을 수행합니다.

Ops Manager는 새 배포를 시드하는 데 사용할 수 있는 데이터 파일 사본을 생성합니다.

중요

MongoDB MongoDB Ops Manager 4.2.13 Ops Manager 이상은 FCV 이상에서 이 기능 을 4.2 지원합니다.

trigger을 할 때 Ops Manager는 이 스냅샷에 대한 링크를 생성합니다. 클릭하면 Ops Manager가 스냅샷 저장소에서 청크를 검색하여 대상 호스트로 스트리밍합니다.

그런 다음 해당 호스트에서 실행 중인 MongoDB 백업 복원 유틸리티는 oplog 항목을 다운로드하고 적용하여 지정된 시점에 도달합니다.

지정된 특정 시점 복원을 제공하는 Ops Manager의 기능은 스냅샷의 보존 정책과 구성된 특정 시점 창에 따라 달라집니다.

보존 정책 및 특정 시점 창에 대해 자세히 알아보려면 스냅샷 일정 및 보존 정책 편집을 참조하세요.

아니요. Ops Manager는 6시간보다 더 빈번한 스냅샷 일정을 지원하지 않습니다. 자세한 내용은 스냅샷 빈도 및 보존 정책을 참조하세요.

예. 백업된 배포의 Edit Snapshot Schedule 메뉴 옵션을 통해 일정을 변경할 수 있습니다. 관리자는 API의 snapshotSchedule 리소스 를 통해 스냅샷 빈도와 보존 정책 을 변경할 수 있습니다.

Ops Manager는 Ops Manager 호스트에서 모든 백업을 압축된 형식으로 인프라로 전송합니다.

또한, 특정 시점 복원은 호스트가 요청된 백업 점으로 롤포워드하기 위해 수신된 스냅샷에 적용해야 하는 oplog 항목의 양에 따라 달라집니다.

Backup은 기본 손상 검사를 수행하고 구성 요소(예: 에이전트)가 다운되거나 고장난 경우 경고를 제공하지만 명시적인 데이터 유효성 검사를 수행하지는 않습니다. Ops Manager가 손상을 감지하면 잘못 판단하여 현재 백업을 무효화하고 경고를 보냅니다.

Ops Manager를 통해 복원을 요청한 다음 복원할 스냅샷과 Ops Manager의 복원 제공 방법을 선택할 수 있습니다. 모든 복원에는 2단계 인증이 필요합니다. SMS를 설정한 경우 Ops Manager가 SMS를 통해 권한 부여 코드를 전송합니다. 복원 프로세스를 시작하려면 백업 인터페이스에 권한 부여 코드를 입력해야 합니다.

참고

인도에서는 Google Authenticator를 사용하여 2단계 인증을 수행합니다. Google Authenticator는 인도 휴대폰 번호로 SMS 문자 메시지를 보내는 인증보다 더 안정적입니다(예: 국가 코드 91).

Ops Manager는 MongoDB 데이터 파일의 tar.gz 아카이브로 복원을 제공합니다.

복원에 대해 자세히 알아보려면 MongoDB 배포 복원을 참조하세요.

중요

MongoDB FCV 이상을 실행 배포서버의 4.2 경우 롤백은 의 백업 데이터에 영향을 주지 MongoDB Ops Manager 않습니다. FCV 4.2 부터 MongoDB Ops Manager 는 과반수 커밋 점 까지의 타임스탬프가 있는 스냅샷만 유지합니다.

MongoDB 배포에서 롤백 이 발생하는 경우 MongoDB Ops Manager는 백업된 데이터도 롤백합니다.

MongoDB Ops Manager는 테일 커서 가 쓰기 작업의 타임스탬프 또는 해시에서 불일치를 발견하면 롤백을 감지합니다. MongoDB Ops Manager는 롤백 상태로 전환되고 복제본 세트의 프라이머리 에서 세 지점을 테스트하여 oplog 기록에서 공통된 지점을 찾습니다. MongoDB Ops Manager 롤백은 MongoDB 공통점이 반드시 가장 최근의 공통점일 필요는 없다는 점에서 세컨더리 롤백과 다릅니다.

Ops Manager가 공통점을 찾으면 서비스는 해당 점을 초과하는 oplog 항목과 스냅샷을 무효화하고 공통점 이전의 가장 최근 스냅샷으로 롤백합니다. 그런 다음 Ops Manager는 정상적인 백업 작업을 재개합니다.

Ops Manager가 공통점을 찾을 수 없는 경우 다시 동기화 해야 합니다.

중요

이 기능 은 4.2 FCV 를 사용하는 MongoDB 와 호환되지 4.2 않습니다.

백업 에이전트의 테일 커서 가 배포서버의 oplog 를 따라잡을 수 없는 경우 백업을 다시 동기화해야 합니다.

이 시나리오는 다음과 같은 경우에 발생할 수 있습니다.

  • 애플리케이션은 주기적으로 많은 데이터를 생성하여 Ops Manager가 소비할 수 있는 속도보다 빠르게 데이터가 oplog에 기록되는 점까지 프라이머리의 oplog window를 축소합니다.

  • 백업 에이전트가 프로비저닝이 부족하거나 과도하게 사용되는 머신에서 실행 중이며 oplog 활동을 따라잡을 수 없는 경우입니다.

  • 백업 에이전트 가 oplog 크기가 허용하는 것보다 긴 시간 동안 다운된 경우. 유지 관리 등을 위해 에이전트를 중단한 경우 적시에 다시 시작하세요. oplog 크기에 대한 자세한 oplog 내용은 MongoDB 매뉴얼의 복제본 세트 를 참조하세요.

  • 모든 복제본 세트 데이터를 삭제하고 동일한 이름의 새 복제본 세트를 배포하는 경우, 배포가 정기적으로 해체되고 재구축되는 테스트 환경에서 발생할 수 있습니다.

  • 롤백이 있고 Ops Manager가 oplog에서 공통점을 찾을 수 없는 경우.

  • oplog 이벤트가 복제본 세트의 백업에 존재하지 않는 문서를 업데이트하려고 하는 경우, 프라이머리와 관련하여 데이터가 일치하지 않는 세컨더리에서 동기화하는 경우 발생할 수 있습니다.

  • 롤링 방식으로 인덱스를 생성하는 경우.

돌아가기

자동화

이 페이지의 내용