Docs Menu
Docs Home
/
MongoDB 매뉴얼
/

FAQ: MongoDB를 사용한 샤딩

이 페이지의 내용

  • 샤딩이 새 배포에 적합한가요?
  • 컬렉션을 샤딩한 후 다른 샤드 키를 선택할 수 있나요?
  • 내 문서가 여러 샤드에 분산된 되지 않는 이유는 무엇인가요?
  • mongos 은(는) 샤드 cluster 구성의 변경 사항을 어떻게 감지하나요?
  • 로그의 writebacklisten (은)는 무슨 뜻인가요?
  • mongos 는 연결을 어떻게 사용하나요?

이 문서 에서는 샤딩 에 대한 일반적인 질문에 답변합니다. 샤딩에 대한 샤딩 를 제공하는 매뉴얼의 샤딩 섹션도 참조하세요.

가끔씩 발생합니다. 그러나 데이터 세트가 단일 서버에 적합한 경우, 데이터 세트가 작을 때 샤딩을 하면 이점이 거의 없으므로 비샤딩 배포로 시작해야 합니다.

샤드 키 변경 옵션은 실행 중인 MongoDB 버전에 따라 다릅니다.

다음도 참조하세요.

청크 분포가 특정 임계값에 도달하면 밸런서 는 샤드 전체에 데이터를 분산하기 시작합니다. 마이그레이션 임계값을 참조하세요.

또한 청크 의 문서 수가 특정 수를 초과하면 MongoDB 는 청크 를 이동할 수 없습니다. 마이그레이션할 범위당 최대 문서 수분할 불가능/점보 청크를 참조하세요.

인스턴스는 mongos 샤딩된 클러스터 의 메타데이터 를 보관하는 config 데이터베이스 의 캐시 를 유지 관리합니다.

mongos 는 샤드 에 요청 을 발행하고 메타데이터 가 최신 상태가 아님을 발견하여 캐시 느리게 업데이트합니다. mongos 가 캐시 를 다시 로드하도록 강제하려면 각 mongos 에 대해flushRouterConfig명령을 직접 실행 수 있습니다.

후기입(Writeback) 리스너는 마이그레이션 후 mongod 또는 mongos에서 쓰기를 릴레이하여 잘못된 서버로 이동하지 않았는지 확인하기 위해 긴 폴링을 여는 프로세스입니다. 후기입 리스너는 필요한 경우 쓰기를 올바른 서버로 다시 보냅니다.

이러한 메시지는 샤딩 인프라의 핵심적인 부분이므로 걱정하지 않아도 됩니다.

mongos 인스턴스 는 샤딩된 클러스터 의 멤버에 대한 연결 풀을 유지 관리합니다. 클라이언트 요청은 이러한 연결을 한 번에 하나씩 사용합니다. 즉, 요청이 멀티플렉싱되거나 파이프라인되지 않습니다.

클라이언트 요청이 완료되면 mongos 가 풀에 대한 연결을 반환합니다. 이러한 풀은 클라이언트 수가 감소해도 축소되지 않습니다. 이로 인해 열려 있는 연결 수가 많은 미사용 mongos 가 발생할 수 있습니다. mongos 가 더 이상 사용되지 않는 경우 프로세스 를 다시 시작하여 기존 연결을 종료하는 것이 안전합니다.

mongos 에서 사용하는 모든 발신 연결 풀과 관련된 애그리게이션된 통계를 반환하려면 mongoshmongos 에 연결하고 connPoolStats 명령을 실행합니다.

db.adminCommand("connPoolStats");

자체 관리 배포서버를 위한 UNIX 설정 문서 의 ulimit 시스템 리소스 사용률 섹션을 참조하세요.

돌아가기

동시성