Обновление: апрель 2018
Этот ответ был верным во время вопроса, но с тех пор все пошло дальше. Начиная с версии 3.4 был введен параллелизм, и билет, на который я ссылался первоначально, был закрыт. Для получения дополнительной информации я расскажу о некоторых деталях в этом более свежем ответе . Оставшуюся часть ответа я оставлю как есть, потому что он остается хорошим справочником по общим вопросам / ограничениям, а также применим для всех, кто работает в более старой версии.
Оригинальный ответ
Если вам интересно, я подробно объясняю, что происходит с миграцией фрагментов в курсе M202 Advanced . В общих чертах, давайте просто скажем, что миграции не очень быстрые, даже для пустых кусков, из-за того, что ведение домашнего хозяйства выполняется, чтобы убедиться, что миграции работают в активной системе (это все еще происходит, даже если ничего не происходит, кроме балансировки).
Кроме того, во всем кластере одновременно происходит только одна миграция - параллелизма нет. Таким образом, несмотря на то, что у вас есть два «полных» узла и два «пустых» узла, в любой момент времени происходит не более одной миграции (между осколком с наибольшим количеством кусков и осколком с наименьшим). Следовательно, добавив 2 осколка, вы ничего не получите с точки зрения скорости балансировки и просто увеличите количество кусков, которые должны быть перемещены.
Для самих миграций размер блоков составляет, вероятно, ~ 30 МБ (зависит от того, как вы заполнили данные, но, как правило, это будет ваше среднее значение с максимальным размером блока по умолчанию). Вы можете использовать db.collection.getShardDistribution()эту информацию и посмотреть мой ответ здесь, чтобы узнать, как получить еще больше информации о ваших чанках.
Поскольку никаких других действий не происходит, для выполнения миграции целевой шард (один из вновь добавленных шардов) должен прочитать ~ 30 МБ данных из исходных шардов (один из исходных 2) и обновить серверы конфигурации до отразить новое местоположение чанка, как только это будет сделано. Перемещение 30 МБ данных не должно быть узким местом для нормальной системы без нагрузки.
Если это происходит медленно, существует ряд возможных причин, почему это так, но наиболее распространенными для системы, которая не занята, являются:
- Исходный дисковый ввод-вывод - если данные не находятся в активной памяти, когда они читаются, они должны быть выгружены с диска
- Сеть - если есть задержка, ограничение скорости, потеря пакетов и т. Д., Тогда чтение может занять довольно много времени.
- Целевой дисковый ввод-вывод - данные и индексы должны быть записаны на диск, многие индексы могут ухудшить ситуацию, но обычно это не проблема в слегка загруженной системе
- Проблемы с миграциями, вызывающими прерывания и неудачные миграции (проблемы с серверами конфигурации, проблемы с удалениями на основных)
- Задержка репликации - для миграции на наборы реплик, запись с записью
w:2или w:majorityиспользуется по умолчанию, и для ее выполнения требуется наличие обновленных вторичных серверов.
Если бы система была занята, то и конфликт памяти, и блокировка обычно бывали и здесь.
Чтобы получить больше информации о том, сколько времени занимает миграция, если она не удалась и т. Д., Взгляните на записи в вашем config.changelog:
// connect to mongos
use config
db.changelog.find()
Как вы уже видели, и, как я обычно говорю людям, когда я прохожу тренировку / обучение, если вы знаете, что вам понадобится 4 осколка, то обычно лучше начинать с 4, а не наращивать. Если вы это сделаете, то вам нужно знать, что добавление осколка может занять много времени, и изначально это чистый отрицательный эффект на ресурсы, а не выигрыш ( более детальное обсуждение этого см. Во второй части моей серии ловушек осколков ).
Наконец, чтобы отслеживать / повышать / комментировать запрос функции для улучшения параллелизма миграции чанков, посмотрите SERVER-4355