문서 메뉴
문서 홈
/
MongoDB 매뉴얼
/

FAQ: MongoDB를 사용한 샤딩

이 페이지의 내용

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

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

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

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

다음도 참조하세요.

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

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

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

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

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

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

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

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

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

db.adminCommand("connPoolStats");

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

돌아가기

동시성

다음

복제