Die Replikation ist in Datenbanksystemen weit verbreitet, um eine hohe Verfügbarkeit von Daten durch das Schaffen von Redundanz sicherzustellen. Es ist im Grunde eine Strategie, eine Kopie derselben Daten auf verschiedenen laufenden Servern zu erstellen, die sich möglicherweise auf verschiedenen Computern befinden, damit im Falle eines Ausfalls des Hauptservers ein anderer dazu gebracht werden kann, mit der Bereitstellung fortzufahren.
Ein Replikatsatz ist eine Gruppe von MongoDB-Instances, die denselben Datensatz verwalten. Sie sind die Grundlage für Produktionsbereitstellungen. Die Replikation hat den Vorteil, dass Daten immer von einem anderen Server verfügbar sind, falls das Hauptserversystem ausfällt. Außerdem verbessert es den Lesedurchsatz, indem es einem Client ermöglicht wird, Leseanfragen an verschiedene Server zu senden und eine Antwort vom nächstgelegenen zu erhalten.
Ein Replikatsatz besteht aus mehreren datentragenden Knoten, die in unterschiedlichen Maschinen gehostet werden könnten, und einem Arbiter-Knoten. Einer dieser datentragenden Knoten wird als primär bezeichnet, während die anderen sekundäre Knoten sind. Der primäre Knoten empfängt alle Schreiboperationen und repliziert die Daten dann auf die anderen Knoten, nachdem die Schreiboperation abgeschlossen und die Änderungen in einem Oplog aufgezeichnet wurden.
Ein Arbiter ist eine zusätzliche Instanz, die keinen Datensatz verwaltet, aber ein Quorum in einem Replikatsatz bereitstellt, indem sie auf Heartbeat- und Wahlanforderungen anderer Mitglieder des Replikatsatzes reagiert. Sie reduzieren somit die Kosten für die Wartung eines Replikatsatzes anstelle eines voll funktionsfähigen Replikatsatzmitglied mit einem Datensatz.
Automatisches Failover
Ein primärer Knoten kann aus bestimmten Gründen wie Stromausfällen oder Netzwerktrennung ausfallen, wodurch er nicht in der Lage ist, mit den anderen Mitgliedern zu kommunizieren. Wenn die Kommunikation für mehr als den konfigurierten Zeitraum electionTimeoutMillis unterbrochen ist, fordert einer der sekundären eine Wahl, um sich selbst als neuer primärer zu nominieren. Wenn die Wahl abgeschlossen und erfolgreich ist, fährt der Cluster mit dem normalen Betrieb fort. Während dieser Zeit können keine Schreiboperationen durchgeführt werden. Die Leseabfragen können jedoch so konfiguriert werden, dass sie normal auf den sekundären Servern ausgeführt werden, während der primäre Server offline ist.
Für einen optimalen Replikationsprozess sollte die mittlere Zeit, bevor der Cluster einen neuen primären Server auswählt, maximal 12 Sekunden mit den standardmäßigen Replikationskonfigurationseinstellungen betragen. Dies kann durch Faktoren wie Netzwerklatenz beeinflusst werden, die die Zeit verlängern können, daher sollte die Architektur des Clusters berücksichtigt werden, um sicherzustellen, dass diese Zeit nicht zu hoch eingestellt ist.
Der Wert für electionTimeoutMillis kann von der Standardeinstellung 10000 (10 Sekunden) herabgesetzt werden, sodass die Primäre sehr schnell als erstes erkannt werden kann. Dies kann jedoch dazu führen, dass die Wahlen häufig für sogar geringfügige Faktoren wie vorübergehende Netzwerklatenz aufgerufen werden, obwohl der primäre Knoten fehlerfrei ist. Dies führt zu Problemen wie Rollbacks für Schreibvorgänge.
Ansible für Replikatsätze
Wie bereits erwähnt, kann ein Replikatsatz Mitglieder von verschiedenen Hostmaschinen haben, wodurch es komplexer wird, den Cluster zu verwalten. Wir brauchen eine einzige Plattform, von der aus dieses Replikat-Set problemlos gewartet werden kann. Ansible ist eines der Tools, das eine bessere Übersicht für die Konfiguration und Verwaltung eines Replikatsatzes bietet. Wenn Sie neu bei Ansible sind, sehen Sie sich bitte eine kurze Zusammenfassung dieses Artikels an, um die Grundlagen wie das Erstellen eines Playbooks zu verstehen.
Konfigurationsparameter
- arbiter_at_index: dies definiert die Position des Arbiters in der Mitgliederliste des Replikatsatzes. Ein Arbiter Remember hat keine Daten wie die anderen Mitglieder und kann nicht als primärer Knoten verwendet werden. Es ist nur verfügbar, ein Quorum während der Wahl herzustellen. Wenn Sie beispielsweise eine gerade Anzahl von Mitgliedern haben, ist es gut, einen Schiedsrichter hinzuzufügen, der bei Stimmengleichheit eine 1 hinzufügt, um ein gewinnendes Mitglied zu machen. Der zuzuweisende Wert sollte eine Ganzzahl sein.
- Verkettung_erlaubt: Dies akzeptiert einen booleschen Wert und definiert, ob die anderen sekundären Elemente von den anderen sekundären Elementen repliziert werden sollen, wenn Verkettung _allowed =true ist. Wenn andernfalls Verkettung _allowed =false ist, können die anderen sekundären Mitglieder nur vom primären Mitglied replizieren. Der Standardwert ist wahr.
- election_timeout_secs: standardmäßig ist der Wert 10000 (nimmt einen ganzzahligen Wert an). Es ist die Zeit in Millisekunden, um zu erkennen, wann der primäre Knoten nicht erreichbar ist oder eher nicht mit den anderen Mitgliedern kommuniziert und somit eine Wahl auslöst. Stellen Sie diesen auf einen Mittelwert von 12 Sekunden ein. Wenn es zu hoch eingestellt ist, dauert es lange, bis der primäre Fehler erkannt wird, und daher länger, um eine Wahl durchzuführen. Da sich dies auf den Schreibvorgang auswirkt, können in diesem Zeitraum viele Daten verloren gehen. Ist er hingegen zu niedrig eingestellt, kommt es häufig zu Wahlauslösungen, auch wenn der Fall nicht so gravierend ist und die Primäre noch erreichbar ist. Infolgedessen müssen Sie so viele Rollbacks für Schreibvorgänge haben, dass dies irgendwann zu einer schlechten Datenintegrität oder Inkonsistenz führen kann.
- heartbeat_timeout_secs: Replica-Sets müssen vor einer Wahl miteinander kommunizieren, indem sie ein Signal senden, das als Heartbeat bezeichnet wird. Die Mitglieder müssen dann innerhalb einer bestimmten Zeitspanne, die standardmäßig auf 10 Sekunden eingestellt ist, auf diese Signalisierung reagieren. Heartbeat_timeout_secs ist die Anzahl der Sekunden, die die Replikatgruppenmitglieder auf einen erfolgreichen Heartbeat voneinander warten, und wenn ein Mitglied nicht antwortet, wird es als nicht zugänglich markiert. Dies gilt jedoch nur für die Protokollversion 0. Der Wert dafür ist also eine Ganzzahl.
- Login-Host: Dies ist der Host, der die Login-Datenbank beherbergt. Standardmäßig ist für MongoDB localhost.
- Login-Datenbank: der Standardwert ist der Administrator und dort werden die Anmeldeinformationen gespeichert. (nimmt einen Zeichenfolgenwert an)
- Anmeldebenutzer: der Benutzername, mit dem die Authentifizierung erfolgen soll. (nimmt einen String-Wert an)
- Login-Passwort: das Passwort zur Authentifizierung des Benutzers. (nimmt einen String-Wert an)
- Anmeldeport: Dies ist der MongoDB-Port, an dem sich der Host anmelden kann. (nimmt einen ganzzahligen Wert an)
- Mitglieder: definiert eine Liste von Mitgliedern des Replikatsatzes. Es ist ein durch Komma getrennter String oder eine Yaml-Liste, z. B. mongodb0:27017, mongodb2:27018, mongodb3:27019… Wenn keine Portnummer vorhanden ist, wird 27017 angenommen.
- Protokollversion: akzeptiert eine Ganzzahl, die die Version des Replikationsprozesses definiert. Entweder 0 oder 1
- replica_set: Dies ist ein Zeichenfolgenwert, der den Namen des Replikatsatzes definiert.
- ssl: boolescher Wert, der definiert, ob beim Verbinden mit der Datenbank eine SSL-Verbindung verwendet werden soll oder nicht.
- ssl_certs_reqs: Dies gibt an, ob ein Zertifikat von der anderen Seite der Verbindung erforderlich ist und ob es ggf. validiert werden muss. Die Auswahlmöglichkeiten dafür sind CERT_NONE, CERT_OPTIONAL und CERT_REQUIRED. Der Standardwert ist CERT_REQUIRED.
- validieren: nimmt einen booleschen Wert an, der definiert, ob eine grundlegende Überprüfung der bereitgestellten Replikatgruppenkonfiguration durchgeführt werden soll. Der Standardwert ist wahr.
Erstellen eines MongoDB-Replikatsatzes mit Ansible
Hier ist ein einfaches Beispiel für Aufgaben zum Einrichten eines Replikatsatzes in Ansible. Nennen wir diese Datei „tasks.yaml“
# Create a replicaset called 'replica0' with the 3 provided members
- name: Ensure replicaset replica0 exists
mongodb_replicaset:
login_host: localhost
login_user: admin
login_password: root
replica_set: replica0
arbiter_at_index:2
election_timeout_secs:12000
members:
- mongodb1:27017
- mongodb2:27018
- mongodb3:27019
when: groups.mongod.index(inventory_hostname) == 0
# Create two single-node replicasets on the localhost for testing
- name: Ensure replicaset replica0 exists
mongodb_replicaset:
login_host: localhost
login_port: 3001
login_user: admin
login_password: root
login_database: admin
replica_set: replica0
members: localhost:3000
validate: yes
- name: Ensure replicaset replica1 exists
mongodb_replicaset:
login_host: localhost
login_port: 3002
login_user: admin
login_password: secret
login_database: root
replica_set: replica1
members: localhost:3001
validate: yes
In unserem Playbook können wir die Aufgaben wie
nennen---
- hosts: ansible-test
remote_user: root
become: yes
Tasks:
- include: tasks.yml
Wenn Sie dies in Ihrem Playbook ausführen, ansible-playbook -i Inventory.txt -c ssh mongodbcreateReplcaSet.yaml, erhalten Sie eine Antwort, ob der Replikatsatz erstellt wurde oder nicht. Wenn der Schlüssel mongodb_replicaset mit einem Erfolgswert und einer Beschreibung des erstellten Replikatsatzes zurückgegeben wird, können Sie loslegen.
Schlussfolgerung
In MongoDB ist es im Allgemeinen mühsam, einen Replikatsatz für die Mongod-Instanzen zu konfigurieren, die von verschiedenen Computern gehostet werden können. Ansible bietet jedoch eine einfache Plattform, um dasselbe zu tun, indem nur ein paar Parameter wie oben beschrieben definiert werden. Die Replikation ist einer der Prozesse, die einen kontinuierlichen Anwendungsbetrieb sicherstellen, und sollte daher gut konfiguriert werden, indem eine mehrfache Anzahl von Mitgliedern in der Produktionswelt festgelegt wird. Ein Arbiter wird verwendet, um während des Wahlprozesses ein Quorum zu schaffen, daher sollte er in die Konfigurationsdatei aufgenommen werden, indem seine Position definiert wird.