Serverprotokolle konfigurieren
MongoDB 3.0 und frühere Versionen unterstützen nur einen einzigen Typ von Konfigurationsserver-Bereitstellungsprotokoll, der ab MongoDB 3.2 als Legacy-SCCC (Sync Cluster Connection Configuration) bezeichnet wird. Eine SCCC-Bereitstellung hat entweder 1 Konfigurationsserver (nur Entwicklung) oder 3 Konfigurationsserver (Produktion).
MongoDB 3.2 setzt das SCCC-Protokoll außer Kraft und unterstützt einen neuen Bereitstellungstyp:Config Servers as Replica Sets (CSRS). Eine CSRS-Bereitstellung hat die gleichen Beschränkungen wie ein Standardreplikatsatz, der 1 Konfigurationsserver (nur Entwicklung) oder bis zu 50 Server (Produktion) wie bei MongoDB 3.2 haben kann. Mindestens 3 CSRS-Server werden für Hochverfügbarkeit in einer Produktionsbereitstellung empfohlen, aber zusätzliche Server können für geografisch verteilte Bereitstellungen nützlich sein.
SCCC (Konfiguration der Sync-Cluster-Verbindung)
Mit SCCC werden die Konfigurationsserver mit einem Zwei-Phasen-Commit aktualisiert Protokoll, das für eine Transaktion den Konsens mehrerer Server erfordert. Sie können einen einzigen Konfigurationsserver für Test-/Entwicklungszwecke verwenden, aber im Produktionseinsatz sollten Sie immer 3 haben. Eine praktische Antwort darauf, warum Sie nicht nur 2 (oder mehr als 3) Server in MongoDB verwenden können, ist, dass die MongoDB-Codebasis nur unterstützt 1 oder 3 Konfigurationsserver für eine SCCC-Konfiguration.
Drei Server bieten eine stärkere Konsistenzgarantie als zwei Server und ermöglichen Wartungsaktivitäten (z. B. Backups) auf einem Konfigurationsserver, während immer noch zwei Server für Ihre mongos verfügbar sind Abfragen. Mehr als drei Server würden die Zeit erhöhen, die erforderlich ist, um Daten auf allen Servern festzuschreiben.
Die Metadaten für Ihren Sharding-Cluster müssen auf allen Konfigurationsservern identisch sein und werden von der MongoDB-Sharding-Implementierung verwaltet. Die Metadaten enthalten die wesentlichen Details darüber, welche Shards derzeit Dokumentbereiche (auch bekannt als chunks) enthalten ). In einer SCCC-Konfiguration sind Konfigurationsserver nicht ein Replikatsatz, wenn also ein oder mehrere Konfigurationsserver offline sind, dann werden die Konfigurationsdaten schreibgeschützt -- andernfalls gibt es keine Möglichkeit, die Daten an die Offline-Konfigurationsserver weiterzugeben, wenn sie wieder online sind.
Offensichtlich bietet 1 Konfigurationsserver keine Redundanz oder Sicherung. Bei 2 Konfigurationsservern besteht ein mögliches Ausfallszenario darin, dass die Server verfügbar sind, aber die Daten auf den Servern nicht übereinstimmen (beispielsweise hatte einer der Server eine Datenbeschädigung). Mit 3 Konfigurationsservern können Sie das vorherige Szenario verbessern:2/3 Server könnten konsistent sein und Sie könnten den ungeraden Server identifizieren.
CSRS (Config Servers as Replica Sets)
MongoDB 3.2 missbilligt die Verwendung von drei gespiegelten mongod Instanzen für Konfigurationsserver, und ab Version 3.2 werden Konfigurationsserver (standardmäßig) als Replikatsatz bereitgestellt. Replikatsatz-Konfigurationsserver müssen die Speicher-Engine WiredTiger 3.2+ verwenden (oder eine andere Speicher-Engine, die den neuen readConcern
Read-Isolationssemantik). CSRS verbietet auch einige nicht standardmäßige Replikatsatz-Konfigurationsoptionen (z. B. arbiterOnly , buildIndexes und slaveDelay ), die für den Anwendungsfall Sharding-Cluster-Metadaten ungeeignet sind.
Die CSRS-Bereitstellung verbessert die Konsistenz und Verfügbarkeit für Konfigurationsserver, da MongoDB die standardmäßigen Lese- und Schreibprotokolle für Replikatsätze zum Sharding von Konfigurationsdaten nutzen kann. Darüber hinaus kann ein Sharding-Cluster mehr als 3 Konfigurationsserver haben, da ein Replikatsatz bis zu 50 Mitglieder haben kann (wie bei MongoDB 3.2).
Bei einer CSRS-Bereitstellung hängt die Schreibverfügbarkeit davon ab, dass ein Quorum von Mitgliedern aufrechterhalten wird, die den aktuellen Primärknoten für einen Replikatsatz sehen können. Beispielsweise würde ein Replikatsatz mit 3 Knoten 2 verfügbare Mitglieder erfordern, um einen primären Knoten zu verwalten. Zusätzliche Mitglieder können für eine verbesserte FehlertoleranzreadConcern der majority wird von mongos verwendet um sicherzustellen, dass Sharding-Cluster-Metadaten nur gelesen werden können, wenn sie an eine Mehrheit von Replikatsatzmitgliedern und eine readPreference festgeschrieben sind von nearest wird verwendet, um Anfragen an den nächsten Konfigurationsserver weiterzuleiten.
