Konfigurovat protokoly serveru
MongoDB 3.0 a starší podporují pouze jeden typ protokolu nasazení konfiguračního serveru, který je od MongoDB 3.2 označován jako starší SCCC (Sync Cluster Connection Configuration). Nasazení SCCC má buď 1 konfigurační server (pouze pro vývoj) nebo 3 konfigurační servery (produkce).
MongoDB 3.2 zastarává protokol SCCC a podporuje nový typ nasazení:Config Servers as Replica Sets (CSRS). Nasazení CSRS má stejné limity jako standardní sada replik, která může mít 1 konfigurační server (pouze pro vývoj) nebo až 50 serverů (produkce) jako v MongoDB 3.2. Pro vysokou dostupnost v produkčním nasazení se doporučují minimálně 3 servery CSRS, ale pro geograficky distribuované nasazení mohou být užitečné další servery.
SCCC (Konfigurace připojení synchronizačního clusteru)
S SCCC jsou konfigurační servery aktualizovány pomocí dvoufázového potvrzení protokol, který pro transakci vyžaduje souhlas více serverů. Pro účely testování/vývoje můžete použít jeden konfigurační server, ale při produkčním použití byste měli mít vždy 3. Praktickou odpovědí, proč nemůžete v MongoDB používat pouze 2 (nebo více než 3) servery, je, že základ kódu MongoDB pouze podporuje 1 nebo 3 konfigurační servery pro konfiguraci SCCC.
Tři servery poskytují silnější záruku konzistence než dva servery a umožňují údržbu (například zálohování) na jednom konfiguračním serveru, přičemž pro vaše mongos máte stále k dispozici dva servery. dotazovat se. Více než tři servery by prodloužily čas potřebný k potvrzení dat na všech serverech.
Metadata pro váš sdílený cluster musí být identická na všech konfiguračních serverech a jsou udržována implementací shardingu MongoDB. Metadata obsahují základní podrobnosti o tom, které úlomky aktuálně obsahují rozsahy dokumentů (neboli chunks ). V konfiguraci SCCC konfigurační servery nejsou sadu replik, takže pokud je jeden nebo více konfiguračních serverů offline, konfigurační data budou pouze pro čtení – jinak neexistuje žádný způsob, jak se data šířit na offline konfigurační servery, když jsou opět online.
Je zřejmé, že 1 konfigurační server neposkytuje žádnou redundanci ani zálohu. U 2 konfiguračních serverů je možný scénář selhání, kdy jsou servery dostupné, ale data na serverech nesouhlasí (například jeden ze serverů měl nějaké poškození dat). Se 3 konfiguračními servery můžete vylepšit předchozí scénář:2/3 serverů mohou být konzistentní a můžete identifikovat lichý server mimo.
CSRS (Konfigurovat servery jako sady replik)
MongoDB 3.2 zavrhuje použití tří zrcadlených mongod instance pro konfigurační servery a počínaje verzí 3.2 jsou konfigurační servery (ve výchozím nastavení) nasazeny jako sada replik. Servery konfigurace sady replik musí používat úložný modul WiredTiger 3.2+ (nebo jiný úložný modul, který podporuje nový readConcern
číst sémantiku izolace). CSRS také zakazuje některé jiné než výchozí možnosti konfigurace sady replik (např. arbiterOnly , buildIndexes a slaveDelay ), které nejsou vhodné pro případ použití metadat sdíleného clusteru.
Nasazení CSRS zlepšuje konzistenci a dostupnost pro konfigurační servery, protože MongoDB může využívat výhod standardních protokolů pro čtení a zápis sady replik pro sdílení konfiguračních dat. Navíc to umožňuje, aby měl sdílený cluster více než 3 konfigurační servery, protože sada replik může mít až 50 členů (jako v MongoDB 3.2).
Při nasazení CSRS závisí dostupnost zápisu na udržování kvora členů, kteří mohou vidět aktuální primární sadu replik. Například sada replik se 3 uzly by vyžadovala 2 dostupné členy pro údržbu primární. Lze přidat další členy pro lepší odolnost vůči chybám , podléhají stejným pravidlům voleb
jako běžnou sadu replik. readConcern majority používá mongos aby bylo zajištěno, že sdílená metadata clusteru bude možné číst až poté, co jsou potvrzena většině členů sady replik a readPreference z nearest se používá ke směrování požadavků na nejbližší konfigurační server.