Оновлення: квітень 2018 року
Ця відповідь була правильною на момент запитання, але з того часу все пішло. З моменту введення версії 3.4 паралелізм, і квиток, на який я посилався, спочатку був закритий. Для отримання додаткової інформації я висвітлюю деякі деталі цієї останньої відповіді . Решту відповіді я залишу так, тому що вона залишається хорошим посиланням на загальні питання / обмеження, а також є дійсною для будь-кого на старій версії.
Оригінальний відповідь
Я даю повне пояснення того, що відбувається з міграцією шматка в курсі M202 Advanced, якщо вас цікавить. Загалом кажучи, скажімо, що міграція не дуже швидка, навіть для порожніх шматок, через ведення господарства, щоб переконатися, що міграції працюють в активній системі (вони все одно трапляються, навіть якщо нічого, крім балансування, не відбувається).
Крім того, є лише одна міграція, яка відбувається одночасно на всьому кластері - паралелізму немає. Отже, незважаючи на те, що у вас є два "повних" вузла та два "порожніх" вузла, в будь-який момент часу відбувається максимум одна міграція (між осколком з найбільшими шматками та осколком з найменшим). Отже, додавши 2 черепки, ви нічого не отримуєте з точки зору швидкості врівноваження і просто збільшуєте кількість шматочків, які потрібно перемістити.
Що стосується самих міграцій, шматки, ймовірно, мають розмір приблизно 30 Мб (залежить від того, як ви заселили дані, але загалом це буде ваш середній розмір за типовим розміром максимуму). Ви можете побігти db.collection.getShardDistribution()за деякою цією інформацією і подивитися тут мою відповідь щодо способів отримати ще більше інформації про ваші шматки.
Оскільки ніякої іншої активності не відбувається, для міграції трапиться цільовий осколок (одна з недавно доданих черепків) повинен прочитати ~ 30MiB даних з вихідних фрагментів (одна з оригінальних 2) та оновити конфігураційні сервери на відобразити нове місце, коли це буде зроблено. Переміщення 30 Мбіт даних не повинно бути великим місцем для звичайної системи без навантаження.
Якщо це повільно, є кілька можливих причин, чому це так, але найбільш поширеними для не зайнятої системи є:
- Джерело вводу / виводу диска - якщо дані не знаходяться в активній пам'яті під час їх читання, вони повинні бути підключені з диска
- Мережа - якщо є затримка, обмеження швидкості, втрата пакету тощо, то читання може зайняти досить багато часу
- Цільовий диск вводу-виводу - дані та індекси повинні бути записані на диск, багато індексів можуть погіршити це, але зазвичай це не проблема в мало завантаженій системі
- Проблеми з міграціями, що спричиняють перебої та невдалі міграції (проблеми з конфігураційними серверами, проблеми з делетами на праймери)
- Затримка реплікації - для міграцій для реплікації наборів, записує занепокоєння
w:2або w:majorityвикористовується за замовчуванням і для її задоволення потрібні актуальні вторинні пристрої.
Якщо система була зайнята тоді суперечками з пам'яттю, суперечки щодо блокування, як правило, і тут були підозрюваними.
Щоб отримати більше інформації про тривалість міграції, якщо вони провалюються тощо, подивіться записи у вашому config.changelog:
// connect to mongos
use config
db.changelog.find()
Як ви бачили, і як я зазвичай кажу людям, коли я займаюся тренуванням / навчанням, якщо ви знаєте, що вам знадобляться 4 осколки, то зазвичай краще починати з 4, а не нарощувати. Якщо це так, то вам потрібно знати, що додавання осколка може зайняти багато часу, і спочатку це чистий мінус на ресурси, а не на прибуток (див. Частину II мого ряду підводних каменів для більш детального обговорення цього питання).
Нарешті, для відстеження / оновлення / коментування запиту на функцію для покращення паралелізму міграційних фрагментів, перегляньте SERVER-4355