Konfigurera serverprotokoll
MongoDB 3.0 och tidigare stöder endast en enda typ av konfigurationsserverdistributionsprotokoll som kallas den äldre SCCC (Sync Cluster Connection Configuration) från och med MongoDB 3.2. En SCCC-distribution har antingen 1 konfigurationsserver (endast utveckling) eller 3 konfigurationsservrar (produktion).
MongoDB 3.2 fasar ut SCCC-protokollet och stöder en ny distributionstyp:Config Servers as Replica Sets (CSRS). En CSRS-distribution har samma gränser som en standard replikuppsättning, som kan ha 1 konfigurationsserver (endast utveckling) eller upp till 50 servrar (produktion) som i MongoDB 3.2. Minst 3 CSRS-servrar rekommenderas för hög tillgänglighet i en produktionsinstallation, men ytterligare servrar kan vara användbara för geografiskt distribuerade distributioner.
SCCC (Sync Cluster Connection Configuration)
Med SCCC uppdateras konfigurationsservrarna med en tvåfasig commit protokoll som kräver konsensus från flera servrar för en transaktion. Du kan använda en enda konfigurationsserver för test-/utvecklingsändamål, men i produktionsanvändning bör du alltid ha 3. Ett praktiskt svar på varför du inte kan använda endast 2 (eller fler än 3) servrar i MongoDB är att MongoDB-kodbasen bara stöder 1 eller 3 konfigurationsservrar för en SCCC-konfiguration.
Tre servrar ger en starkare garanti för konsistens än två servrar och tillåter underhållsaktivitet (till exempel säkerhetskopior) på en konfigurationsserver samtidigt som de fortfarande har två servrar tillgängliga för dina mongos att fråga. Mer än tre servrar skulle öka den tid som krävs för att överföra data över alla servrar.
Metadata för ditt fragmenterade kluster måste vara identiskt över alla konfigurationsservrar och underhålls av MongoDB-shardingimplementeringen. Metadatan inkluderar de väsentliga detaljerna om vilka skärvor som för närvarande innehåller dokumentintervall (aka chunks ). I en SCCC-konfiguration är konfigurationsservrar inte en replikuppsättning, så om en eller flera konfigurationsservrar är offline kommer konfigurationsdatan att vara skrivskyddad -- annars finns det inget sätt för informationen att spridas till offlinekonfigurationsservrarna när de är online igen.
En konfigurationsserver ger uppenbarligen ingen redundans eller backup. Med 2 konfigurationsservrar är ett potentiellt felscenario där servrarna är tillgängliga men data på servrarna inte överensstämmer (till exempel hade en av servrarna viss datakorruption). Med 3 konfigurationsservrar kan du förbättra det tidigare scenariot:2/3 servrar kan vara konsekventa och du kan identifiera den udda servern.
CSRS (Config Servers as Replica Sets)
MongoDB 3.2 fasar ut användningen av tre speglade mongod instanser för konfigurationsservrar och från och med 3.2 distribueras konfigurationsservrar (som standard) som en replikuppsättning. Replica set config-servrar måste använda WiredTiger 3.2+ lagringsmotor (eller annan lagringsmotor som stöder den nya readConcern
läs isoleringssemantik). CSRS tillåter också vissa konfigurationsalternativ för replikuppsättningar som inte är standard (t.ex. arbiterOnly , buildIndexes och slaveDelay ) som är olämpliga för användningsfallet för fragmenterat klustermetadata.
CSRS-distributionen förbättrar konsistensen och tillgängligheten för konfigurationsservrar, eftersom MongoDB kan dra fördel av läs- och skrivprotokollen för standardreplika för att dela konfigurationsdata. Dessutom tillåter detta att ett fragmenterat kluster har mer än 3 konfigurationsservrar eftersom en replikuppsättning kan ha upp till 50 medlemmar (som i MongoDB 3.2).
Med en CSRS-distribution beror skrivtillgänglighet på att ett kvorum av medlemmar upprätthålls som kan se den nuvarande primära för en replikuppsättning. Till exempel skulle en replikuppsättning med 3 noder kräva 2 tillgängliga medlemmar för att upprätthålla en primär. Ytterligare medlemmar kan läggas till för förbättrad feltolerans , enligt samma valregler
som en vanlig replikuppsättning. En readConcern av majority används av mongos för att säkerställa att delad klustermetadata endast kan läsas när den är ansluten till en majoritet av replikuppsättningsmedlemmar och en readPreference av nearest används för att dirigera förfrågningar till närmaste konfigurationsserver.