mongo db의 위험 요소 분석

Question

mongodb 설정을하려고합니다. 위험 요소를 분석하려고합니다. 테스트 환경에서

내 구성은

Routing server------> Config Server ------- > Shard01 
               Shard02 
               Shard03 

내 라우팅 서버 및 구성 서버가 동일한 시스템에서 실행되고 있습니다. Shard01, Shard02, Shard03은 각각 다른 세 대의 컴퓨터에서 실행됩니다. 이 시스템에서 모든 위험 요인이 무엇인지 분석하고 싶습니다. 예를 들어, 샤드 머신이 다운 된 응용 프로그램이 중지되면 하나의 시나리오가 있습니까?

Answer 1

1. 구성 서버가 하나만있는 것은 매우 나쁜 생각입니다. 프로덕션 환경의 경우 항상 항상, 항상은 세 개의 구성 서버를 사용합니다. 이유 : 설정 서버가 없다면, 쿼리 라우터는 설정 서버에서 어떤 키 범위가 어떤 샤드에 있는지에 대한 정보를 얻으므로 클러스터는 기본적으로 쓸모 없게됩니다. (mongos의 메타 데이터 캐싱은 문제를 지연시키기 때문에). 참고 : 달리 수행하는 경우에는 책임지고 수행하십시오.
2. 구성 서버와 쿼리 라우터를 동일한 컴퓨터에서 실행하는 것은 매우 나쁜 생각입니다. 로드가 많은 경우이 컴퓨터는 네트워크 IO를 위해 경쟁해야합니다. 이것은 드문 경우이지만 여전히 발생할 수 있습니다. 각 응용 프로그램 서버에 쿼리 라우터를 두는 것이 더 의미가 있습니다. 즉, 네트워크 대기 시간을 줄이며 (데이터에 도달 할 때까지 한 번 홉을 줄임) 개별 몽고를 오버로드 할 수 없으며 실행할 필요가 없습니다 config 서버의 mongos. ;) 진지하게, 그것은 제안되고 잘 입증 된 설정입니다.
3. 샤드를 독립 실행 형 인스턴스로 실행하는 아이디어는 AWFUL입니다. 기본 샤드 (system을 포함한 군대가 아닌 컬렉션을 보유한 샤드)가 실패하면 큰 문제가 있습니다. 항상은 복제 세트를 샤드로 사용합니다. 참고 : 달리 수행하는 경우에는 책임지고 수행하십시오.

덜 알려진 MongoDB 드라이버의 특징은 여러 몽고 인스턴스를 사용하도록 구성 할 수 있다는 것입니다. 처음 실패하면 다음 시도가 시도됩니다. 따라서 여러 몽고 (응용 프로그램 서버 당 하나), 적절한 데이터 소스 구성, 세 개의 구성 서버 및 복제 세트가 샤드로서 단일 실패 지점 (노드 별)이 없습니다.