Experte
31
Mai
2019
2019
von Marc-David Militz
Forum: MongoDB Theorie
- Artikel von Dj Walker-Morgan
- Low-level Timestamps in MongoDB/WiredTiger
- Logische Sessions in MongoDB
- Unterstützung für das Lesen lokaler Snapshots
- Implementieren einer globalen, logischen Uhr
- Ermöglichen sicherer Lesevorgänge auf den Sekundärknoten
- Hinzufügen wiederholbarer Schreiboperationen
- Zusammenfassung
- Hintergrund
- Datenhaltung in WiredTiger
- Timestamps
- Lesen auf Secondaries
- Zurückrollen von Replikationen
- Timestamps und Transactions
englischer Originalartikel
https://www.mongodb.com/blog/post/transactions-background-part-1-lowlevel-timestamps-in-mongodbwiredtiger
Übersetzung mit freundlicher Genehmigung von MongoDB
Aktuelle Features in MongoDB, wie z.B. Multi-Dokument ACID Transaktionen, haben es notwendig gemacht fundamentale Erweiterungen der darunterliegenden WiredTiger Storage Engine zu implementieren.
Diese Serie beschäftigt sich mit den Änderungen, die notwendig waren, um die Transaktions-Unterstützung in das Herz der Datenbank zu implementieren.
Zu diesen Änderungen gehören:
Jedes dieser Features werden wir uns ansehen um Fragen zu beantworten, wie: "Was wurde hinzugefügt?", "Warum wurde es auf diese Weise implementiert?" und "Was für eine Auswirkung hat das auf Transaktionen als Ganzes?"Beginnen wir mit den Low-level Timestamps in MongoDB und WiredTiger.
Timestamps, von MongoDB Schreiboperationen, werden nun im WiredTiger Storage-Layer als zusätzliche Metadaten verwaltet. Das ermöglicht es das MongoDB eigene Konzept umzusetzen, bei dem nur Daten von vor oder zu einem speziellen Zeitpunkt abgefragt werden. Auf diese Weise kann MongoDB Snapshots erstellen und bei Datenbankoperationen, sowie Transaktionen von einem beliebigen Zeitpunkt aus arbeiten.
Um eine Replikation zu ermöglichen pflegt MongoDB ein Betriebs-Log, das sog. Oplog. Das Oplog ist eine spezialisierte Collection innerhalb des Servers, welche die letzten Operationen, die auf der Datenbank ausgeführt wurden, auflistet. Indem diese Operationen auf einem Sekundärknoten wiederholt werden, wird die Replikation auf den neuesten Stand gebracht und ein Konsistenter Zustand mit dem Primärknoten bewahrt. Die Reihenfolge der Operationen im Oplog ist kritisch, um sicherzustellen dass die Replikas den korrekten Datenbestand des Primärservers abbilden.
MongoDB verwaltet die Reihenfolge des Oplogs und wie die Replicas, in der richtigen Reihenfolge, auf das Oplog zugreifen. Der Wechsel auf die weitaus mächtigere WiredTiger Speicher-Engine, und seine eigene darunterliegende Idee von Reihenfolgen innerhalb des Storage-Layers, machte es notwendig diese mit den Konzepten im Server zu vereinen.
WiredTiger speichert alle Daten in einem Baum aus Schlüsseln und Werten. Wenn man es als Speicher für die MongoDB verwendet, dann können dort Dokumente oder Teile eines Index abgelegt werden. Für jedes Update im Wert eines Schlüssels, erstellt WiredTiger eine Update-Struktur. Diese Struktur enthält Informationen über die Transaktion, die geänderten Daten und einen Pointer auf spätere Änderungen. WiredTiger hängt dies dann an die Original Daten an. Spätere Updates hängen sich selbst an das vorherige Update an und erzeugen auf diese Weise, im Laufe der Zeit, eine Kette der unterschiedlichen Versionen eines Wertes.
Dies ist die Multi-Versions Komponente der Parallelitätskontrolle, die WiredTiger implementiert hat. WiredTiger hat seine eigenen Regeln, wie Update Strukturen gelesen werden um zum aktuellen Stand eines Wertes zu kommen. Die, von WiredTiger verwendete, Reihenfolge unterscheidet sich dabei von der im Oplog von MongoDB. Die Differenz entsteht dadurch, dass WiredTiger mehrfache Schreibvorgänge auf den Sekundärknoten parallelisiert, sofern das möglich ist. Während der Primärknoten viele parallele Schreibzugriffe akzeptieren kann, müssen die Sekundärknoten in der Lage sein diesen zusätzlichen Datendurchsatz mit den vorhandenen parallelen Schreibvorgängen der Replikation, in Einklang zu bringen.
Um die MongoDB Reihenfolge innerhalb der WiredTiger Storage Engine zu erhalten, wurde die Update-Struktur um ein Feld mit einem Zeitstempel erweitert. Den Wert für das Feld bekommt WiredTiger von MongoDB und wird als elementare Meta-Information behandelt. Wenn auf WiredTiger Abfragen mit einem bestimmten Zeitstempel versehen werden, dann wird als Ergebnis der Zustand zu genau diesem Zeitpunkt zurück geliefert. Das ermöglicht ein Mapping zwischen den Reihenfolgen von MongoDB und WiredTiger.
Wen ein Sekundärknoten sich mit dem Primärknoten synchronisiert, dann macht er das indem er die Updates in Chargen aus dem Oplog holt. Im Anschluss werden die Änderungen auf den eigenen Storage angewendet. Ohne Zeitstempel, würden diese Operationen lesende Zugriffe blockieren, bis die jeweilige Charge abgearbeitet wurde, damit die Benutzer keine Schreibvorgänge außerhalb der Reihe zu sehen bekommen. Dank dem hinzufügen der Zeitstempel wird es aber nun möglich lesend zuzugreifen, indem der Zeitstempel von vor dem Beginn der aktuellen Charge verwendet wird. So wird ein konsistentes Ergebnis sichergestellt. Auf diese Weise beeinflussen Schreiboperationen die Leseoperationen auf den Sekundärknoten auch nicht mehr.
Wenn mehrere Sekundärknoten in einer MongoDB, von der Replikation geupdated werden, dann hat jeder Server seinen eigenen Status der Synchronisation, indem er sich gerade befindet. Aus diesem Grund gibt es den "majority commit point": das ist der der Zeitpunkt, an dem die Mehrheit der Sekundärserver den Zustand des Primärservers erfolgreich repliziert haben. Wenn der Primärknoten ausfällt, dann sind nur Daten bis zum letzten majority commit point, auf allen Servern garantiert verfügbar und das ist auch der Datenbestand, mit dem die Sekundärserver arbeiten, bis ein neuer Primärknoten gewählt wurde. Die Wahl läuft nach dem RAFT-Konsens-Protokoll ab.
Wenn der frühere Primärknoten in den Cluster zurückkehrt, dann läuft ein enorm komplexer Prozess ab um die Synchronisation mit dem Rest des Clusters zu gewährleisten. Es besteht die Möglichkeit, dass dieser Server Daten von nach dem "majority commit point" besitzt, und muss nun feststellen welche Änderungen der Cluster nicht mehr mitbekommen hat und die entsprechenden "alten" Versionen abrufen.
Dank der Zeitstempel wurde dieser Vorgang radikal vereinfacht. Mit dem Zeitstempel des "majority commit point" und der Anwendung auf den Speicher des früheren Primaries, können alle Änderungen nach diesem Zeitpunkt verworfen werden und der Konten sich schnell wieder in den Cluster eingliedern und mit der Replikation des Primärknotens anfangen.
Indem der Zeitstempel in das Herz des WiredTiger Trees hinzugefügt wurde, ist es nun möglich die multi-version concurrency control von WiredTiger zu nutzen, um Locks zu reduzieren und Resynchronisierungs-Prozesse zu vereinfachen. Die Möglichkeit Momentaufnahmen (Snapshots) eines beliebigen Zeitpunkts zu liefern, erlaubt dem Server ein Rollback zu jedem beliebigen Zeitpunkt. Dies ist eine fundamentale Funktion für die Richtigkeitsgarantien von Multi-Document ACID Transaktionen.
Wer tiefer in das Thema MongoDB Transaktionen einsteigen will, für den hat Qualiero die Schulung MongoDB Datenbank-Entwickler-Kurs im Angebot
https://www.qualiero.com/lerninhalte/classroom-trainings/mongodb-datenbank-entwickler-kurs.html
