Konfigurationsserverprotokoller
MongoDB 3.0 og tidligere understøtter kun en enkelt type konfigurationsserverimplementeringsprotokol, som omtales som den ældre SCCC (Sync Cluster Connection Configuration) fra MongoDB 3.2. En SCCC-installation har enten 1 konfigurationsserver (kun udvikling) eller 3 konfigurationsservere (produktion).
MongoDB 3.2 forælder SCCC-protokollen og understøtter en ny implementeringstype:Config Servers as Replica Sets (CSRS). En CSRS-implementering har de samme grænser som et standard replikasæt, som kan have 1 konfigurationsserver (kun udvikling) eller op til 50 servere (produktion) som ved MongoDB 3.2. Et minimum af 3 CSRS-servere anbefales for høj tilgængelighed i en produktionsinstallation, men yderligere servere kan være nyttige til geografisk distribuerede implementeringer.
SCCC (Sync Cluster Connection Configuration)
Med SCCC opdateres konfigurationsserverne ved hjælp af en tofaset commit protokol, som kræver konsensus fra flere servere for en transaktion. Du kan bruge en enkelt konfigurationsserver til test/udviklingsformål, men i produktionsbrug bør du altid have 3. Et praktisk svar på hvorfor du ikke kun kan bruge 2 (eller mere end 3) servere i MongoDB er, at MongoDB kodebasen kun understøtter 1 eller 3 konfigurationsservere til en SCCC-konfiguration.
Tre servere giver en stærkere garanti for ensartethed end to servere og giver mulighed for vedligeholdelsesaktivitet (f.eks. sikkerhedskopier) på én konfigurationsserver, mens der stadig er to servere tilgængelige til dine mongos at forespørge. Mere end tre servere ville øge den tid, der kræves til at overføre data på tværs af alle servere.
Metadataene for din sharded cluster skal være identiske på tværs af alle konfigurationsservere og vedligeholdes af MongoDB sharding-implementeringen. Metadataene inkluderer de væsentlige detaljer om, hvilke shards, der i øjeblikket rummer rækker af dokumenter (alias chunks ). I en SCCC-konfiguration er konfigurationsservere ikke et replikasæt, så hvis en eller flere konfigurationsservere er offline, vil konfigurationsdataene kun blive læst -- ellers er der ingen måde, hvorpå dataene kan spredes til offline konfigurationsserverne, når de er online igen.
Det er klart, at 1 konfigurationsserver ikke giver nogen redundans eller backup. Med 2 konfigurationsservere er et potentielt fejlscenarie, hvor serverne er tilgængelige, men dataene på serverne ikke stemmer overens (f.eks. havde en af serverne noget datakorruption). Med 3 konfigurationsservere kan du forbedre det tidligere scenarie:2/3 servere kan være konsistente, og du kan identificere den ulige server ude.
CSRS (Config Servers as Replica Sets)
MongoDB 3.2 fraskriver brugen af tre spejlede mongod instanser til konfigurationsservere, og fra og med 3.2 er konfigurationsservere (som standard) implementeret som et replikasæt. Replica set config-servere skal bruge WiredTiger 3.2+ storage-motoren (eller en anden storage-motor, der understøtter den nye readConcern
læse isolationssemantik). CSRS tillader også nogle ikke-standard konfigurationsmuligheder for replikasæt (f.eks. arbiterOnly , buildIndexes og slaveDelay ), der er uegnede til brugen af sharded cluster-metadata.
CSRS-implementeringen forbedrer konsistensen og tilgængeligheden for konfigurationsservere, da MongoDB kan drage fordel af standard replikasættets læse- og skriveprotokoller til deling af konfigurationsdata. Derudover tillader dette en sharded klynge at have mere end 3 konfigurationsservere, da et replikasæt kan have op til 50 medlemmer (som ved MongoDB 3.2).
Med en CSRS-implementering afhænger skrivetilgængeligheden af at opretholde et kvorum af medlemmer, der kan se det aktuelle primære for et replikasæt. For eksempel ville et 3-node replikasæt kræve 2 tilgængelige medlemmer for at opretholde et primært. Yderligere medlemmer kan tilføjes for at forbedre fejltolerance , underlagt de samme valgregler
som et normalt replikasæt. En readConcern af majority bruges af mongos for at sikre, at opdelte klynge-metadata kun kan læses, når de er forpligtet til et flertal af replikasætmedlemmer og en readPreference af nearest bruges til at dirigere anmodninger til den nærmeste konfigurationsserver.