MongoDB Write Concern:3 wichtige Vorbehalte

„Write Concern“ in MongoDB beschreibt die Ebene der Schreibbestätigung, die Sie davon erwarten können. Es ist eine ziemlich wichtige Einstellung, die Sie sich bei Ihren Schreibvorgängen merken sollten, und ihr Verhalten ist nützlich, um sie zu verstehen, insbesondere in verteilten MongoDB-Bereitstellungen (d. h. Replikatgruppen und fragmentierte Cluster). In diesem Beitrag diskutieren wir 3 Fallstricke bei der Verwendung von MongoDB-Schreibproblemen.

MongoDB-Schreibbedenken

Die MongoDB-Dokumentation definiert Write Concern als „die Ebene der Bestätigung, die von MongoDB für Schreibvorgänge in einen eigenständigen Mongod oder in Replica-Sets oder in Sharding-Cluster angefordert wird.“ „

Einfach ausgedrückt ist ein Schreibproblem ein Hinweis auf die „Dauerhaftigkeit“, die zusammen mit Schreibvorgängen an MongoDB weitergegeben wird. Schauen wir uns zur Verdeutlichung die Syntax an:

{ w: <value>, j: <boolean>, wtimeout: <number> }
Where*,
 w can be an integer | "majority" | , it represents the number of members that must acknowledge the write. Default value is 1.
 j Requests that a write be acknowledged after it is written to the on-disk journal as opposed to just the system memory. Unspecified by default.
wtimeout specifies timeout for the applying the write concern. Unspecified by default.

* Die detaillierte Syntax finden Sie in der Dokumentation der Write Concern Specification.

* Erfahren Sie mehr über die verschiedenen „Tags“, die Sie für häufige Schreibschutzwerte verwenden können, in unserem Blog „Dauerhaftigkeit und Schreibsicherheit in MongoDB verstehen“.

Beispiel:

db.inventory.insert(
    { sku: "abcdxyz", qty : 100, category: "Clothing" },
    { writeConcern: { w: 2, j: true, wtimeout: 5000 } }
)

Die Schreibbedenken der obigen Einfügung können wie folgt gelesen werden:Bestätigen Sie diese Schreiboperation, wenn „mindestens 2 Mitglieder des Replikatsatzes sie innerhalb von 5000 ms in ihre Journale geschrieben haben, oder geben Sie einen Fehler zurück '. Ein Write Concern-Wert für die Option war Mehrheit, d. h. „erfordert eine Bestätigung, dass Schreibvorgänge an die Mehrheit der abstimmenden Knoten, einschließlich des primären Knotens, weitergegeben wurden. „

Die Wichtigkeit des Schreibens ist offensichtlich. Erhöhen der Werte von w erhöht die Latenz von Schreibvorgängen und verringert gleichzeitig die Wahrscheinlichkeit, dass sie verloren gehen. Die Auswahl der richtigen Werte für Schreibvorgänge hängt von den Latenz- und Daueranforderungen der ausgeführten Schreibvorgänge ab.

Vor dem Hintergrund dessen, was ein Anliegen zum Schreiben ist, gehen wir weiter zu den drei Vorbehalten, die Sie bei der Verwendung von Anliegen zum Schreiben beachten sollten.

WARNUNG 1:Das Festlegen von Write Concern für Replikatsätze ohne wtimeout kann dazu führen, dass Schreibvorgänge auf unbestimmte Zeit blockiert werden

Die obige Mehrheitsdefinition (anwendbar ab MongoDB 3.0) besagt, dass eine Bestätigung von einer Mehrheit der „Abstimmungsknoten“ angefordert wird. Beachten Sie, dass „Wenn Sie wtimeout nicht angeben Option und die Stufe der Schreibbetroffenheit nicht erreichbar ist, wird der Schreibvorgang auf unbestimmte Zeit blockiert. „

Dies kann unerwartete Folgen haben, betrachten Sie beispielsweise einen 2+1-Replikatsatz (d. h. einen primären, einen sekundären und einen Arbiter). Wenn Ihr einziges Lesereplikat ausfällt, werden alle Schreibvorgänge mit einem Schreibproblem mit der Option „Mehrheit“ auf unbestimmte Zeit blockiert. Dasselbe passiert, wenn die w-Option auf 2 gesetzt ist. Ein weiteres extremes Beispiel ist der Fall eines 3+2-Replica-Sets (primär, 2 sekundäre und 2 Arbiter, keine empfohlene Konfiguration). Alle „Mehrheits“-Schreibvorgänge werden blockiert, selbst wenn ein einzelner Datenknoten nicht verfügbar ist, da die Mehrheitszahl in diesem Fall 3 ist.

