Aktualizacja: kwiecień 2018 r
Ta odpowiedź była poprawna w momencie pytania, ale od tego czasu wszystko potoczyło się dalej. Od wersji 3.4 wprowadzono paralelizm, a bilet, do którego się pierwotnie odwoływałem, został zamknięty. Aby uzyskać więcej informacji, opisuję niektóre szczegóły w tej najnowszej odpowiedzi . Pozostawiam resztę odpowiedzi bez zmian, ponieważ pozostaje ona dobrym odniesieniem do ogólnych problemów / ograniczeń, a także jest ważna dla każdego w starszej wersji.
Oryginalna odpowiedź
Jeśli jesteś zainteresowany, podaję pełne wyjaśnienie tego, co dzieje się z migracją porcji na kursie M202 Advanced . Mówiąc ogólnie, powiedzmy tylko, że migracje nie są bardzo szybkie, nawet w przypadku pustych porcji, ze względu na wykonywanie operacji porządkowych w celu upewnienia się, że migracje działają w aktywnym systemie (nadal tak się dzieje, nawet jeśli nie dzieje się nic oprócz równoważenia).
Ponadto w całym klastrze odbywa się tylko jedna migracja - nie ma równoległości. Tak więc pomimo faktu, że masz dwa „pełne” węzły i dwa „puste” węzły, w danym momencie odbywa się co najwyżej jedna migracja (między fragmentem o największej liczbie fragmentów a fragmentem o najmniejszej liczbie). Dlatego po dodaniu 2 odłamków nic nie zyskujesz pod względem prędkości równoważenia, a jedynie zwiększa liczbę porcji, które należy przenieść.
W przypadku samych migracji porcje mają rozmiar około 30 MB (zależy od sposobu zapełniania danych, ale ogólnie będzie to średnia z domyślnym maksymalnym rozmiarem porcji). Możesz ubiegać się db.collection.getShardDistribution()o niektóre z tych informacji i zobacz moją odpowiedź tutaj, aby uzyskać więcej informacji na temat twoich kawałków.
Ponieważ nie odbywa się żadna inna aktywność, aby dokonać migracji, fragment docelowy (jeden z nowo dodanych fragmentów) będzie musiał odczytać ~ 30 MB danych z fragmentów źródłowych (jeden z oryginalnych 2) i zaktualizować serwery konfiguracji, aby odzwierciedlają nową lokalizację porcji po jej zakończeniu. Przeniesienie 30 MB danych nie powinno stanowić wąskiego gardła dla normalnego systemu bez obciążenia.
Jeśli jest powolny, istnieje wiele możliwych przyczyn, ale najczęstsze dla systemu, który nie jest zajęty, to:
- Dysk źródłowy we / wy - jeśli dane nie są w aktywnej pamięci podczas odczytu, muszą zostać przywołane z dysku
- Sieć - jeśli występuje opóźnienie, ograniczenie prędkości, utrata pakietów itp., Odczyt może potrwać dość długo
- Docelowe We / Wy dysku - dane i indeksy muszą być zapisane na dysku, wiele indeksów może to pogorszyć, ale zwykle nie jest to problem w lekko obciążonym systemie
- Problemy z migracjami powodujące przerwanie i nieudane migracje (problemy z serwerami konfiguracji, problemy z usuwaniem na urządzeniach podstawowych)
- Opóźnienie replikacji - w przypadku migracji do zestawów replik należy napisać problem
w:2lub w:majorityjest używany domyślnie i wymaga aktualnych plików pomocniczych, aby go spełnić.
Jeśli system był zajęty, to rywalizacja o pamięć, rywalizacja o blokadę również zwykle byłaby tutaj podejrzana.
Aby uzyskać więcej informacji o tym, jak długo trwają migracje, jeśli kończą się niepowodzeniem itp., Spójrz na wpisy w config.changelog:
// connect to mongos
use config
db.changelog.find()
Jak widzieliście i jak ogólnie mówię ludziom, kiedy trenuję / edukuję, jeśli wiesz, że będziesz potrzebować 4 odłamków, wtedy zwykle lepiej jest zacząć od 4, a nie zwiększać. Jeśli to zrobisz, musisz mieć świadomość, że dodanie odłamka może zająć dużo czasu i początkowo ma raczej ujemny wpływ na zasoby niż zysk ( więcej szczegółów na ten temat można znaleźć w części II mojej serii pułapek odłamków ).
Wreszcie, aby śledzić / aktualizować / komentować żądanie funkcji w celu poprawy równoległości migracji porcji, sprawdź SERVER-4355
