mongodb는 하나의 AWS EC2에서만 실행됩니다 (마스터 - 슬레이브 없음, 복제 세트 없음). 데이터 파일은 별도의 EBS 볼륨에 저장됩니다. 따라서 데이터를 쓰기 (쓰기 잠금)하지 않고 백업 및 복원하는 가장 좋은 방법은 무엇입니까 (& 잠금)? 아니면 그것을 달성하기 위해 우리는 반드시 노예가 되어야만 하는가?mongodb의 데이터를 잠그지 않고 백업하는 좋은 전략은 무엇입니까 (fsync 및 lock)?
은 당신이 일지 (MongoDB의의 기본을 2.0 이상) 활성화, 당신은 fSyncLock() 필요없이 데이터 파일의 일관성있는 덤프를 얻을 수 EBS 스냅 샷을 활용할 수 있습니다.
자세한 내용은 MongoDB 사이트의 EC2 Backup & Restore 문서를 참조하십시오.
MongoDirector.com에서 우리는 우리의 MongoDB 데이터베이스를 백업하기 위해 LVM 스냅 샷을 사용합니다. DB 크기가 커지면 실제로 유일한 옵션입니다. MongoDump를 사용하고 MongoRestore를 사용하여 복원하려고하면 몇 시간이 걸릴 수 있습니다. 2.0 이상에서는 fsyncLock()은 선택 사항이지만 어쨌든 사용합니다.
감사합니다. 그런데도 ebs 스냅 샷을 수행 할 때 db 성능에 대한 염려가 있습니다. 성능에 많은 영향을 줍니까? 그렇다면 더 나은 해결책이 있습니까? –
제 경험상 EBS 성능은 일반적으로 일치하지 않지만 EBS 스냅 샷은 Amazon Web Services에서 지원하는 특정 시점의 백업 전략입니다. 실제 영향은 시스템 활용도, 파일 시스템, 데이터 디렉토리의 크기, 스냅 샷의 빈도 및 EBS의 날씨 패턴에 따라 달라질 수 있습니다. – Stennie
대안으로 [MongoDB 백업 및 복원 전략] (http://docs.mongodb.org/manual/administration/backups/)에 대한 개요가 있습니다. 전체 데이터 백업과 함께 대기 대기 상태가되며 단일 서버에 비해 다른 관리 이점이 있으므로 복제 세트를 사용하는 것이 좋습니다. 예를 들어 주 서버에 영향을주지 않고 보조 서버에서 백업을 수행 할 수 있습니다. 장애 조치를 위해 다른 가용성 영역에 노드를 가질 수도 있습니다. 복제본 세트는 보관 백업 전략 대신 사용할 수는 없지만 좋은 보완책이 될 수 있습니다. – Stennie