Erstellen Sie in Rekordzeit ein robustes MongoDB-Replikatset (4 Methoden)

MongoDB ist eine NoSQL-Datenbank, die JSON-ähnliche Dokumente mit dynamischen Schemas verwendet. Bei der Arbeit mit Datenbanken ist es immer gut, einen Notfallplan zu haben, falls einer Ihrer Datenbankserver ausfällt. Sidebar, können Sie die Wahrscheinlichkeit verringern, dass dies geschieht, indem Sie ein raffiniertes Verwaltungstool für Ihre WordPress-Site nutzen.

Aus diesem Grund ist es sinnvoll, viele Kopien Ihrer Daten zu haben. Es reduziert auch Leselatenzen. Gleichzeitig kann es die Skalierbarkeit und Verfügbarkeit der Datenbank verbessern. Hier kommt die Replikation ins Spiel. Sie ist definiert als die Praxis, Daten über mehrere Datenbanken hinweg zu synchronisieren.

In diesem Artikel werden wir uns mit den verschiedenen herausragenden Aspekten der MongoDB-Replikation befassen, wie z. B. ihren Funktionen und Mechanismen, um nur einige zu nennen.

Was ist Replikation in MongoDB?

In MongoDB führen Replikatsätze die Replikation durch. Dies ist eine Gruppe von Servern, die denselben Datensatz durch Replikation verwalten. Sie können sogar die MongoDB-Replikation als Teil des Lastenausgleichs verwenden. Hier können Sie je nach Anwendungsfall die Schreib- und Leseoperationen auf alle Instanzen verteilen.

Was ist ein MongoDB-Replikatsatz?

Jede Instanz von MongoDB, die Teil eines bestimmten Replikatsatzes ist, ist ein Mitglied. Jeder Replikatsatz muss ein primäres Mitglied und mindestens ein sekundäres Mitglied haben.

Das primäre Mitglied ist der primäre Zugriffspunkt für Transaktionen mit dem Replikatsatz. Es ist auch das einzige Mitglied, das Schreibvorgänge akzeptieren kann. Bei der Replikation wird zunächst das Oplog (Operations Log) des Primärservers kopiert. Als nächstes wiederholt es die protokollierten Änderungen an den jeweiligen Datensätzen der sekundären Datenbanken. Daher kann jeder Replikatsatz jeweils nur ein primäres Mitglied haben. Verschiedene Primärdatenbanken, die Schreiboperationen empfangen, können Datenkonflikte verursachen.

Normalerweise fragen die Anwendungen nur das primäre Mitglied nach Schreib- und Lesevorgängen ab. Sie können Ihr Setup so gestalten, dass es von einem oder mehreren der sekundären Mitglieder liest. Die asynchrone Datenübertragung kann dazu führen, dass die Lesevorgänge sekundärer Knoten alte Daten bereitstellen. Daher ist eine solche Anordnung nicht für jeden Anwendungsfall ideal.

Replikat-Set-Funktionen

Der automatische Failover-Mechanismus hebt die Replikat-Sets von MongoDB von der Konkurrenz ab. In Abwesenheit eines Primärknotens wählt eine automatische Wahl unter den Sekundärknoten einen neuen Primärknoten aus.

MongoDB-Replikatsatz vs. MongoDB-Cluster

Ein MongoDB-Replikatsatz erstellt verschiedene Kopien desselben Datensatzes über die Replikatsatzknoten hinweg. Das Hauptziel eines Replikats ist:

• Bieten Sie eine integrierte Backup-Lösung an
• Erhöhen Sie die Datenverfügbarkeit

Ein MongoDB-Cluster ist ein ganz anderes Ballspiel. Es verteilt die Daten über einen Shard-Schlüssel auf viele Knoten. Dieser Prozess fragmentiert die Daten in viele Teile, die Shards genannt werden. Als nächstes kopiert es jeden Shard auf einen anderen Knoten. Ein Cluster zielt darauf ab, große Datensätze und Operationen mit hohem Durchsatz zu unterstützen. Dies wird durch horizontales Skalieren der Arbeitslast erreicht.

Hier ist der Unterschied zwischen einem Replikatsatz und einem Cluster, in einfachen Worten:

• Ein Cluster verteilt die Arbeitslast. Es speichert auch Datenfragmente (Shards) auf vielen Servern.
• Ein Replikatsatz dupliziert den Datensatz vollständig.

Mit MongoDB können Sie diese Funktionalitäten kombinieren, indem Sie einen Sharding-Cluster erstellen. Hier können Sie jeden Shard auf einen sekundären Server replizieren. Dadurch kann ein Shard eine hohe Redundanz und Datenverfügbarkeit bieten.

Die Wartung und Einrichtung eines Replikats kann technisch anspruchsvoll und zeitaufwändig sein. Und den richtigen Hosting-Service finden? Das sind ganz andere Kopfschmerzen. Bei so vielen Optionen da draußen ist es einfach, Stunden mit der Recherche zu verschwenden, anstatt Ihr Geschäft aufzubauen.

Lassen Sie mich Ihnen einen kurzen Überblick über ein Tool geben, das all dies und noch viel mehr kann, damit Sie es wieder mit Ihrem Service / Produkt vernichten können.

Kinstas Application Hosting-Lösung, der über 55.000 Entwickler vertrauen, können Sie in nur 3 einfachen Schritten in Betrieb nehmen. Wenn das zu gut klingt, um wahr zu sein, hier sind einige weitere Vorteile der Verwendung von Kinsta:

• Genieße eine bessere Leistung mit den internen Verbindungen von Kinsta : Vergiss deine Kämpfe mit gemeinsam genutzten Datenbanken. Wechseln Sie zu dedizierten Datenbanken mit internen Verbindungen, die keine Beschränkungen für die Anzahl der Abfragen oder Zeilen haben. Kinsta ist schneller, sicherer und stellt dir keine internen Bandbreiten/Datenverkehr in Rechnung.
• Ein auf Entwickler zugeschnittener Funktionsumfang : Skalieren Sie Ihre Anwendung auf der robusten Plattform, die Gmail, YouTube und die Google-Suche unterstützt. Seien Sie versichert, hier sind Sie in den besten Händen.
• Genießen Sie unvergleichliche Geschwindigkeiten mit einem Rechenzentrum Ihrer Wahl : Wählen Sie die Region, die für Sie und Ihre Kunden am besten geeignet ist. Mit über 25 Rechenzentren zur Auswahl sorgen die über 275 PoPs von Kinsta für maximale Geschwindigkeit und eine globale Präsenz für Ihre Website.

