Config Server-protocollen
MongoDB 3.0 en eerder ondersteunen slechts één type configuratieserverimplementatieprotocol dat vanaf MongoDB 3.2 de legacy SCCC (Sync Cluster Connection Configuration) wordt genoemd. Een SCCC-implementatie heeft ofwel 1 configuratieserver (alleen ontwikkeling) of 3 configuratieservers (productie).
MongoDB 3.2 deprecieert het SCCC-protocol en ondersteunt een nieuw implementatietype:Config Servers as Replica Sets (CSRS). Een CSRS-implementatie heeft dezelfde limieten als een standaard replicaset, die 1 configuratieserver (alleen ontwikkeling) of maximaal 50 servers (productie) kan hebben zoals bij MongoDB 3.2. Een minimum van 3 CSRS-servers wordt aanbevolen voor hoge beschikbaarheid in een productie-implementatie, maar extra servers kunnen handig zijn voor geografisch gedistribueerde implementaties.
SCCC (Sync Cluster Connection Configuration)
Met SCCC worden de configuratieservers bijgewerkt met behulp van een tweefasige commit protocol dat consensus vereist van meerdere servers voor een transactie. U kunt een enkele configuratieserver gebruiken voor test-/ontwikkelingsdoeleinden, maar in productiegebruik zou u er altijd 3 moeten hebben. Een praktisch antwoord waarom u niet slechts 2 (of meer dan 3) servers in MongoDB kunt gebruiken, is dat de MongoDB-codebasis alleen ondersteunt 1 of 3 configuratieservers voor een SCCC-configuratie.
Drie servers bieden een sterkere garantie voor consistentie dan twee servers, en zorgen voor onderhoudsactiviteiten (bijvoorbeeld back-ups) op één configuratieserver terwijl er nog steeds twee servers beschikbaar zijn voor uw mongos opvragen. Meer dan drie servers zouden de tijd verlengen die nodig is om gegevens op alle servers vast te leggen.
De metagegevens voor uw shard-cluster moeten identiek zijn op alle configuratieservers en worden onderhouden door de MongoDB-shardingimplementatie. De metadata bevatten de essentiële details van welke shards momenteel reeksen documenten bevatten (ook bekend als chunks ). In een SCCC-configuratie zijn configuratieservers niet een replicaset, dus als een of meer configuratieservers offline zijn, worden de configuratiegegevens alleen-lezen -- anders kunnen de gegevens niet worden doorgegeven aan de offline configuratieservers wanneer ze weer online zijn.
Het is duidelijk dat 1 configuratieserver geen redundantie of back-up biedt. Met 2 configuratieservers is een potentieel storingsscenario waar de servers beschikbaar zijn, maar de gegevens op de servers niet overeenkomen (bijvoorbeeld, een van de servers had wat gegevenscorruptie). Met 3 configuratieservers kun je het vorige scenario verbeteren:2/3 servers kunnen consistent zijn en je zou de vreemde server kunnen identificeren.
CSRS (configuratieservers als replicasets)
MongoDB 3.2 deprecieert het gebruik van drie gespiegelde mongod instances voor configuratieservers, en vanaf 3.2 worden configuratieservers (standaard) geïmplementeerd als een replicaset. Replicaset-configuratieservers moeten de WiredTiger 3.2+ opslagengine gebruiken (of een andere opslagengine die de nieuwe readConcern
lees isolatiesemantiek). CSRS verbiedt ook sommige niet-standaard configuratie-opties voor replicasets (bijv. arbiterOnly , buildIndexes , en slaveDelay ) die niet geschikt zijn voor het gebruik van shard-clustermetadata.
De CSRS-implementatie verbetert de consistentie en beschikbaarheid voor configuratieservers, aangezien MongoDB kan profiteren van de standaard lees- en schrijfprotocollen voor replicasets voor het sharden van configuratiegegevens. Bovendien kan een shard-cluster hierdoor meer dan 3 configuratieservers hebben, aangezien een replicaset tot 50 leden kan hebben (zoals bij MongoDB 3.2).
Bij een CSRS-implementatie is de schrijfbeschikbaarheid afhankelijk van het handhaven van een quorum van leden die de huidige primaire voor een replicaset kunnen zien. Voor een replicaset met 3 knooppunten zijn bijvoorbeeld 2 beschikbare leden nodig om een primaire te onderhouden. Extra leden kunnen worden toegevoegd voor verbeterde fouttolerantie , onderhevig aan dezelfde verkiezingsregels
als een normale replicaset. Een readConcern van majority wordt gebruikt door mongos om ervoor te zorgen dat metagegevens van shard-clusters alleen kunnen worden gelezen als deze zijn vastgelegd voor een meerderheid van de leden van de replicaset en een readPreference van nearest wordt gebruikt om verzoeken naar de dichtstbijzijnde configuratieserver te routeren.