MongoDB Nebenläufigkeitsmodell bestimmt den Testansatz für Read Replicas

Post date: Mar 10, 2013 11:29:26 AM

MongoDB verwendet Sperren für Lese- und Schreibzugriffe um eine konsistente Sicht der Dokumentdaten zu gewährleisten.

Lesezugriffe, “get more” Operationen auf Cursor-Ebene, die Einfügung, die Änderung, das Löschen von Daten, die Erzeugung von Indizen und die Map/Reduce Jobs verwenden alle Sperren. Wenn Datenbanken kopiert werden, wenn Journalling ausgeführt wird und wenn Authentifizierung-Operationen stattfinden während Daten auf dem Primary gespeichert werden mehrere Sperren auf Datenbanken werden benötigt weil der Oplog in der lokalen Datenbank gespeichert werden muss zusammen mit den Dokumenten die in anderen Datenbanken geschrieben werden.

Der Sperrentyp ist eine Reader-Writer-Sperre die nebenläufige Lesezugriffe aber nur einen exklusiven Schreibzugriff gleichzeitig erlaubt. Writers werden bevorzugt und werden früher als die anderen gleichzeitig wartenden Readers bedient. Die Granularität der Sperre in Version 2.2 von Mongo DB ist auf Datenbank-Ebene für die meisten Lese- und Schreibzugriffe mit der Ausnahme der o.g. Fälle. Die alten Versionen von MongoDB haben eine einzige Sperre auf MongoDB Prozess-Ebene verwendet.

Wenn der MongoDB-Prozess einen Page Fault erhält oder wenn der MongoDB Prozess Dokumente liest die voraussichtlich nicht im Speicher liegen, ergeben die Lese- und Schreibzugriffe ihre Sperren um anderen Operationen Zugang zu den im Speicher liegenden Dokumente zu erlauben während die Dokumente von dem MongoDB Prozess in den Speicher geladen werden.

Das allgemeine Modell ist dass lange laufende Operationen ihre Sperren zu kurz laufenden Operationen ergeben. Lange laufende Schreibzugriffe werden ihre Sperren ergeben um Lesezugriffe zu erlauben und lange laufende Lesezugriffe werden auch ihre Sperren ergeben um Schreibzugriffe zu ermöglichen.

Die Sperren zu ergeben wenn ein Page Fault auftritt ist eine neue Fähigkeit in der Version 2.2 von MongoDB. Vor einer Ausführung der Lesezugriffe wird MongoDB voraussagen ob sich die Daten im Speicher befinden. Wenn nicht, wird der Lesezugriff seine Sperre zu anderen Operationen aufgeben während der mongod Prozess die Daten in den Speicher auflädt.

Die Secondary-Knoten sammeln Oplog-Einträge in Batches und führen Schreiboperationen auf den im Speichen geladenen Daten aus. Die Daten werden mit der Hilfe einer Lese-Sperre geladen und während dieser Operation sind andere nebenläufige Lesezugriffe erlaubt. Um eine nebenläufige Ausführung der Schreibzugriffe zu ermöglichen, wird ein Thread Pool verwendet. Während der Ausführung der Oplog-Operationen werden Lesezugriffe auf den Secondary-Knoten nicht erlaubt.

Diese Eigenschaft bringt uns zu der Schlussfolgerung dass ein realistischer Stress-Test auf Read Replicas effektiv ist nur wenn heftige Replikation stattdindet.