Probieren Sie die Anwendungshosting-Lösung von Kinsta noch heute kostenlos aus!

Wie funktioniert die Replikation in MongoDB?

In MongoDB senden Sie Writer-Vorgänge an den primären Server (Knoten). Der primäre Server weist die Vorgänge über sekundäre Server zu und repliziert die Daten.

Drei Arten von MongoDB-Knoten

Von den drei Arten von MongoDB-Knoten sind zwei zuvor aufgetaucht: primäre und sekundäre Knoten. Der dritte Typ von MongoDB-Knoten, der sich während der Replikation als nützlich erweist, ist ein Arbiter. Der Arbiter-Knoten hat keine Kopie des Datensatzes und kann nicht primär werden. Allerdings nimmt der Schiedsrichter an den Wahlen zur Vorwahl teil.

Wir haben bereits erwähnt, was passiert, wenn der primäre Knoten ausfällt, aber was, wenn die sekundären Knoten den Staub beißen? In diesem Szenario wird der primäre Knoten sekundär und die Datenbank wird unerreichbar.

Mitgliederwahl

Die Wahlen können in den folgenden Szenarien stattfinden:

• Initialisieren eines Replikatsatzes
• Verlust der Konnektivität zum primären Knoten (der durch Heartbeats erkannt werden kann)
• Wartung eines Replikatsatzes mit rs.reconfig oder stepDown -Methoden
• Hinzufügen eines neuen Knotens zu einem vorhandenen Replikatsatz

Ein Replica-Set kann bis zu 50 Mitglieder haben, aber nur 7 oder weniger können bei einer Wahl abstimmen.

Die durchschnittliche Zeit, bevor ein Cluster einen neuen Primary wählt, sollte 12 Sekunden nicht überschreiten. Der Wahlalgorithmus versucht, die Sekundärseite mit der höchsten Priorität verfügbar zu haben. Gleichzeitig können die Mitglieder mit einem Prioritätswert von 0 keine Vorwahlen werden und nehmen nicht an der Wahl teil.

Die Schreibsorge

Aus Gründen der Dauerhaftigkeit haben Schreibvorgänge einen Rahmen, um die Daten in eine bestimmte Anzahl von Knoten zu kopieren. Damit können Sie dem Kunden sogar Feedback geben. Dieses Framework wird auch als „Write Concern“ bezeichnet. Es hat datentragende Mitglieder, die eine Schreibbedenken bestätigen müssen, bevor die Operation als erfolgreich zurückkehrt. Im Allgemeinen haben die Replikatsätze einen Wert von 1 als Schreibanliegen. Daher sollte nur der Primäre den Schreibvorgang bestätigen, bevor er die Bestätigung des Schreibvorgangs zurücksendet.

Sie können sogar die Anzahl der Mitglieder erhöhen, die zum Bestätigen des Schreibvorgangs erforderlich sind. Es gibt keine Obergrenze für die Anzahl der Mitglieder, die Sie haben können. Aber wenn die Zahlen hoch sind, müssen Sie mit einer hohen Latenzzeit umgehen. Dies liegt daran, dass der Client auf eine Bestätigung von allen Mitgliedern warten muss. Außerdem können Sie das Schreiben der Betroffenheit der „Mehrheit“ festlegen. Damit rechnet mehr als die Hälfte der Mitglieder nach Erhalt ihrer Zusage.

Vorlieben lesen

Für die Lesevorgänge können Sie die Leseeinstellung angeben, die beschreibt, wie die Datenbank die Abfrage an Mitglieder des Replikatsatzes weiterleitet. Im Allgemeinen empfängt der primäre Knoten die Leseoperation, aber der Client kann eine Lesepräferenz angeben, um die Leseoperationen an sekundäre Knoten zu senden. Hier sind die Optionen für die Lesepräferenz:

• primaryPreferred : Normalerweise kommen die Lesevorgänge vom primären Knoten, aber wenn dieser nicht verfügbar ist, werden die Daten von den sekundären Knoten gezogen.
• primary : Alle Leseoperationen stammen vom primären Knoten.
• sekundäre : Alle Leseoperationen werden von den sekundären Knoten ausgeführt.
• next : Hier werden die Leseanfragen an den nächstgelegenen erreichbaren Knoten geleitet, der durch Ausführen des ping Befehls ermittelt werden kann. Das Ergebnis von Lesevorgängen kann von jedem Mitglied des Replikatsatzes stammen, unabhängig davon, ob es sich um das primäre oder das sekundäre handelt.
• secondaryPreferred : Hier kommen die meisten Lesevorgänge von den sekundären Knoten, aber wenn keiner davon verfügbar ist, werden die Daten vom primären Knoten genommen.

Synchronisierung von Replikationssatzdaten

Um aktuelle Kopien des freigegebenen Datensatzes zu erhalten, replizieren oder synchronisieren sekundäre Mitglieder eines Replikatsatzes Daten von anderen Mitgliedern.

MongoDB nutzt zwei Formen der Datensynchronisierung. Anfängliche Synchronisierung, um neue Mitglieder mit dem vollständigen Datensatz zu füllen. Replikation zur Durchführung laufender Änderungen am gesamten Datenbestand.

Anfängliche Synchronisierung

Während der anfänglichen Synchronisierung führt ein sekundärer Knoten den Befehl init sync aus, um alle Daten vom primären Knoten mit einem anderen sekundären Knoten zu synchronisieren, der die neuesten Daten enthält. Daher nutzt der Sekundärknoten konsequent die tailable cursor Funktion, um die neuesten Oplog-Einträge innerhalb der local.oplog.rs-Sammlung des Primärknotens abzufragen, und wendet diese Operationen innerhalb dieser Oplog-Einträge an.

