나는 교통량이 비교적 적지 만 데이터를 안전하게 유지하려고합니다. 데이터는 단일 MongoDb 인스턴스에 저장됩니다. 여러 개의 복제본을 실행하고 관리하고 싶지 않습니다. 따라서 데이터 디렉터리를 EFS 경로로 변경하여 복제 및 기타 이점을 활용할 계획입니다. 주기적인 스냅 샷은 데이터 손실을 유발할 수 있으며 복구는 수동입니다. 추가 대기 시간으로 인해 EFS에 데이터 및 저널 파일을 저장하는 데 단점이 있습니까?Amazon EFS의 MongoDb 데이터 - 탄성 파일 시스템
언급했듯이 EFS 개체는 가용성 영역 전체에 replicated입니다. 이와 대조적으로 EBS 볼륨은 단일 가용성 영역 내에서만 replicated입니다. 가격 차이는 현재 EFS가 0.30 달러/GB, EBS가 0.10 달러/GB로 시작하는 경우 크게 차이가납니다. 일반적인 EFS 유스 케이스는 사용자 홈 디렉토리 및 응용 프로그램 데이터와 같이 여러 인스턴스에서 공유해야하는 데이터를위한 것입니다. EBS는 또한 최저 대기 시간을 제공 할 수 있습니다.
이러한 점을 염두에두고 MongoDB 데이터에는 EFS를 사용하지 않는 것이 좋습니다. EFS의 다중 AZ 복제가 주요 목표 인 경우 EBS 볼륨의 주기적 스냅 샷 (S3에 저장 됨)을 사용하여 EBS로 달성 할 수 있습니다. 나는 EBS가 당신에게 더 나은 성능과 저렴한 비용을 줄 것이라고 생각합니다.
EFS를 사용하는 것이 실제로 여러 MongoDB 인스턴스를 실행하는 대신 사용할 수있는 방법은 아닙니다. 복제 및 샤딩은 EFS가 달성 할 수있는 것이 아닙니다.
주기적 스냅 샷으로는 충분하지 않습니다. 이로 인해 데이터가 손실 될 수 있습니다. 또한 복구는 수동입니다. 게다가, 내 데이터 크기는 여전히 거의 1 기가 바이트이며, 나는 그것이 가까운 미래에 5 기가 바이트 넘어 증가 볼 수 없습니다. 따라서 스토리지 비용은 필자의 경우 큰 문제는 아닙니다. – JackDaniels
EBS 스냅 샷은 특정 시점 백업입니다. 무언가 잘못되면 다시 되돌릴 점이 있습니다. EFS를 사용하면 백업을하지 않아도 어떤 이유로 든 데이터 손실이 발생하는 경우 (일부 사용자 지정 스크립트 없이는) 백업 할 필요가 없습니다. – jbird
EBS의 실패로 인해 EBS 스냅 샷을 사용할 수없는 상황을 보았습니다. 이상한데? 예. 그러나 그것은 실제로 일어난 일입니다. 준비되다. –
하나의 EC2 인스턴스에서 실행되는 단일 MongoDB 설치를 통해이 데이터에 독점적으로 액세스 할 계획입니까? –
예, 적어도 몇 개월 이상. 하루에 200 건의 글이 거의 없습니다. 이것이 설치를 단순화하는 데 도움이됩니까? – JackDaniels
예. 나는 @jbird가 내가했던 것과 똑같은 인상을 받았고 MongoDB 구성 요소를 실행하는 여러 대의 EC2 머신을 상상하고 EFS에 살고있는 하나의 백업 스토어를 공유하고 있다고 생각합니다.이 경우에 그는 완전히 정확합니다. 그러나 스토리지 탄력성 측면을 찾고있는 경우에는 다소 비 재래 적 유스 케이스입니다.하지만 "생각해보십시오."라고 말하고 싶습니다. 시도하는 것이 무엇이 아플까? 서비스를 중지하고, 파일을 복사하고, 경로를 구성하고, 다시 시작하십시오. 당신이 묘사하는 것과 같이 트래픽이 적을 때 합리적으로 잘 작동하지 않아야하는 본질적인 이유는 없습니다. –