Der einfachste Weg, dieses Problem zu lösen, besteht darin, immer einen wtimeout-Wert anzugeben, damit die Abfrage eine Zeitüberschreitung erleiden kann, wenn das Schreiben nicht durchgesetzt werden kann. Im Falle solcher Zeitüberschreitungsfehler macht MongoDB jedoch bereits erfolgreiche Schreibvorgänge, die an einige der Mitglieder vorgenommen wurden, bevor die Zeitüberschreitung auftrat, nicht rückgängig.

Außerdem gibt es derzeit keine Einstellung, um sicherzustellen, dass ein Schreibvorgang die Mehrheit der Knoten erreicht, die derzeit erreichbar sind. Seien Sie also vorsichtig, wenn Sie den Wert von Write Concern w basierend auf der gewünschten Topologie festlegen Haltbarkeit und Verfügbarkeit.

WARNUNG 2: Du könntest sogar mit w:Mehrheit Daten verlieren

Es scheint intuitiv, dass, sobald ein Schreiben von der Mehrheit der stimmberechtigten Mitglieder bestätigt wurde, seine Dauerhaftigkeit garantiert ist. Das ist jedoch nicht der Fall! Denken Sie daran, dass, wenn die j-Option nicht angegeben ist, ein Schreibvorgang sofort bestätigt wird, nachdem er in den Speicher geschrieben wurde.

Ein solcher Schreibvorgang kann also verloren gehen, wenn ein ungewöhnlicher Stromausfall die Mehrheit der Knoten ausschaltet, an die der Schreibvorgang weitergegeben wurde (und vor syncPeriodSecs, d. h. bevor er geleert werden konnte Festplatte).

Um die Dauerhaftigkeit von Schreibvorgängen zu gewährleisten, ist es am besten, das Journaling in Ihrer Datenbank nicht zu deaktivieren und die Option j auf true zu setzen. Tatsächlich wird beim Starten von MongoDB 3.6 das --nojournal -Flag wurde für Replica-Set-Mitglieder, die die WiredTiger-Speicher-Engine verwenden, als veraltet markiert.

Bei einem w-Wert von „majority“ und unspezifizierter j-Option für einen Replikatsatz hängt das genaue Haltbarkeitsverhalten vom Wert der Replikatsatzkonfiguration writeConcernMajorityJournalDefault ab. Wenn es auf „true“ gesetzt ist (und wenn Journaling aktiviert ist), werden Schreibvorgänge bestätigt, nachdem sie in die Journale einer Mehrheit der stimmberechtigten Mitglieder geschrieben wurden.

Nebenbei:Auch bei aktiviertem Journaling gehen Ihre Schreibvorgänge auf der MMAPv1-Speicher-Engine möglicherweise verloren, wenn innerhalb der Dauer von „commitIntervalM“ ein Ausfall auftritt. Die WiredTiger-Speicher-Engine hingegen erzwingt eine Synchronisierung von Journaldateien, wenn sie einen Schreibvorgang erhält, bei dem die j-Option auf „true“ gesetzt ist. Und selbst wenn j auf „false“ gesetzt ist, kann ein bestätigter „Mehrheits“-Schreibvorgang in eine neueste WiredTiger-basierte Bereitstellung nur dann verloren gehen, wenn die Mehrheit der Datenknoten gleichzeitig abstürzt.

CAVEAT 3: w:0 while set j:true verbessert nicht die Schreibleistung

Dies ist leicht zu begründen, sobald man darüber nachdenkt, aber ebenso leicht zu vergessen. Das Setzen der w-Option auf 0 wird normalerweise durchgeführt, um in die Datenbank nach dem „Fire-and-Forget“-Prinzip zu schreiben – wenn Sie ein ziemliches Maß an Vertrauen in die Datenbankinfrastruktur haben und sich mehr um die Latenz als um die Dauer jedes Schreibvorgangs kümmern. Wenn Sie jedoch die j-Option auf true setzen, wird Ihre w-Option effektiv überschrieben, da die Datenbank sicherstellt, dass der Schreibvorgang vor der Rückgabe in das On-Disk-Journal geschrieben wird.

Wenn Sie Bedenken beim Schreiben verwenden, um den Erfolg Ihrer Schreibvorgänge zu garantieren, denken Sie unbedingt an diese drei entscheidenden Vorbehalte! Wir sind hier, um zu helfen, also zögern Sie nicht, sich bei Fragen über Twitter oder per E-Mail zu melden.