Ab MongoDB 5.2 können anfängliche Synchronisierungen auf Dateikopien basieren oder logisch sein.

Logische Synchronisierung

Wenn Sie eine logische Synchronisierung ausführen, führt MongoDB Folgendes aus:

1. Entwickelt alle Sammlungsindizes, während die Dokumente für jede Sammlung kopiert werden.
2. Dupliziert alle Datenbanken außer der lokalen Datenbank. mongod scannt jede Sammlung in allen Quelldatenbanken und fügt alle Daten in seine Duplikate dieser Sammlungen ein.
3. Führt alle Änderungen am Datensatz durch. Durch die Nutzung des Oplogs aus der Quelle aktualisiert der mongod seinen Datensatz, um den aktuellen Zustand des Replikatsatzes darzustellen.
4. Extrahiert neu hinzugefügte Oplog-Datensätze während der Datenkopie. Stellen Sie sicher, dass das Zielmitglied über genügend Speicherplatz in der lokalen Datenbank verfügt, um diese Oplog-Datensätze für die Dauer dieser Datenkopierphase vorläufig zu speichern.

Wenn die anfängliche Synchronisierung abgeschlossen ist, wechselt das Mitglied von STARTUP2 zu SECONDARY .

Dateikopie-basierte Erstsynchronisierung

Auf Anhieb können Sie dies nur ausführen, wenn Sie MongoDB Enterprise verwenden. Dieser Prozess führt die anfängliche Synchronisierung durch Duplizieren und Verschieben der Dateien im Dateisystem aus. Diese Synchronisierungsmethode ist in einigen Fällen möglicherweise schneller als die logische anfängliche Synchronisierung. Beachten Sie, dass die auf Dateikopien basierende anfängliche Synchronisierung zu ungenauen Zählungen führen kann, wenn Sie die Methode count() ohne ein Abfrageprädikat ausführen.

Aber auch diese Methode hat ihren gerechten Anteil an Einschränkungen:

• Während einer auf Dateikopien basierenden anfänglichen Synchronisierung können Sie nicht in die lokale Datenbank des Mitglieds schreiben, das synchronisiert wird. Sie können auch keine Sicherung auf dem Mitglied ausführen, mit dem synchronisiert wird, oder auf dem Mitglied, mit dem synchronisiert wird.
• Bei der Nutzung der verschlüsselten Speicher-Engine verwendet MongoDB den Quellschlüssel, um das Ziel zu verschlüsseln.
• Sie können jeweils nur eine anfängliche Synchronisierung von einem bestimmten Mitglied ausführen.

Reproduzieren

Sekundäre Mitglieder replizieren Daten konsistent nach der anfänglichen Synchronisierung. Sekundäre Member duplizieren das Oplog aus ihrer Synchronisierung von der Quelle und führen diese Vorgänge in einem asynchronen Prozess aus.

Secondaries sind in der Lage, ihre Synchronisierung von der Quelle nach Bedarf automatisch zu ändern, basierend auf den Änderungen in der Ping-Zeit und dem Status der Replikation anderer Mitglieder.

Streaming-Replikation

Ab MongoDB 4.4 sendet die Synchronisierung von Quellen einen kontinuierlichen Strom von Oplog-Einträgen an ihre synchronisierenden sekundären Datenbanken. Die Streaming-Replikation reduziert die Replikationsverzögerung in Netzwerken mit hoher Auslastung und hoher Latenz. Es kann auch:

• Verringern Sie das Risiko, Schreibvorgänge mit w:1 aufgrund eines primären Failovers zu verlieren.
• Verringern Sie die Veraltung von Lesevorgängen von Secondaries.
• Reduzieren Sie die Latenz bei Schreibvorgängen mit w:“majority” und w:>1 . Kurz gesagt, alle Schreibangelegenheiten, die auf die Replikation warten müssen.

Multithreaded-Replikation

MongoDB hat verwendet, um Operationen in Stapeln über mehrere Threads zu schreiben, um die Parallelität zu verbessern. MongoDB gruppiert die Stapel nach Dokument-ID, während jede Gruppe von Operationen mit einem anderen Thread angewendet wird.

MongoDB führt Schreibvorgänge auf einem bestimmten Dokument immer in seiner ursprünglichen Schreibreihenfolge aus. Dies hat sich in MongoDB 4.0 geändert.

Ab MongoDB 4.0 lesen Lesevorgänge, die auf Sekundärknoten abzielen und mit einer Lesebetroffenheitsebene von “majority” oder “local” konfiguriert sind, jetzt aus einem WiredTiger-Snapshot der Daten, wenn der Lesevorgang auf einem Sekundärknoten erfolgt, auf dem die Replikationsstapel angewendet werden. Das Lesen aus einem Snapshot garantiert eine konsistente Ansicht der Daten und lässt das Lesen gleichzeitig mit der laufenden Replikation erfolgen, ohne dass eine Sperre erforderlich ist.

Daher müssen sekundäre Lesevorgänge, die diese Leseinteressenstufen benötigen, nicht mehr auf die Anwendung von Replikationsbatches warten und können verarbeitet werden, sobald sie empfangen werden.

So erstellen Sie ein MongoDB-Replikatset

Wie bereits erwähnt, verarbeitet MongoDB die Replikation über Replikatsätze. In den nächsten Abschnitten stellen wir einige Methoden vor, mit denen Sie Replikatsätze für Ihren Anwendungsfall erstellen können.

Methode 1: Erstellen eines neuen MongoDB-Replikatsatzes auf Ubuntu

Bevor wir beginnen, müssen Sie sicherstellen, dass Sie mindestens drei Server haben, auf denen Ubuntu 20.04 ausgeführt wird, wobei MongoDB auf jedem Server installiert ist.

