Konfiguracja protokołów serwera
MongoDB 3.0 i wcześniejsze obsługują tylko jeden typ protokołu wdrażania serwera konfiguracji, który od MongoDB 3.2 jest określany jako starszy SCCC (Sync Cluster Connection Configuration). Wdrożenie SCCC ma 1 serwer konfiguracyjny (tylko programowanie) lub 3 serwery konfiguracyjne (produkcja).
MongoDB 3.2 wypiera protokół SCCC i obsługuje nowy typ wdrożenia:Config Servers as Replica Sets (CSRS). Wdrożenie CSRS ma takie same ograniczenia jak standardowy zestaw replik, który może mieć 1 serwer konfiguracyjny (tylko programowanie) lub do 50 serwerów (produkcja) jak w MongoDB 3.2. Zalecane są co najmniej 3 serwery CSRS w celu zapewnienia wysokiej dostępności we wdrożeniu produkcyjnym, ale dodatkowe serwery mogą być przydatne w przypadku wdrożeń rozproszonych geograficznie.
SCCC (Konfiguracja połączenia klastra synchronizacji)
Dzięki SCCC serwery konfiguracyjne są aktualizowane przy użyciu dwufazowego zatwierdzania protokół, który wymaga konsensusu wielu serwerów dla transakcji. Możesz użyć jednego serwera konfiguracyjnego do celów testowych/rozwojowych, ale w zastosowaniach produkcyjnych zawsze powinieneś mieć 3. Praktyczną odpowiedzią na to, dlaczego nie możesz używać tylko 2 (lub więcej niż 3) serwerów w MongoDB jest to, że baza kodu MongoDB tylko obsługuje 1 lub 3 serwery konfiguracyjne dla konfiguracji SCCC.
Trzy serwery zapewniają większą gwarancję spójności niż dwa serwery i pozwalają na działania konserwacyjne (na przykład tworzenie kopii zapasowych) na jednym serwerze konfiguracyjnym, przy jednoczesnym posiadaniu dwóch serwerów dostępnych dla Twoich mongos zapytać. Więcej niż trzy serwery wydłużyłyby czas wymagany do zatwierdzenia danych na wszystkich serwerach.
Metadane klastra podzielonego na fragmenty muszą być identyczne na wszystkich serwerach konfiguracji i są obsługiwane przez implementację fragmentowania MongoDB. Metadane zawierają podstawowe informacje o tym, które fragmenty aktualnie przechowują zakresy dokumentów (aka chunks ). W konfiguracji SCCC serwery konfiguracyjne nie zestaw replik, więc jeśli jeden lub więcej serwerów konfiguracyjnych jest w trybie offline, dane konfiguracyjne będą tylko do odczytu - w przeciwnym razie nie ma możliwości rozprzestrzenienia się danych na serwery konfiguracyjne w trybie offline, gdy będą one ponownie online.
Oczywiście 1 serwer konfiguracyjny nie zapewnia nadmiarowości ani kopii zapasowej. W przypadku 2 serwerów konfiguracyjnych potencjalny scenariusz awarii to sytuacja, w której serwery są dostępne, ale dane na serwerach nie zgadzają się (na przykład na jednym z serwerów wystąpiło pewne uszkodzenie danych). Dzięki 3 serwerom konfiguracyjnym możesz poprawić poprzedni scenariusz:2/3 serwerów może być spójnych i możesz zidentyfikować nieparzysty serwer.
CSRS (serwery konfiguracyjne jako zestawy replik)
MongoDB 3.2 przestaje używać trzech kopii lustrzanych mongod instancje serwerów konfiguracyjnych, począwszy od wersji 3.2, serwery konfiguracyjne są (domyślnie) wdrażane jako zestaw replik. Serwery konfiguracji zestawu replik muszą używać silnika pamięci masowej WiredTiger 3.2+ (lub innego silnika pamięci masowej, który obsługuje nowy readConcern
czytać semantykę izolacji). CSRS nie zezwala również na niektóre inne niż domyślne opcje konfiguracji zestawu replik (np. arbiterOnly , buildIndexes i slaveDelay ), które są nieodpowiednie dla przypadku użycia metadanych klastra podzielonego na fragmenty.
Wdrożenie CSRS poprawia spójność i dostępność serwerów konfiguracyjnych, ponieważ MongoDB może korzystać ze standardowych protokołów odczytu i zapisu zestawu replik do dzielenia danych konfiguracyjnych na fragmenty. Ponadto umożliwia to klasterowi podzielonemu na fragmenty mieć więcej niż 3 serwery konfiguracyjne, ponieważ zestaw replik może zawierać do 50 elementów (tak jak w MongoDB 3.2).
W przypadku wdrożenia CSRS dostępność zapisu zależy od utrzymania kworum członków, którzy mogą zobaczyć bieżący podstawowy zestaw replik. Na przykład zestaw replik składający się z 3 węzłów wymagałby 2 dostępnych członków do obsługi podstawowego. Można dodać dodatkowych członków, aby poprawić odporność na awarie , z zastrzeżeniem tych samych zasad wyborów
jako normalny zestaw replik. readConcern majority jest używany przez mongos aby upewnić się, że podzielone na fragmenty metadane klastra mogą być odczytywane tylko wtedy, gdy zostaną zatwierdzone do większości elementów zestawu replik i readPreference z nearest służy do kierowania żądań do najbliższego serwera konfiguracyjnego.
