Was ist Kettenreplikation?
Wenn wir von Replikation sprechen, beziehen wir uns auf den Prozess, redundante Kopien von Daten zu erstellen, um Designkriterien für die Datenverfügbarkeit zu erfüllen. Kettenreplikation bezieht sich daher auf die lineare Anordnung von MongoDB-Servern, um eine synchronisierte Kette zu bilden. Die Kette enthält einen primären Knoten, gefolgt von linear angeordneten sekundären Servern. Wie das Wort Kette andeutet, repliziert der Server, der dem primären Server am nächsten ist, von ihm, während jeder andere nachfolgende sekundäre Server vom vorhergehenden sekundären MongoDB-Server repliziert. Dies ist der Hauptunterschied zwischen der verketteten Replikation und der normalen Replikation. Verkettete Replikation tritt auf, wenn ein sekundärer Knoten sein Ziel mithilfe der Ping-Zeit auswählt oder wenn der nächstgelegene Knoten ein sekundärer ist. Obwohl die Kettenreplikation scheinbar die Last auf dem primären Knoten verringert, kann sie zu Replikationsverzögerungen führen.
Warum Kettenreplikation verwenden?
Systeminfrastrukturen erleiden manchmal unvorhersehbare Ausfälle, die zum Ausfall eines Servers führen und somit die Verfügbarkeit beeinträchtigen. Die Replikation stellt sicher, dass unvorhersehbare Ausfälle die Verfügbarkeit nicht beeinträchtigen. Die Replikation ermöglicht außerdem die Wiederherstellung nach Hardwarefehlern und Dienstunterbrechungen. Sowohl die verkettete als auch die unverkettete Replikation dienen diesem Zweck, die Verfügbarkeit trotz Systemausfällen sicherzustellen. Nachdem Sie festgestellt haben, dass die Replikation wichtig ist, fragen Sie sich vielleicht, warum gerade die Kettenreplikation verwendet wird. Es gibt keinen Leistungsunterschied zwischen verketteter und unverketteter Replikation in MongoDb. Wenn in beiden Fällen der primäre Knoten ausfällt, stimmen die sekundären Server für einen neuen aktiven primären Knoten ab, und daher wird das Schreiben und Lesen von Daten in beiden Fällen nicht beeinträchtigt. Die verkettete Replikation ist jedoch der standardmäßige Replikationstyp in MongoDb.
So richten Sie eine Kettenreplik ein
Standardmäßig ist die verkettete Replikation in MongoDB aktiviert. Wir werden daher auf den Prozess der Deaktivierung der Kettenreplikation eingehen. Der Hauptgrund, warum die Kettenreplikation deaktiviert werden kann, ist, wenn sie Verzögerungen verursacht. Der Vorteil der Kettenreplikation ist jedoch dem Verzögerungsnachteil überlegen, und daher ist es in den meisten Fällen unnötig, ihn zu deaktivieren. Falls die Kettenreplikation nicht standardmäßig aktiviert ist, helfen Ihnen die folgenden Befehle bei der Aktivierung.
cfg = rs.config()
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)Dieser Vorgang ist reversibel. Wenn Sie gezwungen werden, die Kettenreplikation zu deaktivieren, wird der folgende Prozess gewissenhaft befolgt.
cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)Tipps und Tricks für die Kettenreplikation
Die schlimmste Einschränkung der Kettenreplikation ist die Replikationsverzögerung. Die Replikationsverzögerung bezieht sich auf die Verzögerung, die zwischen dem Zeitpunkt auftritt, an dem ein Vorgang auf dem primären Computer ausgeführt wird, und dem Zeitpunkt, an dem derselbe Vorgang auf dem sekundären Computer repliziert wird. Obwohl es natürlich unmöglich ist, ist es immer erwünscht, dass die Replikationsgeschwindigkeit sehr hoch ist, wenn die Replikationsverzögerung Null ist. Um eine Replikationsverzögerung von nahezu Null zu vermeiden oder zu minimieren, ist es ein umsichtiges Designkriterium, primäre und sekundäre Hosts mit denselben Spezifikationen in Bezug auf CPU, RAM, E/A und netzwerkbezogene Spezifikationen zu verwenden.
Obwohl die Kettenreplikation die Datenverfügbarkeit sicherstellt, kann die Kettenreplikation zusammen mit dem Journaling verwendet werden. Das Journaling bietet Datensicherheit, indem in ein Protokoll geschrieben wird, das regelmäßig auf die Festplatte geschrieben wird. Wenn die beiden kombiniert werden, werden drei Server pro Schreibanforderung geschrieben, anders als bei der Kettenreplikation allein, wo nur zwei Server pro Schreibanforderung geschrieben werden.
Ein weiterer wichtiger Tipp ist die Verwendung von w mit Replikation. Der w-Parameter steuert die Anzahl der Server, an die eine Antwort geschrieben werden soll, bevor ein Erfolg zurückgegeben wird. Wenn der w-Parameter gesetzt ist, prüft getlasterror das Oplog der Server und wartet, bis die angegebene Anzahl von „w“-Servern die Operation angewendet hat.
Durch die Verwendung eines Überwachungstools wie MongoDB Monitoring Service (MMS) oder ClusterControl können Sie den Status Ihrer Replikatknoten abrufen und Änderungen im Laufe der Zeit visualisieren. In MMS finden Sie beispielsweise Replikationsverzögerungsdiagramme der sekundären Knoten, die die Variation der Replikationsverzögerungszeit zeigen.
Messen der Kettenreplikationsleistung
Inzwischen wissen Sie, dass der wichtigste Leistungsparameter der Kettenreplikation die Replikationsverzögerungszeit ist. Wir werden daher erörtern, wie die Replikationsverzögerungsperiode getestet werden kann. Dieser Test kann über das MongoDb-Shellskript durchgeführt werden. Um einen Replikationsverzögerungstest durchzuführen, vergleichen wir das Oplog des letzten Ereignisses auf dem primären Knoten und das Oplog des letzten Ereignisses auf dem sekundären Knoten.
Um die Informationen für den primären Knoten zu überprüfen, führen wir den folgenden Code aus.
db.printSlaveReplicationInfo()Der obige Befehl liefert Informationen zu allen kürzlich durchgeführten Operationen auf dem primären Knoten. Die Ergebnisse sollten wie folgt aussehen.
rs-ds046297:PRIMARY db.printSlaveReplicationInfo()
source: ds046297-a1.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)
source: ds046297-a2.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)Nachdem wir das Oplog für den primären Knoten erhalten haben, interessieren wir uns nun für das Oplog für den sekundären Knoten. Der folgende Befehl hilft uns, das Oplog zu erhalten.
db.printReplicationInfo()Dieser Befehl liefert eine Ausgabe mit Details zur Oplog-Größe, Protokolllänge, Zeit für das erste Ereignis des Oplogs, Zeit für das letzte Ereignis des Oplogs und die aktuelle Zeit. Die Ergebnisse werden wie folgt angezeigt.
rs-ds046297:PRIMARY db.printReplicationInfo()
configured oplog size: 1024MB
log length start to end: 5589 secs (1.55hrs)
oplog first event time: Tue Mar 05 2013 06:15:19 GMT-0800 (PST)
oplog last event time: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
now: Tue Mar 05 2013 09:53:07 GMT-0800 (PST)Aus dem Oplog des primären Servers erfolgte die letzte Synchronisierung am Dienstag, 5. März 2013, 07:48:19 GMT-0800 (PST). Aus dem Oplog des sekundären Servers ging hervor, dass die letzte Operation am Di, 05. März 2013, 07:48:19 GMT-0800 (PST) stattfand. Die Replikationsverzögerung war null und daher funktioniert unser kettenrepliziertes System ordnungsgemäß. Die Replikationszeitverzögerung kann jedoch abhängig von der Menge der zu replizierenden Änderungen variieren.
