Configura protocolli server
MongoDB 3.0 e versioni precedenti supportano solo un singolo tipo di protocollo di distribuzione del server di configurazione denominato SCCC (Sync Cluster Connection Configuration) legacy a partire da MongoDB 3.2. Una distribuzione SCCC ha 1 server di configurazione (solo sviluppo) o 3 server di configurazione (produzione).
MongoDB 3.2 depreca il protocollo SCCC e supporta un nuovo tipo di distribuzione:Config Servers as Replica Sets (CSRS). Una distribuzione CSRS ha gli stessi limiti di un set di repliche standard, che può avere 1 server di configurazione (solo sviluppo) o fino a 50 server (produzione) come in MongoDB 3.2. Si consiglia un minimo di 3 server CSRS per un'elevata disponibilità in una distribuzione di produzione, ma potrebbero essere utili server aggiuntivi per distribuzioni distribuite geograficamente.
SCCC (Configurazione connessione cluster di sincronizzazione)
Con SCCC, i server di configurazione vengono aggiornati utilizzando un commit a due fasi protocollo che richiede il consenso di più server per una transazione. Puoi utilizzare un singolo server di configurazione per scopi di test/sviluppo, ma nell'utilizzo in produzione dovresti sempre averne 3. Una risposta pratica al motivo per cui non puoi utilizzare solo 2 (o più di 3) server in MongoDB è che la base di codice MongoDB solo supporta 1 o 3 server di configurazione per una configurazione SCCC.
Tre server forniscono una maggiore garanzia di coerenza rispetto a due server e consentono attività di manutenzione (ad esempio backup) su un server di configurazione pur avendo due server disponibili per i tuoi mongos interrogare. Più di tre server aumenterebbero il tempo necessario per eseguire il commit dei dati su tutti i server.
I metadati per il tuo cluster partizionato devono essere identici su tutti i server di configurazione e sono gestiti dall'implementazione di partizionamento orizzontale MongoDB. I metadati includono i dettagli essenziali di cui gli shard attualmente contengono intervalli di documenti (ovvero chunks ). In una configurazione SCCC, i server di configurazione non un set di repliche, quindi se uno o più server di configurazione sono offline, i dati di configurazione saranno di sola lettura, altrimenti non ci sono mezzi per propagare i dati ai server di configurazione offline quando sono di nuovo online.
Chiaramente 1 server di configurazione non fornisce ridondanza o backup. Con 2 server di configurazione, un potenziale scenario di errore è quello in cui i server sono disponibili ma i dati sui server non sono d'accordo (ad esempio, uno dei server ha danneggiato i dati). Con 3 server di configurazione puoi migliorare lo scenario precedente:2/3 server potrebbero essere coerenti e potresti identificare il server dispari fuori.
CSRS (Configura server come set di repliche)
MongoDB 3.2 depreca l'uso di tre mongod con mirroring le istanze per i server di configurazione e a partire dalla versione 3.2 i server di configurazione vengono distribuiti (per impostazione predefinita) come set di repliche. I server di configurazione del set di repliche devono utilizzare il motore di archiviazione WiredTiger 3.2+ (o un altro motore di archiviazione che supporta il nuovo readConcern
leggere la semantica di isolamento). CSRS non consente inoltre alcune opzioni di configurazione del set di repliche non predefinite (ad es. arbiterOnly , buildIndexes e slaveDelay ) che non sono adatti al caso d'uso dei metadati del cluster partizionato.
La distribuzione CSRS migliora la coerenza e la disponibilità per i server di configurazione, poiché MongoDB può sfruttare i protocolli di lettura e scrittura del set di repliche standard per lo sharding dei dati di configurazione. Inoltre, ciò consente a un cluster partizionato di avere più di 3 server di configurazione poiché un set di repliche può avere fino a 50 membri (come in MongoDB 3.2).
Con una distribuzione CSRS, la disponibilità in scrittura dipende dal mantenimento di un quorum di membri in grado di visualizzare l'elemento primario corrente per un set di repliche. Ad esempio, un set di repliche a 3 nodi richiederebbe 2 membri disponibili per mantenere un primario. È possibile aggiungere altri membri per una migliore tolleranza ai guasti , soggetto alle stesse regole elettorali
come un normale set di repliche. Un readConcern di majority è usato da mongos per garantire che i metadati del cluster partizionato possano essere letti solo dopo che sono stati assegnati alla maggior parte dei membri del set di repliche e a un readPreference di nearest viene utilizzato per instradare le richieste al server di configurazione più vicino.