Um einen Replikatsatz einzurichten, ist es wichtig, eine Adresse anzugeben, unter der jedes Mitglied des Replikatsatzes von anderen im Satz erreicht werden kann. In diesem Fall behalten wir drei Mitglieder im Set. Obwohl wir IP-Adressen verwenden können, wird dies nicht empfohlen, da sich die Adressen unerwartet ändern könnten. Eine bessere Alternative kann die Verwendung der logischen DNS-Hostnamen beim Konfigurieren von Replikatgruppen sein.

Wir können dies tun, indem wir die Subdomäne für jedes Replikationsmitglied konfigurieren. Während dies für eine Produktionsumgebung ideal sein kann, wird in diesem Abschnitt beschrieben, wie Sie die DNS-Auflösung konfigurieren, indem Sie die Dateien der jeweiligen Hosts jedes Servers bearbeiten. Diese Datei ermöglicht es uns, numerischen IP-Adressen lesbare Hostnamen zuzuordnen. Wenn sich also Ihre IP-Adresse ändert, müssen Sie lediglich die Dateien der Hosts auf den drei Servern aktualisieren, anstatt den Replikatsatz von Grund auf neu zu konfigurieren!

Meistens wird hosts im Verzeichnis /etc/ gespeichert. Wiederholen Sie die folgenden Befehle für jeden Ihrer drei Server:

 sudo nano /etc/hosts

Im obigen Befehl verwenden wir nano als Texteditor, Sie können jedoch jeden beliebigen Texteditor verwenden. Fügen Sie nach den ersten paar Zeilen, die den localhost konfigurieren, einen Eintrag für jedes Mitglied des Replikatsatzes hinzu. Diese Einträge haben die Form einer IP-Adresse, gefolgt von einem menschenlesbaren Namen Ihrer Wahl. Sie können sie zwar benennen, wie Sie möchten, aber achten Sie darauf, beschreibend zu sein, damit Sie wissen, wie Sie zwischen den einzelnen Mitgliedern unterscheiden können. Für dieses Tutorial verwenden wir die folgenden Hostnamen:

• mongo0.replset.member
• mongo1.replset.member
• mongo2.replset.member

Unter Verwendung dieser Hostnamen würden Ihre /etc/hosts-Dateien ähnlich wie die folgenden hervorgehobenen Zeilen aussehen:

Speichern und schließen Sie die Datei.

Nachdem wir die DNS-Auflösung für den Replikatsatz konfiguriert haben, müssen wir die Firewall-Regeln aktualisieren, damit sie miteinander kommunizieren können. Führen Sie den folgenden ufw Befehl auf mongo0 aus, um mongo1 Zugriff auf Port 27017 auf mongo0 zu gewähren:

 sudo ufw allow from mongo1_server_ip to any port 27017

Geben Sie anstelle des Parameters mongo1_server_ip die tatsächliche IP-Adresse Ihres mongo1-Servers ein. Wenn Sie die Mongo-Instanz auf diesem Server aktualisiert haben, um einen nicht standardmäßigen Port zu verwenden, stellen Sie außerdem sicher, dass Sie 27017 ändern, um den Port widerzuspiegeln, den Ihre MongoDB-Instanz verwendet.

Fügen Sie nun eine weitere Firewall-Regel hinzu, um mongo2 Zugriff auf denselben Port zu gewähren:

 sudo ufw allow from mongo2_server_ip to any port 27017

Geben Sie anstelle des Parameters mongo2_server_ip die tatsächliche IP-Adresse Ihres mongo2-Servers ein. Aktualisieren Sie dann die Firewall-Regeln für Ihre beiden anderen Server. Führen Sie die folgenden Befehle auf dem mongo1-Server aus und stellen Sie sicher, dass Sie die IP-Adressen anstelle des server_ip-Parameters ändern, um die von mongo0 bzw. mongo2 widerzuspiegeln:

 sudo ufw allow from mongo0_server_ip to any port 27017

 sudo ufw allow from mongo2_server_ip to any port 27017

Führen Sie zuletzt diese beiden Befehle auf mongo2 aus. Stellen Sie auch hier sicher, dass Sie für jeden Server die richtigen IP-Adressen eingeben:

 sudo ufw allow from mongo0_server_ip to any port 27017

 sudo ufw allow from mongo1_server_ip to any port 27017

Ihr nächster Schritt besteht darin, die Konfigurationsdatei jeder MongoDB-Instanz zu aktualisieren, um externe Verbindungen zuzulassen. Um dies zu ermöglichen, müssen Sie die Konfigurationsdatei auf jedem Server ändern, um die IP-Adresse widerzuspiegeln und den Replikatsatz anzugeben. Während Sie jeden bevorzugten Texteditor verwenden können, verwenden wir wieder den Nano-Texteditor. Nehmen wir die folgenden Änderungen in jeder mongod.conf-Datei vor.

Auf mongo0:

 # network interfaces net: port: 27017 bindIp: 127.0.0.1,mongo0.replset.member# replica set replication: replSetName: "rs0"

Auf mongo1:

 # network interfaces net: port: 27017 bindIp: 127.0.0.1,mongo1.replset.member replication: replSetName: "rs0"

Auf Mongo2:

 # network interfaces net: port: 27017 bindIp: 127.0.0.1,mongo2.replset.member replication: replSetName: "rs0"

 sudo systemctl restart mongod

Damit haben Sie die Replikation für die MongoDB-Instanz jedes Servers aktiviert.

Sie können jetzt den Replikatsatz mit der Methode rs.initiate() initialisieren. Diese Methode muss nur auf einer einzelnen MongoDB-Instanz im Replikatsatz ausgeführt werden. Stellen Sie sicher, dass der Name und das Mitglied des Replikatsatzes mit den Konfigurationen übereinstimmen, die Sie zuvor in jeder Konfigurationsdatei vorgenommen haben.

 rs.initiate( { _id: "rs0", members: [ { _id: 0, host: "mongo0.replset.member" }, { _id: 1, host: "mongo1.replset.member" }, { _id: 2, host: "mongo2.replset.member" } ] })

