Nasza najnowsza wersja ClusterControl zamienia niektóre z najbardziej kłopotliwych zadań MongoDB w zaledwie 15-sekundową pracę. Dodano nowe funkcje, aby zapewnić większą kontrolę nad klastrem i dokonywać zmian w topologii:
- Konwertuj replikę MongoDBUstaw na sharded klaster MongoDB
- Dodaj i usuń odłamki
- Dodaj routery shard do shardowanego klastra MongoDB
- Zwolnij lub zamroź węzeł
- Nowi doradcy MongoDB
Poniżej szczegółowo opiszemy te dodane funkcje.
Konwertuj zestaw replik MongoDB na klaster MongoDB z podziałem na fragmenty
Ponieważ większość użytkowników MongoDB zaczyna od zestawu replik do przechowywania bazy danych, jest to najczęściej używany typ klastra. Jeśli napotkasz problemy ze skalowaniem, możesz przeskalować ten zestaw repliki, dodając więcej pomocniczych lub skalując w poziomie przez fragmentowanie. Istniejący zestaw replik można przekonwertować na klaster podzielony na fragmenty, jednak jest to długi proces, w którym można łatwo popełnić błędy. W ClusterControl zautomatyzowaliśmy ten proces, w którym automatycznie dodajemy serwery Configserver, routery shard i włączamy sharding.
Aby przekonwertować zestaw replik do klastra podzielonego na fragmenty, możesz go po prostu wyzwolić za pomocą listy rozwijanej akcji:
Spowoduje to otwarcie dwuetapowego dialogu, w jaki sposób przekonwertować to na odłamek. Pierwszym krokiem jest określenie miejsca wdrożenia serwera Configserver i routerów shard:
Drugim krokiem jest to, gdzie przechowywać dane i które pliki konfiguracyjne powinny być używane dla serwera Configserver i routera odłamkowego.
Po zakończeniu zadania migracji fragmentów przegląd klastra wyświetla teraz fragmenty zamiast wystąpień zestawu repliki:
Po konwersji do klastra podzielonego na fragmenty można dodać nowe fragmenty.
Dodaj lub usuń fragmenty z klastra MongoDB podzielonego na fragmenty
Dodawanie odłamków
Ponieważ fragment MongoDB jest technicznie repliką, dodanie nowego fragmentu wiąże się również z wdrożeniem nowego zestawu replik. W ramach ClusterControl najpierw wdrażamy nowy zestaw replik, a następnie dodajemy go do klastra podzielonego na fragmenty.
Z interfejsu użytkownika ClusterControl możesz łatwo dodawać nowe fragmenty za pomocą dwuetapowego kreatora, otwieranego z listy rozwijanej akcji:
Tutaj możesz zdefiniować topologię nowego fragmentu.
Po dodaniu nowego fragmentu do klastra router fragmentu MongoDB zacznie przypisywać do niego nowe fragmenty, a system równoważenia automatycznie zrównoważy wszystkie fragmenty we wszystkich fragmentach.
Usuwanie odłamków
Usunięcie fragmentów jest nieco trudniejsze niż dodanie fragmentu, ponieważ wiąże się to z przeniesieniem danych do innych fragmentów przed usunięciem samego fragmentu. W przypadku wszystkich danych, które zostały podzielone na wszystkie fragmenty, będzie to zadanie wykonywane przez system równoważenia MongoDB.
Jednak każda baza danych/kolekcja nie podzielona na fragmenty, która została przypisana do tego fragmentu jako jego fragment podstawowy, musi zostać przeniesiona do innego fragmentu i utworzyć nowy fragment podstawowy. W tym procesie MongoDB musi wiedzieć, dokąd przenieść te bazy danych/kolekcje nie podzielone na fragmenty.
W ClusterControl możesz je po prostu usunąć za pomocą rozwijanego menu:
Umożliwi to wybranie fragmentu, który chcesz usunąć, oraz fragmentu, do którego chcesz przenieść podstawowe bazy danych:
Zadanie, które usuwa fragment, wykona następnie podobne czynności, jak opisano wcześniej:przeniesie wszystkie podstawowe bazy danych do wyznaczonego fragmentu, włączy funkcję równoważenia, a następnie poczeka, aż przeniesie wszystkie dane z fragmentu.
Po usunięciu wszystkich danych fragment zostanie usunięty z interfejsu użytkownika.
Dodawanie dodatkowych routerów odłamkowych MongoDB
Gdy zaczniesz skalować swoją aplikację za pomocą klastra z fragmentami MongoDB, może się okazać, że potrzebujesz dodatkowych routerów fragmentu.
Dodawanie dodatkowych routerów shard MongoDB jest bardzo prostym procesem za pomocą ClusterControl, wystarczy otworzyć okno dialogowe Dodaj węzeł z listy rozwijanej akcji:
Spowoduje to dodanie nowego routera fragmentu do klastra. Nie zapomnij ustawić prawidłowego domyślnego portu (27017) na routerze.
Zamknij serwer
Jeśli chcesz przeprowadzić konserwację na węźle podstawowym w zestawie replik, lepiej jest najpierw „ustąpić” w sposób wdzięczny przed przełączeniem go w tryb offline. Rezygnacja z podstawowego oznacza, że host przestaje być głównym i staje się drugorzędnym i nie kwalifikuje się do zostania głównym przez określoną liczbę sekund. Węzły w zestawie replik MongoDB z uprawnieniami do głosowania wybiorą nową podstawową z wykluczeniem podstawowej z obniżoną na określoną liczbę sekund.
W ClusterControl dodaliśmy funkcję obniżania poziomu jako akcję na stronie Węzły. Aby przejść w dół, po prostu wybierz tę akcję z listy rozwijanej:
Po ustawieniu liczby sekund do wycofania i potwierdzeniu, podstawowa zrezygnuje i zostanie wybrana nowa podstawowa.
Zamrożenie węzła
Ta funkcja jest podobna do polecenia obniżania poziomu:powoduje to, że określony węzeł nie kwalifikuje się do stania się głównym przez określoną liczbę sekund. Oznacza to, że możesz zapobiec sytuacji, w której jeden lub więcej węzłów drugorzędnych stanie się głównymi podczas obniżania poziomu głównego i w ten sposób zmusić określony węzeł, aby stał się nowym głównym.
W ClusterControl dodaliśmy funkcję zamrożenia węzła jako akcję na stronie Węzły. Aby zamrozić węzeł, po prostu wybierz to jako akcję z listy rozwijanej:
Po ustawieniu liczby sekund i potwierdzeniu, węzeł nie będzie kwalifikował się jako główny przez określoną liczbę sekund.
Nowi doradcy MongoDB
Doradcy to miniprogramy, które udzielają porad w konkretnych kwestiach dotyczących baz danych. Dodaliśmy trzech nowych doradców dla MongoDB. Pierwsza oblicza okno replikacji, druga czuwa nad oknem replikacji, a trzecia sprawdza, czy nie ma baz danych/kolekcji bez fragmentów.
Doradca opóźnień replikacji MongoDB
Opóźnienie replikacji jest bardzo ważne, aby mieć na to oko, jeśli skalujesz odczyty poprzez dodanie większej liczby drugorzędnych. MongoDB użyje tych serwerów pomocniczych tylko wtedy, gdy nie pozostaną zbyt daleko w tyle. Jeśli serwer pomocniczy ma opóźnienie replikacji, ryzykujesz udostępnienie nieaktualnych danych, które zostały już nadpisane na serwerze podstawowym.
Aby sprawdzić opóźnienie replikacji, wystarczy połączyć się z serwerem podstawowym i pobrać te dane za pomocą polecenia replSetGetStatus. W przeciwieństwie do MySQL, serwer podstawowy śledzi stan replikacji swoich drugorzędnych.
Wdrożyliśmy to sprawdzenie do doradcy w ClusterControl, aby zapewnić, że opóźnienie replikacji będzie zawsze obserwowane.
Doradca okna replikacji MongoDB
Podobnie jak opóźnienie replikacji, okno replikacji jest równie ważnym wskaźnikiem, na który należy patrzeć. Doradca lagów już informuje nas o tym, ile sekund węzeł drugorzędny jest za głównym/głównym. Ponieważ oplog ma ograniczony rozmiar, posiadanie slave lag wiąże się z następującymi zagrożeniami:
- Jeśli węzeł pozostaje zbyt daleko w tyle, może nie być już w stanie nadrobić zaległości, ponieważ transakcje niezbędne do nadrobienia zaległości nie znajdują się już w oplogu głównego.
- Opóźniony węzeł drugorzędny jest mniej uprzywilejowany w wyborach MongoDB na nowy główny. Jeśli wszystkie drugorzędne są opóźnione w replikacji, będziesz miał problem i ten z najmniejszym opóźnieniem stanie się podstawowym.
- Opóźniające się drugorzędne elementy są mniej preferowane przez sterownik MongoDB podczas skalowania odczytów za pomocą MongoDB, zwiększa to również obciążenie pozostałych drugorzędnych.
Gdybyśmy mieli drugorzędny węzeł opóźniony o kilka minut (lub godzin), przydałoby się mieć doradcę, który poinformuje nas, ile czasu nam zostało, zanim nasza następna transakcja zostanie usunięta z oploga. Różnica czasu między pierwszym a ostatnim wpisem w oplogu nazywana jest oknem replikacji. Te dane można utworzyć, pobierając pierwszy i ostatni element z oploga i obliczając różnicę ich sygnatur czasowych.
W powłoce MongoDB dostępna jest już funkcja, która oblicza dla Ciebie okno replikacji. Jednak ta funkcja jest wbudowana w powłokę wiersza poleceń, więc żadne połączenie zewnętrzne nie korzystające z powłoki wiersza poleceń nie będzie miało tej wbudowanej funkcji. Dlatego stworzyliśmy doradcę, który będzie czuwał nad oknem replikacji i ostrzegał, jeśli przekroczysz wcześniej ustalony próg.
MongoDB Unsharded Databases and Collections Advisor
Bazy danych i kolekcje nie podzielone na fragmenty zostaną przypisane do domyślnego podstawowego fragmentu przez router fragmentu MongoDB. Oznacza to, że baza danych lub kolekcja jest ograniczona do rozmiaru tego podstawowego fragmentu, a jeśli zostanie zapisana w dużych woluminach, może wykorzystać całe pozostałe miejsce na dysku fragmentu. Gdy to się stanie, odłamek oczywiście przestanie działać. Dlatego ważne jest, aby czuwać nad wszystkimi istniejącymi bazami danych i kolekcjami oraz przeskanować bazę danych konfiguracyjnych, aby sprawdzić, czy zostały włączone do shardingu.
Aby temu zapobiec, stworzyliśmy nieoddzieloną bazę danych i doradcę w zakresie zbierania. Ten doradca przeskanuje każdą bazę danych i kolekcję oraz ostrzeże Cię, jeśli nie zostały one podzielone.
ClusterControl poprawił łatwość konserwacji MongoDB
Zrobiliśmy duży krok, dodając wszystkie ulepszenia ClusterControl dla zestawów replik MongoDB i klastrów podzielonych na fragmenty. To znacznie poprawia użyteczność MongoDB i pozwala administratorom baz danych, administratorom i deweloperom na jeszcze lepsze utrzymywanie swoich klastrów!
