MongoDB에서 대용량 데이터 세트를 백업하기 위해 권장되는 방법은 무엇입니까? 10TB 정도의 데이터 크기가 있다고 가정 해 봅시다. 어떻게 백업 하시겠습니까?

숨겨져 있거나 지연된 복제본 세트 노드를 고려하고 있습니다. 지연으로 인해 데이터베이스 전체가 실수로 삭제되는 것을 방지 할 수 있습니다. 이것이 가능한 솔루션이며 조사 할 다른 옵션은 무엇입니까?

감사!

10TB를 백업해야하므로 약간 복잡합니다.

복제본은 적절한 백업을 대체하지 않습니다

지연된 복제본 세트 멤버는 우발적 인 조작에 도움을주는 비교적 쉬운 방법을 제공 할 수 있지만, RAID가 파일 시스템 기반 백업을 대체하지 않는 것처럼 적절한 백업을 대체 할 수는 없습니다.

추천

설정 방식에 따라 크게 다릅니다.

SAN 스냅 샷

10TB에서는 일종의 SAN이 연결되어 있다고 가정합니다. 이러한 환경에서 MongoDB를 백업하는 가장 쉬운 방법은 파일 시스템과 MongoDB 모두에서 저널링을 활성화하고 보조 기능 중 하나의 SAN 볼륨에 대한 스냅 샷을 작성하는 것입니다. 중단되지 않습니다. 이 작업은 일반적으로 몇 초 밖에 걸리지 않지만 복제 oplog 창이 충분한 지 확인하십시오. 그렇지 않으면 보조를 다시 동기화해야 할 수도 있습니다.

mongodump를 사용하지 마십시오

mongodump 사용법에 대해 RolandoMySQLDBA에 동의하지 않아야합니다. 우선, 서버에 잠금을 부과합니다. 비교적 빠른 속도로 해제되지만 숨겨진 노드에서 실행하거나 보조 환경 설정에 대한 읽기 기본 설정이없는 경우에는 잠금 수가 많기 때문에 작업을 방해 할 수 있습니다. 또한 빠르지는 않습니다. 적어도 백업 시간보다 오래 걸릴 것으로 예상됩니다. 참고 : 항상 옵션으로 mongodump를 실행 하십시오.--oplog. 또한 mongodump는 인덱스를 백업하지 않지만 인덱스를 작성하는 조작을 기억하십시오. 이러한 인덱스는 복원하는 동안 다시 작성해야하므로 필요한 시간이 크게 늘어날 수 있습니다. 내 경험에 따르면 데이터베이스를 복원해야 할 경우 최대한 빨리 데이터베이스를 원합니다. mongodump가 10TB 백업에 적합하지 않은 또 다른 이유.

LVM 스냅 샷에 대한 참고 사항

mongod 에서 저널링을 사용하도록 설정 한 경우 실행중인 mongod 인스턴스에서 LVM 스냅 샷을 수행 할 수 있습니다 (제 경험상 FS 수준에서도 사용하도록 설정해도 문제가되지 않습니다). 그러나 LVM 스냅 샷에는 몇 가지 의미가 있습니다. 먼저 백업 작업 중에 변경을 수행 할 수있는 충분한 디스크 공간이 있어야합니다. 그것을 명확히하겠습니다.

