MongoDB – beliebtes dokumentenorientiertes Datenbanksystem, das keine Entwicklung und Erstellung von DB-Schemata erfordert.
Weit verbreitet in der Entwicklung von Webanwendungen und auch für jede Art von Software, bei der NoSQL effektiver und nützlicher ist als relationale Datenbank.
Um eine Anwendung zu entwickeln oder zu testen, reicht oft ein einziger DB-Server aus.
Es wird empfohlen, vor dem Einsatz einer Anwendung in einer Produktionsumgebung über mögliche Risiken nachzudenken – was kann passieren, wenn Daten auf dem einzigen DB-Server gespeichert werden?
Wenn die Daten nicht kritisch sind (z. B. für Cache-Zwecke), funktioniert eine Anwendung auch ohne diese Daten weiter, die für die Wiederherstellung der Datenbank benötigte Zeit (im Falle eines Fehlers) ist akzeptabel – dann reicht der einzige Server aus.
Andernfalls, wenn die Daten als kritisch betrachtet werden, wirkt sich ihr Verlust oder ihre Unzugänglichkeit auf eine Anwendung (also einen Dienst, den sie ausmacht) aus cliEnts empfangen) – in diesem Fall lautet die Empfehlung, einen Cluster für die Datenspeicherung zu verwenden.
MongoDB ermöglicht den Aufbau zweier Arten von Clustern:
- Replikatsatz: Eine Gruppe von Servern, die dieselben Daten speichern. Die Zugänglichkeit der Daten wird durch Replikation sichergestellt.
- Shard-Cluster: Teile der Daten auf mehrere Server verteilen, bedeutet horizontale Skalierung.
Unten wird der Konfigurationsprozess eines Replikatsatz-Clusters gezeigt.
Replikatsatz – Serverrollen.
Der MongoDB-Cluster erfordert mindestens drei Server (Knoten) (oder eine ungerade Zahl):
- Primärer Server – verarbeitet alle Lese-/Schreibanfragen. Alle Vorgänge, die die Daten ändern, werden in einer speziellen Sammlung namens „oplog“ (Operationsprotokoll) gespeichert – Einträge aus dieser Sammlung werden zur Durchführung der Replikation verwendet.
- Sekundärserver (mindestens zwei Server) – repliziert die Oplog-Sammlung und wendet Änderungen auf die gespeicherten Daten an. Durch diesen Prozess wird sichergestellt, dass die Daten auf allen Servern identisch sind.
Gemeinsames Schema:
Replikatsatz – Konfiguration.
Verwendete Serverdaten:
- Primärer Server: Name – Server1, IP 10.20.30.10
- Sekundärer Server: Name – Server2, IP 10.20.30.20
- Sekundärer Server: Name – Server3, IP 10.20.30.30
Ersetzen Sie Namen und IP-Adressen durch Ihre eigenen.
Schritte für alle Server, bevor Sie fortfahren:
- Installieren Sie MongoDB.
- Einrichtung firewall wenn es verwendet wird, um eingehende/ausgehende Pakete auf Port 27017 zuzulassen.
- Legen Sie die Auflösung des Servernamens fest: Wenn nein DNS Server verwendet wird, kann dies durch Hinzufügen von Einträgen zur Datei /etc/hosts wie folgt erfolgen:
10.20.30.10 server1.domain.local server1
10.20.30.20 server2.domain.local server2
10.20.30.30 server3.domain.local server3Wichtiger Hinweis: Alle folgenden Konfigurationsbefehle dürfen nur Servernamen enthalten! Ab Version 5.0 ist die Verwendung von IP-Adressen nicht mehr zulässig. MongoDB überprüft die Konfiguration und startet nicht, wenn IPs vorhanden sind.
Schritte zur Clusterkonfiguration:
1. Starten Sie MongoDB auf allen Servern:
mongod --replSet “rs0” –bind_ip localhost,server_name„rs0“ – Replikatname (wählen Sie bei Bedarf einen anderen Namen)
server_name – Name eines Servers, auf dem MongoDB startet.
2. Starten Sie auf dem Primärserver die MongoDB-Shell mit dem Namen „mongo“ (indem Sie Ihre Anmeldeinformationen anstelle von Benutzername und Passwort verwenden):
mongo -u username -p password3. Initialisieren Sie die Replikation und fügen Sie alle Server zum Cluster hinzu:
rs.initiate( {
_id: “rs0”,
members: [
{ _id: 0, host: “server1.domain.local:27017” },
{ _id: 1, host: “server2.domain.local:27017” },
{ _id: 2, host: “server3.domain.local:27017” },
]
})Dieser Schritt muss nur auf dem Primärserver durchgeführt werden und muss nicht auf dem Sekundärserver wiederholt werden.
4. Überprüfen Sie die Replikationseinstellungen mit dem Befehl „rs.conf()“ – die Ausgabe dieses Befehls zeigt parameter jedes Servers. Für den Primärserver sollte es so aussehen:
{
"_id" : "rs0",
"version" : 1,
"protocolVersion" : NumberLong(1),
"members" : [
{
"_id" : 0,
"host" : "server1. domain.local:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},5. Es konnte festgestellt werden, dass jeder Server die Standardpriorität 1 hat: die Zeichenfolge „priority: 1“.
Bei der Wahl wird der Prioritätswert verwendet: Der niedrigste Wert bedeutet die höchste Wahrscheinlichkeit, neuer Primärserver zu werden.
Mit den folgenden Befehlen kann zuvor definiert werden, welcher sekundäre Server genau als neuer primärer Server ausgewählt wird:
conf = rs.conf()
conf[‘members’][0].priority = 1
conf[‘members’][1].priority = 2
conf[‘members’][2].priority = 3
rs.reconfig(conf)Somit
- Server1 ist immer primär.
- Server2 wird zum neuen Primärserver, wenn auf Server1 nicht zugegriffen werden kann.
- Server3 bleibt der einzige und primäre Server im Cluster, wenn sowohl auf Server1 als auch auf Server2 nicht zugegriffen werden kann.
6. Überprüfen Sie den Replikationsstatus mit dem Befehl „rs.status()“. Das Vorhandensein aller Server sowie deren Status (die Zeichenfolge „stateStr“) sollten in der Ausgabe überprüft werden.
Beispiel für den Primärserver:
"members" : [
{
"_id" : 0,
"name" : "server1:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 87986,
"optime" : {
"ts" : Timestamp(1526936047, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2023-03-29T12:54:07Z"),
"electionTime" : Timestamp(1526848104, 1),
"electionDate" : ISODate("2018-03-29T12:28:24Z"),
"configVersion" : 3,
"self" : true
},Der Wert von „stateStr“ ist „PRIMARY“, was bedeutet, dass Server1 tatsächlich der primäre Server ist.
Für den sekundären Server2:
{
"_id" : 0,
"name" : "server2:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 97453,
"optime" : {
"ts" : Timestamp(1526936047, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2023-03-29T12:54:07Z"),
"electionTime" : Timestamp(1526848104, 1),
"electionDate" : ISODate("2018-03-29T12:28:24Z"),
"configVersion" : 3,
"self" : true
},„stateStr“ ist „SECONDARY“, was bedeutet, dass Server2 Teil des Clusters und erwartungsgemäß sekundär ist. Eine ähnliche Ausgabe sollte für Server3 erfolgen.
Standardmäßig überprüfen die Server alle 10 Sekunden den Status (Zustand) der anderen Server (der Zeitraum kann geändert werden).
Wie bereits erwähnt: Wenn auf den Primärserver nicht zugegriffen werden kann, wird der Wahlprozess gestartet.
Gemäß den Prioritätswerten wird Server2 zum neuen Primärserver – dies ist in der Ausgabe von „rs.status()“ zu sehen: „stateStr“ wird von „SECONDARY“ in „PRIMARY“ geändert.
Für Server1 wird „stateStr“ gleichzeitig „nicht erreichbar/fehlerfrei“ sein.
Sobald Server1 wieder im Cluster verfügbar ist – die Daten werden von Server2 repliziert und nachdem die Neuauswahl gestartet wurde – wird Server1 aufgrund seiner Priorität zum primären Server.
Ein konfigurierter Cluster ermöglicht außerdem die Durchführung von Wartungsarbeiten auf jedem Server ohne Auswirkungen auf eine Anwendung, da auf die Daten von einem anderen Server aus zugegriffen werden kann.
Zusammenfassung
Diese Schritte reichen aus, um einen grundlegenden „Replica-Set“-Cluster einzurichten.
Es könnten komplexere Konfigurationen verwendet werden, einschließlich einer KombinationnatIon der beiden Clustertypen.
Beispiele für diese Art von Konfigurationen werden in den folgenden Artikeln besprochen.
