mongodb 샤드 클러스터가 있으며 샤드 키가 해시됩니다. 2 개의 샤드 복제본 세트가 있습니다. 각 복제본 세트에는 2 개의 시스템이 있습니다.
다른 2 개의 샤드 복제본 세트를 추가하여 실험을 수행 한 후 재조정을 시작합니다.
그러나 잠시 후 청크 마이그레이션이 느리다는 것을 알았습니다. 1.4GB의 데이터를 이동하는 데 1 시간이 걸립니다.
걱정이됩니다. 500GB 청크 마이그레이션을 완료하려면 13 일 동안 기다려야합니다!
나는이 물건에 익숙하지 않으며 느리거나 빠르거나 정상인지 신의 느낌이 없습니다. 그러나 여전히 그 숫자는 저를 설득하지 않습니다.
실험에 대한 추가 참고 사항 :-m3 medium AWS 시스템 사용-다른 프로세스 실행 없음, 청크 마이그레이션 만-추가 구성없이 기본 mongodb 샤딩 설치-shardkey가 객체 ID (_id)에서 해시를 사용함-최대 청크 크기 64MB
답변:
업데이트 : 2018 년 4 월
이 답변은 질문 당시에는 정확했지만 그 이후로 상황이 계속되었습니다. 버전 3.4 이후 병렬 처리가 도입되었으며 원래 참조한 티켓이 닫혔습니다. 자세한 내용은이 최신 답변 의 세부 정보 중 일부를 다루고 있습니다 . 나는 일반적인 문제 / 제약 조건에 대한 좋은 참고 자료로 남아 있으며 이전 버전의 모든 사람에게도 유효하기 때문에 나머지 대답은 그대로 둡니다.
원래 답변
관심 이 있으시 다면 M202 Advanced 코스 에서 청크 마이그레이션으로 인해 발생하는 일에 대해 자세히 설명합니다 . 일반적으로 빈 청크에서도 마이그레이션이 활성 시스템에서 작동하도록하기 위해 수행되는 하우스 키핑 때문에 마이그레이션이 매우 빠르지 않다고 가정 해 봅시다 (이것은 여전히 밸런싱이 발생하더라도 발생합니다).
또한 전체 클러스터에서 한 번에 하나의 마이그레이션 만 발생하며 병렬 처리는 없습니다. 따라서 두 개의 "전체"노드와 두 개의 "빈"노드가 있다는 사실에도 불구하고, 주어진 시간에 최대 한 번의 마이그레이션이 발생합니다 (가장 큰 청크가있는 샤드와 가장 적은 샤드간에). 따라서 2 개의 샤드를 추가하면 속도 균형면에서 아무것도 얻지 못하고 이동 해야하는 청크 수가 증가합니다.
마이그레이션 자체의 경우 청크 크기는 ~ 30MiB (데이터를 채우는 방법에 따라 다르지만 일반적으로 기본 최대 청크 크기의 평균이 됨)입니다. db.collection.getShardDistribution()그 정보 중 일부를 실행 하고 청크에 대한 더 많은 정보를 얻는 방법에 대한 내 대답을 참조하십시오 .
진행중인 다른 활동이 없기 때문에 마이그레이션을 수행하려면 대상 샤드 (새로 추가 된 샤드 중 하나)가 소스 샤드 (원래 2 중 하나)에서 ~ 30MiB의 데이터를 읽고 구성 서버를 다음과 같이 업데이트해야합니다. 새로운 청크 위치가 완료되면 반영합니다. 30MiB의 데이터 이동은로드가없는 일반 시스템에서 병목 현상을 일으키지 않아야합니다.
속도가 느리면 여러 가지 이유가있을 수 있지만 사용 중이 아닌 시스템에 가장 일반적인 이유는 다음과 같습니다.
w:2또는 w:majority기본적으로 사용되며이를 충족하려면 최신 보조가 필요합니다.시스템이 메모리 경합 인 경우, 경합 경합은 일반적으로 여기에서도 의심됩니다.
마이그레이션에 걸리는 시간, 실패한 경우 등에 대한 자세한 정보를 얻으려면 다음 항목을 살펴보십시오 config.changelog.
// connect to mongos
use config
db.changelog.find()
당신이 보았 듯이, 내가 훈련 / 교육을 할 때 사람들에게 일반적으로 말했듯이, 4 개의 샤드가 필요하다는 것을 알고 있다면 일반적으로 증가하지 않고 4로 시작하는 것이 좋습니다. 그렇다면 샤드를 추가하는 데 오랜 시간이 걸릴 수 있으며 처음에는 이익이 아닌 자원에 대한 부정적인 영향을 미칩니다 ( 자세한 내용은 샤딩 함정 시리즈 II 참조 ).
마지막으로, 청크 마이그레이션의 병렬 처리를 개선하기 위해 기능 요청에 대한 추적 / 발표 / 코멘트를 작성하려면 SERVER-4355를 확인하십시오.