Wdrażanie MongoDB w środowisku produkcyjnym może naprawdę działać tylko wtedy, gdy przestrzegany jest właściwy wzorzec wdrażania. Wdrożenie zestawu replik na jednym hoście nie gwarantuje wysokiej dostępności danych. Radzenie sobie z dużymi zbiorami danych wymaga szeroko zakrojonych badań i optymalnych wdrożeń, albo poprzez połączenie dostępnych opcji, albo wybranie tej z najbardziej obiecującymi korzyściami.
Wzorce wdrażania MongoDB obejmują:
- Trzy zestawy replik członków
- Zestawy replik rozmieszczone w dwóch lub więcej centrach danych.
Trzy zestawy replik członków
Replikacja to strategia skalowania dla MongoDB, która zwiększa wysoką dostępność danych. Zestaw replik obejmuje:
- Węzeł podstawowy:odpowiedzialny za wszystkie operacje związane z przepustowością zapisu i może być również odczytywany.
- Węzły drugorzędne:mogą być używane tylko do operacji odczytu, ale mogą być wybrane jako główne w przypadku awarii istniejącego. Otrzymują aktualizacje danych z oploga wygenerowanego przez głównego członka zestawu.
- Arbiter. Służy do ułatwienia wyboru podstawowego w przypadku parzystej liczby członków zestawu replik. Nie przechowuje żadnej kopii danych.
Korzyści z zestawu replik można osiągnąć tylko przy minimalnej liczbie trzech elementów o następującej architekturze:
Podstawowy-Dodatkowy-Dodatkowy
Jest to najbardziej zalecane, ponieważ ma większą odporność na błędy i rozwiązuje ograniczenia związane z dodawaniem trzeciego elementu przenoszącego dane, takie jak koszt.
To wdrożenie zawsze zapewni dwie kompletne kopie oprócz danych podstawowych, zapewniając w ten sposób wysoką dostępność. Niepowodzenie podstawowego spowoduje, że zestaw replik wybierze nowy podstawowy, a operacja udostępniania zostanie wznowiona normalnie. Jeśli stara podstawowa ożyje, zostanie zaklasyfikowana jako drugorzędny członek.
Podczas procesu wyborczego członkowie sygnalizują sobie nawzajem puls i w tym czasie nie odbywają się żadne operacje zapisu
Po procesie wyborczym zakładamy reformę architektury jako:
Główny-drugi-arbiter
Gwarantuje to, że zestaw replik pozostaje dostępny, nawet jeśli główny lub dodatkowy jest niedostępny, ułatwiając proces wyboru drugiego na główny. Arbitrzy nie mają przy sobie żadnej kopii danych, dlatego ich zarządzanie wymaga mniej zasobów.
Ograniczeniem tego wdrożenia jest; brak redundancji, ponieważ istnieją tylko dwa elementy przenoszące dane:pierwotny i wtórny. Skutkuje to niższą tolerancją błędów.
Tolerancja błędów powinna zapewniać:
- Dostępność zapisu:większość głosujących członków zestawu replik jest potrzebna do utrzymania lub wybrania podstawowego, który jest odpowiedzialny za operacje zapisu.
- Nadmiarowość danych:zapis może być potwierdzony przez wielu członków, aby uniknąć cofnięć
Konfiguracja Primary-Secondary-Arbiter obsługuje aspekt dostępności zapisu tylko w taki sposób, że jeśli pojedynczy element zestawu jest niedostępny, podstawowy może być nadal utrzymany.
Jednak brak wsparcia drugiego aspektu skutkuje pewnymi konsekwencjami operacyjnymi, jeśli drugorzędny członek staje się niedostępny:
- Nie będzie aktywnej replikacji, zwłaszcza jeśli pomocnicza jest przez długi czas w trybie offline. Gdy serwer pomocniczy jest zbyt długo w trybie offline, może spaść z oploga, zmuszając go do ponownej synchronizacji podczas ponownego uruchamiania.
- Nadmiarowość danych zostanie sabotowana, wymuszając potwierdzenie operacji zapisu tylko przez bieżącą stronę główną.
- Większość z zaniepokojeniem opcja nie będzie dostarczać najnowszych danych do podłączonych aplikacji i procesów wewnętrznych. Dzieje się tak, gdy twoja konfiguracja oczekuje, że zapisy zażądają potwierdzenia większości, dlatego zostaną zablokowane, dopóki większość członków przenoszących dane nie będzie dostępna.
- Migracja fragmentów między fragmentami również zostanie zagrożona, jeśli zestaw replik jest częścią klastra podzielonego na fragmenty.
- Nacisk na pamięć podręczną silnika pamięci masowej WiredTiger, jeśli nastąpi wycofanie i punkt zatwierdzenia większości nie może być zaawansowany.
Aby uniknąć tych konsekwencji, można wybrać konfigurację Główny-Dodatkowy-Dodatkowy, ponieważ zwiększa to odporność na błędy.
Uwaga:Odporność na awarie nie pojawia się tylko w przypadku awarii, ale także niektóre operacje systemowe, takie jak aktualizacja oprogramowania i normalna konserwacja, mogą zmusić członka do chwilowej niedostępności.
Zestawy replik rozmieszczone w dwóch lub więcej centrach danych
Wysoką dostępność można podnieść na inny poziom, rozprowadzając elementy zestawu replik w różnych geograficznie centrach danych. Takie podejście zwiększy redundancję, a także zapewni wysoką odporność na awarie w przypadku, gdy jakiekolwiek centrum danych stanie się niedostępne.
Jeśli wszyscy członkowie znajdują się w jednym centrum danych, zestaw replik jest podatny na awarie centrum danych, takie jak stany nieustalone sieci i przerwy w dostawie prądu.
Wskazane jest trzymanie co najmniej jednego członka w alternatywnym centrum danych, użyj nieparzystej liczby centrów danych i wybierz rozkład członków, który zaoferuje większość w wyborach lub przynajmniej dostarczy kopię danych w przypadku niepowodzenia.
Konfiguracja powinna zapewniać, że w przypadku awarii dowolnego centrum danych zestaw replik pozostanie zapisywalny, ponieważ pozostali członkowie mogą przeprowadzić wybory.
Dystrybuuj swoje dane co najmniej w trzech centrach danych.
Członkowie mogą być ograniczeni do zasobów lub mieć ograniczenia sieciowe, przez co nie mogą stać się głównymi w przypadku przełączenia awaryjnego. Możesz skonfigurować tych członków, aby nie stali się głównymi, nadając im priorytet 0.
Członkowie w centrum danych mogą mieć wyższy priorytet niż inne centra danych, aby nadać im priorytet głosowania, tak aby mogli wybrać pierwszorzędny przed członkami w innych centrach danych.
Wszyscy członkowie zestawu replik powinni mieć możliwość komunikowania się ze sobą.
Wnioski
Korzyści z replikacji można podnieść do bardziej obiecującego statusu, rozprowadzając członków w wielu centrach danych. To zasadniczo zwiększa odporność na uszkodzenia, oprócz zapewnienia nadmiarowości danych. Elementy zestawu Replica Set rozmieszczone w dwóch lub większej liczbie centrów danych zapewniają korzyści w porównaniu z pojedynczym centrum danych, takie jak:
Jeśli jedno z centrów danych ulegnie awarii, dane są nadal dostępne do odczytu, w przeciwieństwie do pojedynczej dystrybucji centrum danych.
Operacje zapisu mogą być nadal potwierdzane w przypadku awarii centrum danych z członkami mniejszościowymi.
Operacje odczytu mogą być nadal możliwe, jeśli centrum danych z większościowymi członkami głosującymi ulegnie awarii, w przeciwieństwie do przypadku pojedynczego centrum danych.
