Co to jest replikacja łańcuchowa?
Kiedy mówimy o replikacji, mamy na myśli proces tworzenia nadmiarowych kopii danych w celu spełnienia kryteriów projektowych dotyczących dostępności danych. Replikacja łańcuchowa odnosi się zatem do liniowego uporządkowania serwerów MongoDB w celu utworzenia zsynchronizowanego łańcucha. Łańcuch zawiera węzeł główny, za którym następują serwery pomocnicze ułożone liniowo. Jak sugeruje łańcuch słów, serwer znajdujący się najbliżej głównego serwera replikuje z niego, podczas gdy każdy kolejny kolejny serwer pomocniczy wykonuje replikację z poprzedniego pomocniczego serwera MongoDB. Jest to główna różnica między replikacją łańcuchową a replikacją normalną. Replikacja łańcuchowa występuje, gdy węzeł drugorzędny wybiera swój cel przy użyciu czasu ping lub gdy najbliższy węzeł jest drugorzędny. Chociaż replikacja łańcucha, jak się wydaje, zmniejsza obciążenie węzła podstawowego, może powodować opóźnienie replikacji.
Dlaczego warto korzystać z replikacji łańcuchowej?
Infrastruktury systemowe czasami ulegają nieprzewidywalnym awariom, które prowadzą do utraty serwera, a tym samym wpływają na dostępność. Replikacja zapewnia, że nieprzewidywalne awarie nie wpływają na dostępność. Replikacja umożliwia ponadto odzyskanie sprawności po awarii sprzętu i przerwach w świadczeniu usług. Zarówno replikacja łańcuchowa, jak i niełańcuchowa służą temu celowi zapewnienia dostępności pomimo awarii systemu. Po ustaleniu, że replikacja jest ważna, możesz zapytać, dlaczego w szczególności stosuje się replikację łańcuchową. Nie ma różnicy wydajności między replikacją łańcuchową i niełańcuchową w MongoDb. W obu przypadkach, gdy węzeł główny ulegnie awarii, serwery pomocnicze głosują na nowy działający serwer główny, a zatem w obu przypadkach nie ma to wpływu na zapis i odczyt danych. Replikacja łańcuchowa jest jednak domyślnym typem replikacji w MongoDb.
Jak skonfigurować replikę łańcucha
Domyślnie replikacja łańcuchowa jest włączona w MongoDB. Dlatego omówimy proces dezaktywacji replikacji łańcucha. Głównym powodem wyłączenia replikacji łańcucha jest to, że powoduje opóźnienie. Zaleta replikacji łańcucha jest jednak wyższa niż wada opóźnień i dlatego w większości przypadków jej dezaktywacja nie jest konieczna. Na wypadek, gdyby replikacja łańcucha nie była domyślnie aktywna, poniższe polecenia pomogą w aktywacji.
cfg = rs.config()
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)Ten proces jest odwracalny. Gdy zostaniesz zmuszony do dezaktywacji replikacji łańcucha, następujący proces jest przestrzegany religijnie.
cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)Wskazówki i wskazówki dotyczące replikacji łańcucha
Najbardziej przerażającym ograniczeniem replikacji łańcucha jest opóźnienie replikacji. Opóźnienie replikacji odnosi się do opóźnienia, które występuje między wykonaniem operacji na serwerze podstawowym a wykonaniem tej samej operacji na serwerze pomocniczym. Chociaż jest to naturalnie niemożliwe, zawsze pożądane jest, aby szybkość replikacji była bardzo duża w tym opóźnieniu replikacji, wynosząca zero. Aby uniknąć lub zminimalizować opóźnienie replikacji do zera, rozważnym kryterium projektowym jest użycie hostów podstawowych i pomocniczych o tych samych specyfikacjach w zakresie procesora, pamięci RAM, IO i specyfikacji związanych z siecią.
Chociaż replikacja łańcuchowa zapewnia dostępność danych, replikacja łańcuchowa może być używana razem z kronikowaniem. Kronikowanie zapewnia bezpieczeństwo danych dzięki zapisywaniu w dzienniku, który jest regularnie opróżniany na dysk. Gdy te dwa są połączone, trzy serwery są zapisywane na każde żądanie zapisu, w przeciwieństwie do samej replikacji łańcuchowej, gdzie tylko dwa serwery są zapisywane na żądanie zapisu.
Kolejną ważną wskazówką jest używanie w z replikacją. Parametr w kontroluje liczbę serwerów, na których należy zapisać odpowiedź przed zwróceniem powodzenia. Gdy parametr w jest ustawiony, getlasterror sprawdza oplog serwerów i czeka, aż podana liczba serwerów „w” wykona operację.
Korzystanie z narzędzia do monitorowania, takiego jak MongoDB Monitoring Service (MMS) lub ClusterControl, pozwala uzyskać status węzłów repliki i wizualizować zmiany w czasie. Na przykład w MMS można znaleźć wykresy opóźnień replikacji węzłów drugorzędnych pokazujące różnice w czasie opóźnienia replikacji.
Pomiar wydajności replikacji łańcucha
Wiesz już, że najważniejszym parametrem wydajności replikacji łańcuchowej jest czas opóźnienia replikacji. Dlatego omówimy, jak przetestować okres opóźnienia replikacji. Ten test można wykonać za pomocą skryptu powłoki MongoDb. Aby wykonać test opóźnienia replikacji, porównujemy oplog ostatniego zdarzenia w węźle podstawowym i oplog ostatniego zdarzenia w węźle drugorzędnym.
Aby sprawdzić informacje o węźle podstawowym, uruchamiamy następujący kod.
db.printSlaveReplicationInfo()Powyższe polecenie dostarczy informacji o wszystkich ostatnich operacjach na węźle podstawowym. Wyniki powinny wyglądać jak poniżej.
rs-ds046297:PRIMARY db.printSlaveReplicationInfo()
source: ds046297-a1.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)
source: ds046297-a2.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)Po uzyskaniu oploga dla głównego węzła, jesteśmy teraz zainteresowani oplogiem dla drugiego węzła. Następujące polecenie pomoże nam uzyskać oplog.
db.printReplicationInfo()To polecenie dostarczy dane wyjściowe ze szczegółami dotyczącymi rozmiaru oploga, długości dziennika, czasu pierwszego zdarzenia oploga, czasu ostatniego zdarzenia oploga i czasu bieżącego. Wyniki są wyświetlane poniżej.
rs-ds046297:PRIMARY db.printReplicationInfo()
configured oplog size: 1024MB
log length start to end: 5589 secs (1.55hrs)
oplog first event time: Tue Mar 05 2013 06:15:19 GMT-0800 (PST)
oplog last event time: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
now: Tue Mar 05 2013 09:53:07 GMT-0800 (PST)Ostatnia synchronizacja z dziennika głównego serwera głównego miała miejsce we wtorek, 5 marca 2013 r., 07:48:19 GMT-0800 (PST). W oplogu serwera pomocniczego ostatnia operacja miała miejsce 5 marca 2013 r. o godz. 07:48:19 GMT-0800 (PST). Opóźnienie replikacji wynosiło zero i dlatego nasz system replikacji łańcuchowej działa prawidłowo. Opóźnienie replikacji może się jednak różnić w zależności od ilości zmian, które należy zreplikować.