Wenn die Methode „ok“: 1 in der Ausgabe zurückgibt, bedeutet dies, dass der Replikatsatz korrekt gestartet wurde. Unten sehen Sie ein Beispiel dafür, wie die Ausgabe aussehen sollte:

 { "ok": 1, "$clusterTime": { "clusterTime": Timestamp(1612389071, 1), "signature": { "hash": BinData(0, "AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId": NumberLong(0) } }, "operationTime": Timestamp(1612389071, 1) }

Fahren Sie den MongoDB-Server herunter

Sie können einen MongoDB-Server mit der Methode db.shutdownServer() herunterfahren. Unten ist die Syntax dafür. Sowohl force als auch timeoutsecs sind optionale Parameter.

 db.shutdownServer({ force: <boolean>, timeoutSecs: <int> })

Diese Methode kann fehlschlagen, wenn das Mitglied des Mongod-Replikatsatzes bestimmte Vorgänge als Indexerstellung ausführt. Um die Operationen zu unterbrechen und das Herunterfahren des Mitglieds zu erzwingen, können Sie den booleschen Parameter force auf true eingeben.

Starten Sie MongoDB mit –replSet neu

Um die Konfiguration zurückzusetzen, stellen Sie sicher, dass jeder Knoten in Ihrem Replikatsatz gestoppt ist. Löschen Sie dann die lokale Datenbank für jeden Knoten. Starten Sie es erneut mit dem Flag –replSet und führen Sie rs.initiate() auf nur einer Mongod-Instanz für den Replikatsatz aus.

 mongod --replSet "rs0"

rs.initiate() kann ein optionales Replikatsatz-Konfigurationsdokument annehmen, nämlich:

• Die Option Replication.replSetName “ oder —replSet , um den Namen des Replikatsatzes im Feld _id anzugeben.
• Das Array der Mitglieder, das ein Dokument für jedes Replikatgruppenmitglied enthält.

Die Methode rs.initiate() löst eine Wahl aus und wählt eines der Mitglieder zum primären Mitglied.

Mitglieder zum Replikatsatz hinzufügen

Um Mitglieder zum Set hinzuzufügen, starten Sie Mongod-Instanzen auf verschiedenen Computern. Starten Sie als Nächstes einen Mongo-Client und verwenden Sie den Befehl rs.add() .

Der Befehl rs.add() hat die folgende grundlegende Syntax:

 rs.add(HOST_NAME:PORT)

Zum Beispiel,

Angenommen, mongo1 ist Ihre Mongod-Instanz und lauscht auf Port 27017. Verwenden Sie den Mongo-Client-Befehl rs.add() , um diese Instanz zum Replikatsatz hinzuzufügen.

 rs.add("mongo1:27017")

Erst nachdem Sie mit dem primären Knoten verbunden sind, können Sie dem Replikatsatz eine Mongod-Instanz hinzufügen. Verwenden Sie den Befehl db.isMaster() , um zu überprüfen, ob Sie mit dem primären Server verbunden sind.

Benutzer entfernen

Um ein Mitglied zu entfernen, können wir rs.remove() verwenden.

Fahren Sie dazu zunächst die Mongod-Instanz herunter, die Sie entfernen möchten, indem Sie die oben besprochene Methode db.shutdownServer() verwenden.

Stellen Sie als Nächstes eine Verbindung mit dem aktuellen Primärknoten des Replikatsatzes her. Verwenden Sie zum Ermitteln des aktuellen Primärknotens db.hello() , während Sie mit einem beliebigen Mitglied des Replikatsatzes verbunden sind. Führen Sie einen der folgenden Befehle aus, nachdem Sie die primäre festgelegt haben:

 rs.remove("mongodb-node-04:27017") rs.remove("mongodb-node-04")

Wenn der Replikatsatz einen neuen Primärknoten auswählen muss, trennt MongoDB die Shell möglicherweise kurzzeitig. In diesem Szenario wird die Verbindung automatisch erneut hergestellt. Außerdem wird möglicherweise ein DBClientCursor::init call() Fehler angezeigt, obwohl der Befehl erfolgreich war.

Methode 2: Konfigurieren eines MongoDB-Replikatsatzes für Bereitstellung und Tests

Im Allgemeinen können Sie Replikatsätze zum Testen entweder mit aktiviertem oder deaktiviertem RBAC einrichten. Bei dieser Methode richten wir Replikatsätze mit deaktivierter Zugriffskontrolle ein, um sie in einer Testumgebung bereitzustellen.

Erstellen Sie zunächst mit dem folgenden Befehl Verzeichnisse für alle Instanzen, die Teil des Replikatsatzes sind:

 mkdir -p /srv/mongodb/replicaset0-0 /srv/mongodb/replicaset0-1 /srv/mongodb/replicaset0-2

Dieser Befehl erstellt Verzeichnisse für drei MongoDB-Instanzen replicaset0-0, replicaset0-1 und replicaset0-2. Starten Sie nun die MongoDB-Instanzen für jede von ihnen mit den folgenden Befehlen:

Für Server 1:

 mongod --replSet replicaset --port 27017 --bind_ip localhost,<hostname(s)|ip address(es)> --dbpath /srv/mongodb/replicaset0-0 --oplogSize 128

Für Server 2:

 mongod --replSet replicaset --port 27018 --bind_ip localhost,<hostname(s)|ip address(es)> --dbpath /srv/mongodb/replicaset0-0 --oplogSize 128

Für Server 3:

 mongod --replSet replicaset --port 27019 --bind_ip localhost,<hostname(s)|ip address(es)> --dbpath /srv/mongodb/replicaset0-0 --oplogSize 128

Der Parameter –oplogSize wird verwendet, um zu verhindern, dass die Maschine während der Testphase überlastet wird. Es trägt dazu bei, die Menge an Speicherplatz zu reduzieren, die jede Festplatte verbraucht.

Stellen Sie nun über die Mongo-Shell eine Verbindung zu einer der Instanzen her, indem Sie die Verbindung über die unten stehende Portnummer herstellen.

 mongo --port 27017

Wir können den Befehl rs.initiate() verwenden, um den Replikationsprozess zu starten. Sie müssen den hostname Parameter durch den Namen Ihres Systems ersetzen.

 rs conf = { _id: "replicaset0", members: [ { _id: 0, host: "<hostname>:27017}, { _id: 1, host: "<hostname>:27018"}, { _id: 2, host: "<hostname>:27019"} ] }

Sie können nun die Konfigurationsobjektdatei als Parameter für den Befehl „initiate“ übergeben und wie folgt verwenden:

 rs.initiate(rsconf)

Und da haben Sie es! Sie haben erfolgreich einen MongoDB-Replikatsatz für Entwicklungs- und Testzwecke erstellt.

Methode 3: Transformieren einer eigenständigen Instanz in einen MongoDB-Replikatsatz

MongoDB ermöglicht seinen Benutzern, ihre eigenständigen Instanzen in Replikatsätze umzuwandeln. Während eigenständige Instanzen hauptsächlich für die Test- und Entwicklungsphase verwendet werden, sind Replikat-Sets Teil der Produktionsumgebung.

Lassen Sie uns zunächst unsere Mongod-Instanz mit dem folgenden Befehl herunterfahren:

 db.adminCommand({"shutdown":"1"})

Starten Sie Ihre Instanz neu, indem Sie den Parameter –repelSet in Ihrem Befehl verwenden, um den zu verwendenden Replikatsatz anzugeben:

 mongod --port 27017 – dbpath /var/lib/mongodb --replSet replicaSet1 --bind_ip localhost,<hostname(s)|ip address(es)>

Sie müssen den Namen Ihres Servers zusammen mit der eindeutigen Adresse im Befehl angeben.

Verbinden Sie die Shell mit Ihrer MongoDB-Instance und verwenden Sie den Befehl „initiate“, um den Replikationsprozess zu starten und die Instance erfolgreich in einen Replikatsatz zu konvertieren. Sie können alle grundlegenden Vorgänge wie das Hinzufügen oder Entfernen einer Instanz mit den folgenden Befehlen ausführen:

 rs.add(“<host_name:port>”)

 rs.remove(“host-name”)

Außerdem können Sie den Status Ihres MongoDB-Replikatsatzes mit den Befehlen rs.status() und rs.conf() überprüfen.

Methode 4: MongoDB-Atlas – eine einfachere Alternative

Replikation und Sharding können zusammenarbeiten, um einen sogenannten Sharding-Cluster zu bilden. Während die Einrichtung und Konfiguration ziemlich zeitaufwändig, wenn auch unkompliziert sein kann, ist MongoDB Atlas eine bessere Alternative als die zuvor genannten Methoden.

Es automatisiert Ihre Replikatsätze und macht den Prozess einfach zu implementieren. Es kann global fragmentierte Replikatsätze mit wenigen Klicks bereitstellen, was eine Notfallwiederherstellung, eine einfachere Verwaltung, Datenlokalisierung und Bereitstellungen in mehreren Regionen ermöglicht.

In MongoDB Atlas müssen wir Cluster erstellen – sie können entweder ein Replikatsatz oder ein Sharding-Cluster sein. Für ein bestimmtes Projekt ist die Anzahl der Knoten in einem Cluster in anderen Regionen auf insgesamt 40 begrenzt.

Davon ausgenommen sind die kostenlosen oder gemeinsam genutzten Cluster und die Google-Cloud-Regionen, die miteinander kommunizieren. Die Gesamtzahl der Knoten zwischen zwei beliebigen Regionen muss diese Einschränkung erfüllen. Zum Beispiel, wenn es ein Projekt gibt, in dem:

• Region A hat 15 Knoten.
• Region B hat 25 Knoten
• Region C hat 10 Knoten

Wir können der Region C nur 5 weitere Knoten zuweisen, da

1. Bereich A + Bereich B = 40; erfüllt die Einschränkung, dass 40 die maximal zulässige Anzahl von Knoten ist.
2. Region B+ Region C = 25+10+5 (zusätzliche Knoten, die C zugeordnet sind) = 40; erfüllt die Einschränkung, dass 40 die maximal zulässige Anzahl von Knoten ist.
3. Region A + Region C = 15 + 10 + 5 (zusätzliche Knoten, die C zugeordnet sind) = 30; erfüllt die Einschränkung, dass 40 die maximal zulässige Anzahl von Knoten ist.

Wenn wir der Region C 10 weitere Knoten zuordnen, sodass die Region C 20 Knoten hat, dann sind Region B + Region C = 45 Knoten. Dies würde die angegebene Einschränkung überschreiten, sodass Sie möglicherweise keinen Cluster mit mehreren Regionen erstellen können.

Wenn Sie einen Cluster erstellen, erstellt Atlas einen Netzwerkcontainer im Projekt für den Cloud-Anbieter, falls er vorher nicht vorhanden war. Um einen Replikatsatz-Cluster in MongoDB Atlas zu erstellen, führen Sie den folgenden Befehl in der Atlas-CLI aus:

 atlas clusters create [name] [options]

Stellen Sie sicher, dass Sie einen aussagekräftigen Clusternamen angeben, da er nach der Erstellung des Clusters nicht mehr geändert werden kann. Das Argument kann ASCII-Buchstaben, Ziffern und Bindestriche enthalten.

Je nach Ihren Anforderungen stehen mehrere Optionen für die Clustererstellung in MongoDB zur Verfügung. Wenn Sie beispielsweise ein kontinuierliches Cloud-Backup für Ihren Cluster wünschen, setzen Sie --backup auf true.

Umgang mit Replikationsverzögerung

Die Replikationsverzögerung kann ziemlich abschreckend sein. Es ist eine Verzögerung zwischen einem Vorgang auf dem primären und der Anwendung dieses Vorgangs vom Oplog auf den sekundären. Wenn Ihr Unternehmen mit großen Datensätzen zu tun hat, ist eine Verzögerung innerhalb eines bestimmten Schwellenwerts zu erwarten. Manchmal können jedoch auch externe Faktoren dazu beitragen und die Verzögerung erhöhen. Um von einer aktuellen Replikation zu profitieren, stellen Sie Folgendes sicher:

1. Sie leiten Ihren Netzwerkverkehr in einer stabilen und ausreichenden Bandbreite weiter. Die Netzwerklatenz spielt eine große Rolle bei der Beeinträchtigung Ihrer Replikation, und wenn das Netzwerk nicht ausreicht, um die Anforderungen des Replikationsprozesses zu erfüllen, kommt es zu Verzögerungen bei der Replikation von Daten im gesamten Replikatsatz.
2. Sie haben einen ausreichenden Plattendurchsatz. Wenn das Dateisystem und das Festplattengerät auf dem sekundären Gerät nicht in der Lage sind, Daten so schnell auf die Festplatte zu übertragen wie das primäre, wird das sekundäre Gerät Schwierigkeiten haben, Schritt zu halten. Daher verarbeiten die sekundären Knoten die Schreibanfragen langsamer als der primäre Knoten. Dies ist ein häufiges Problem in den meisten Multi-Tenant-Systemen, einschließlich virtualisierter Instanzen und umfangreicher Bereitstellungen.
3. Sie fordern nach einem Intervall eine Schreibbestätigung für Schreibvorgänge an, um den Sekundärknoten die Möglichkeit zu geben, mit dem Primärknoten Schritt zu halten, insbesondere wenn Sie einen Massenladevorgang oder eine Datenerfassung durchführen möchten, die eine große Anzahl von Schreibvorgängen auf dem Primärknoten erfordern. Die Secondaries werden das Oplog nicht schnell genug lesen können, um mit den Änderungen Schritt zu halten; insbesondere bei unbestätigten Schreibproblemen.
4. Sie identifizieren die laufenden Hintergrundaufgaben. Bestimmte Aufgaben wie Cron-Jobs, Server-Updates und Sicherheitsüberprüfungen können unerwartete Auswirkungen auf die Netzwerk- oder Festplattennutzung haben und Verzögerungen beim Replikationsprozess verursachen.

Wenn Sie sich nicht sicher sind, ob Ihre Anwendung eine Replikationsverzögerung aufweist, machen Sie sich keine Sorgen – im nächsten Abschnitt werden Strategien zur Fehlerbehebung behandelt!

Fehlerbehebung bei MongoDB-Replikatsätzen

Sie haben Ihre Replikatsätze erfolgreich eingerichtet, aber Sie stellen fest, dass Ihre Daten serverübergreifend inkonsistent sind. Dies ist für große Unternehmen sehr alarmierend, aber mit schnellen Methoden zur Fehlerbehebung können Sie die Ursache finden oder sogar das Problem beheben! Im Folgenden finden Sie einige gängige Strategien zur Fehlerbehebung bei Bereitstellungen von Replikatgruppen, die sich als nützlich erweisen könnten:

Überprüfen Sie den Replikationsstatus

Wir können den aktuellen Status des Replikatsatzes und den Status jedes Mitglieds überprüfen, indem wir den folgenden Befehl in einer Mongosh-Sitzung ausführen, die mit dem Primärknoten eines Replikatsatzes verbunden ist.

 rs.status()

Überprüfen Sie die Replikationsverzögerung

Wie bereits erwähnt, kann die Replikationsverzögerung ein ernsthaftes Problem darstellen, da sie dazu führt, dass „verzögerte“ Mitglieder nicht schnell primär werden können, und die Wahrscheinlichkeit erhöht, dass verteilte Lesevorgänge inkonsistent sind. Wir können die aktuelle Länge des Replikationsprotokolls mit dem folgenden Befehl überprüfen:

 rs.printSecondaryReplicationInfo()

Dies gibt den syncedTo Wert zurück, der die Zeit ist, zu der der letzte Oplog-Eintrag für jedes Mitglied in den sekundären geschrieben wurde. Hier ist ein Beispiel, um dasselbe zu demonstrieren:

 source: m1.example.net:27017 syncedTo: Mon Oct 10 2022 10:19:35 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary source: m2.example.net:27017 syncedTo: Mon Oct 10 2022 10:19:35 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary

Ein verzögertes Mitglied kann als 0 Sekunden hinter dem primären Mitglied angezeigt werden, wenn der Inaktivitätszeitraum auf dem primären Mitglied größer als der Wert members[n].secondaryDelaySecs ist.

Testverbindungen zwischen allen Mitgliedern

Jedes Mitglied eines Replikatsatzes muss in der Lage sein, sich mit jedem anderen Mitglied zu verbinden. Achten Sie immer darauf, die Verbindungen in beide Richtungen zu überprüfen. Meistens verhindern Firewall-Konfigurationen oder Netzwerktopologien die normale und erforderliche Konnektivität, was die Replikation blockieren kann.

Nehmen wir zum Beispiel an, dass die Mongod-Instanz sowohl an localhost als auch an den Hostnamen „ExampleHostname“ bindet, der der IP-Adresse 198.41.110.1 zugeordnet ist:

 mongod --bind_ip localhost, ExampleHostname

Um sich mit dieser Instanz zu verbinden, müssen Remote-Clients den Hostnamen oder die IP-Adresse angeben:

 mongosh --host ExampleHostname mongosh --host 198.41.110.1

Wenn ein Replikatsatz aus drei Mitgliedern besteht, m1, m2 und m3, die den Standardport 27017 verwenden, sollten Sie die Verbindung wie folgt testen:

Auf m1:

 mongosh --host m2 --port 27017 mongosh --host m3 --port 27017

Auf m2:

 mongosh --host m1 --port 27017 mongosh --host m3 --port 27017

Auf m3:

 mongosh --host m1 --port 27017 mongosh --host m2 --port 27017

Wenn eine Verbindung in irgendeiner Richtung fehlschlägt, müssen Sie Ihre Firewall-Konfiguration überprüfen und neu konfigurieren, um die Verbindungen zuzulassen.

Gewährleistung einer sicheren Kommunikation mit Keyfile-Authentifizierung

Standardmäßig basiert die Keyfile-Authentifizierung in MongoDB auf dem Salted-Challenge-Response-Authentifizierungsmechanismus (SCRAM). Dazu muss MongoDB die bereitgestellten Anmeldeinformationen des Benutzers lesen und validieren, die eine Kombination aus Benutzername, Passwort und Authentifizierungsdatenbank enthalten, die der jeweiligen MongoDB-Instanz bekannt ist. Dies ist genau der Mechanismus, der verwendet wird, um Benutzer zu authentifizieren, die ein Kennwort angeben, wenn sie sich mit der Datenbank verbinden.

Wenn Sie die Authentifizierung in MongoDB aktivieren, wird die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) automatisch für den Replikatsatz aktiviert, und dem Benutzer werden eine oder mehrere Rollen gewährt, die seinen Zugriff auf Datenbankressourcen bestimmen. Wenn RBAC aktiviert ist, bedeutet dies, dass nur der gültige authentifizierte Mongo-Benutzer mit den entsprechenden Berechtigungen auf die Ressourcen auf dem System zugreifen kann.

Die Schlüsseldatei verhält sich wie ein gemeinsames Passwort für jedes Mitglied im Cluster. Dadurch kann jede Mongod-Instanz im Replikatsatz den Inhalt der Schlüsseldatei als gemeinsames Kennwort zum Authentifizieren anderer Mitglieder in der Bereitstellung verwenden.

Nur die Mongod-Instanzen mit der richtigen Schlüsseldatei können dem Replikatsatz beitreten. Die Länge eines Schlüssels muss zwischen 6 und 1024 Zeichen betragen und darf nur Zeichen im base64-Satz enthalten. Bitte beachten Sie, dass MongoDB beim Lesen von Schlüsseln die Leerzeichen entfernt.

Sie können eine Schlüsseldatei mit verschiedenen Methoden generieren . In diesem Tutorial verwenden wir openssl , um eine komplexe Zeichenfolge mit 1024 zufälligen Zeichen zu generieren, die als gemeinsames Passwort verwendet werden kann. It then uses chmod to change file permissions to provide read permissions for the file owner only. Avoid storing the keyfile on storage mediums that can be easily disconnected from the hardware hosting the mongod instances, such as a USB drive or a network-attached storage device. Below is the command to generate a keyfile:

 openssl rand -base64 756 > <path-to-keyfile> chmod 400 <path-to-keyfile>

Next, copy the keyfile to each replica set member . Make sure that the user running the mongod instances is the owner of the file and can access the keyfile. After you've done the above, shut down all members of the replica set starting with the secondaries. Once all the secondaries are offline, you may go ahead and shut down the primary. It's essential to follow this order so as to prevent potential rollbacks. Now shut down the mongod instance by running the following command:

 use admin db.shutdownServer()

After the command is run, all members of the replica set will be offline. Now, restart each member of the replica set with access control enabled .

For each member of the replica set, start the mongod instance with either the security.keyFile configuration file setting or the --keyFile command-line option.

If you're using a configuration file, set

• security.keyFile to the keyfile's path, and
• replication.replSetName to the replica set name.

 security: keyFile: <path-to-keyfile> replication: replSetName: <replicaSetName> net: bindIp: localhost,<hostname(s)|ip address(es)>

Start the mongod instance using the configuration file:

 mongod --config <path-to-config-file>

If you're using the command line options, start the mongod instance with the following options:

• –keyFile set to the keyfile's path, and
• –replSet set to the replica set name.

 mongod --keyFile <path-to-keyfile> --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>

You can include additional options as required for your configuration. For instance, if you wish remote clients to connect to your deployment or your deployment members are run on different hosts, specify the –bind_ip. For more information, see Localhost Binding Compatibility Changes.

Next, connect to a member of the replica set over the localhost interface . You must run mongosh on the same physical machine as the mongod instance. This interface is only available when no users have been created for the deployment and automatically closes after the creation of the first user.

We then initiate the replica set. From mongosh, run the rs.initiate() method:

 rs.initiate( { _id: "myReplSet", members: [ { _id: 0, host: "mongo1:27017" }, { _id: 1, host: "mongo2:27017" }, { _id: 2, host: "mongo3:27017" } ] } )

As discussed before, this method elects one of the members to be the primary member of the replica set. To locate the primary member, use rs.status() . Connect to the primary before continuing.

Now, create the user administrator . You can add a user using the db.createUser() method. Make sure that the user should have at least the userAdminAnyDatabase role on the admin database.

The following example creates the user 'batman' with the userAdminAnyDatabase role on the admin database:

 admin = db.getSiblingDB("admin") admin.createUser( { user: "batman", pwd: passwordPrompt(), // or cleartext password roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] } )

Enter the password that was created earlier when prompted.

Next, you must authenticate as the user administrator . To do so, use db.auth() to authenticate. Zum Beispiel:

db.getSiblingDB(“admin”).auth(“batman”, passwordPrompt()) // or cleartext password

Alternatively, you can connect a new mongosh instance to the primary replica set member using the -u <username> , -p <password> , and the --authenticationDatabase parameters.

 mongosh -u "batman" -p --authenticationDatabase "admin"

Even if you do not specify the password in the -p command-line field, mongosh prompts for the password.

Lastly, create the cluster administrator . The clusterAdmin role grants access to replication operations, such as configuring the replica set.

Let's create a cluster administrator user and assign the clusterAdmin role in the admin database:

 db.getSiblingDB("admin").createUser( { "user": "robin", "pwd": passwordPrompt(), // or cleartext password roles: [ { "role" : "clusterAdmin", "db" : "admin" } ] } )

Enter the password when prompted.

If you wish to, you may create additional users to allow clients and interact with the replica set.

And voila! You have successfully enabled keyfile authentication!

Zusammenfassung

Replication has been an essential requirement when it comes to databases, especially as more businesses scale up. It widely improves the performance, data security, and availability of the system. Speaking of performance, it is pivotal for your WordPress database to monitor performance issues and rectify them in the nick of time, for instance, with Kinsta APM, Jetpack, and Freshping to name a few.

Replication helps ensure data protection across multiple servers and prevents your servers from suffering from heavy downtime(or even worse – losing your data entirely). In this article, we covered the creation of a replica set and some troubleshooting tips along with the importance of replication. Do you use MongoDB replication for your business and has it proven to be useful to you? Let us know in the comment section below!