시간별 변경 속도가 500GB라고 가정합니다. 그리고 일부 스토리지에 업로드하기 전에 백업이 삐걱 거리게하고 싶습니다. 병렬 bzip2를 사용하는 경우에도 10TB 압축은 완료하는 데 몇 시간이 걸릴 것입니다. 대량 스토리지 처리량이 가장 많기 때문에 제한 요인이되기 때문입니다. 데이터를 2TB로 압축하는 데 2 ​​시간이 걸린다고 가정 해 봅시다. 따라서 이제는 2TB + 2 * 500GB의 여유 디스크 공간이 필요하며 LVM 스냅 샷에는 1TB가 필요합니다. 이를 통해 최소한 파일 시스템을 과도하게 프로비저닝해야 할 필요가 있습니다.30 % 적절한 안전 여유를 원할 경우 스냅 샷 크기와 bzipped 백업 자체에 필요한 공간에 동일한 크기로 원본 파일 시스템의 사용률이 0.8 인 경우 60-70 % (20 %는 20 %)로 쉽게 증가 할 수 있습니다. ). 오버 프로비저닝은 정적 인 것이기 때문에 대부분의 프로덕션 환경에서는 용납 할 수 없습니다 (백업 스크립트가 LVM과 동적으로 엉망이되지 않겠습니까?).

MMS 백업

MMS 백업에는 몇 가지 멋진 기능 (연속 백업, 손쉬운 특정 시점 복구)이 있지만, 큰 배포에 대한 가격표는 수천에 달할 수 있다는 심각한 단점이 있습니다. 이러한 10TB에서 시간당 500GB의 시간당 변경 률이 가정되면 클라우드 백업 의 중간 규모는 그림 6 입니다. 월간 간행물.

내 제안은 백업을 포함한 온 프레미스 MMS 인스턴스를 가질 수 있도록 서버에 엔터프라이즈 가입 을하는 것입니다.

요약

다음은 선호도의 내림차순으로 사용하는 옵션입니다.

1. SAN 스냅 샷 : 구현하기 쉽고 비교적 저렴
2. 엔터프라이즈 구독 : 최고의 기능. 설치, 구성, 잊어 버리면 필요할 때 사용 가능
3. LVM 스냅 샷 : 구현이 쉽지만 시간이 지남에 따라 초과 프로비저닝 비용이 발생할 수 있습니다.

두 가지 옵션이 있습니다

물리적 백업

가동 중지 시간이 마음에 들지 않으면 가장 간단한 방법은

service mongod stop

LVM 스냅 샷 또는 cpMongo 데이터 폴더 의 무차별 대입 을 다른 디스크에 수행

service mongod start

물론 10TB의 데이터가 독립형 시스템에있는 경우 가동 중지 시간을 원하지 않습니다.

지연된 교체 세트

세 개의 노드가있는 복제본 세트가있는 경우 백업을 위해 노드 중 하나를 사용하십시오.

{
        "_id" : "myreplica",
        "version" : 1,
        "members" : [
                {
                        "_id" : 1,
                        "host" : "10.20.30.40:27017",
                        "priority" : 2
                },
                {
                        "_id" : 2,
                        "host" : "10.20.30.41:27017"
                },
                {
                        "_id" : 3,
                        "host" : "10.20.30.42:27017",
                        "priority" : 0,
                        "slaveDelay" : 3600
                }
        ]
}

"_id' : 3모든 실제 백업 과 함께 노드를 사용하십시오 . 따라서 다운 타임이 없습니다. 자정 스냅 샷을 얻으려면 숨겨진 노드가 1 시간 뒤이므로 오전 1시에 백업을 시작할 수 있습니다.

물론 단점은 각각 10TB의 서버 2 대와 시스템 관리자의 정신이 위험하다는 것입니다.

몽고 덤

mongodump를 독립형 시스템에 사용할 수 있지만 mongodump는 다른 연결과 같은 연결을 사용하는 클라이언트 프로그램이므로 성능이 저하되어야합니다.

특정 시점 백업을 원할 경우

mongodump --oplog 

논리적 BSON 백업은 물리적 백업보다 작습니다 (특히 gzipped 또는 bzipped).

mongodump --oplog숨겨진 노드에 대해 사용하는 것이 가장 좋습니다. 그렇게하면 마스터에 대한 성능 저하가 없습니다.

기권

나는 MongoDB (우발적 / 부수적 MongoDBA)를 비교적 처음 사용합니다. 내 답변이 도움이 되길 바랍니다.