MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

Was ist das Standard-Mongod-Schreibproblem in welcher Version?

Das Standard-Schreibproblem in MongoDB war w:1 schon seit MongoDB 2.2 im Jahr 2012.

Es gibt drei verschiedene Einstellungen, mit denen Sie in aktuellen MongoDB-Versionen (Version 3.2.6 und neuer) Schreibschutz einrichten können:

  • w Einstellung :Wie viele Knoten sollten den Schreibvorgang bestätigen, bevor er als erfolgreich deklariert wird. Der Standardwert ist 1, was bedeutet, dass die Bestätigung des primären Knotens ausreichend ist.
  • j Einstellung :Müssen die Schreibvorgänge aufgezeichnet werden, bevor sie bestätigt werden? Standard hängt von writeConcernMajorityJournalDefault ab .
  • writeConcernMajorityJournalDefault :wenn Sie w:majority angeben Write Concern-Einstellung für Ihre Schreibvorgänge, ohne j zu setzen , was ist der implizite j Wert? Standard ist true (Schreibvorgänge sollten in den meisten Abstimmungsknoten aufgezeichnet werden, bevor sie bestätigt werden).

Es gibt auch einen wtimeout Einstellung um zu konfigurieren, wie lange MongoDB auf die Erfüllung des Schreibproblems warten soll, bevor es den Client darüber informiert, dass der Schreibvorgang nicht bestätigt wurde. Andernfalls können Schreibvorgänge, die darauf warten, dass die Schreibanforderungen erfüllt werden, ewig warten, anstatt fehlzuschlagen.

Die spezielle Einstellung hier ist w:majority . Das bedeutet, dass Schreibvorgänge an die Mehrheit der Abstimmungsknoten weitergegeben werden müssen (und auch an ihre Zeitschriften) in einem zu bestätigenden Replikatsatz. Dies ist wohl die sicherste Einstellung bei gleichzeitig guter Leistung, weil:

  • Es verhindert, dass bestätigte Schreibvorgänge bei Fehlern rückgängig gemacht werden.
  • Es regelt den Durchsatz der Anwendung, sodass Schreibvorgänge nicht schneller gesendet werden, als der Replikatsatz verarbeiten kann (aufgrund von Hardwareeinschränkungen, Netzwerksituation usw.).

Wie Sie sich vorgestellt haben, enthalten Voting Nodes den Arbiter . Somit ist in einem Replikatsatz mit Primary-Secondary-Arbiter-Setup w:majority könnte in einem Szenario fehlschlagen, in dem:

  • Einer der datentragenden Knoten ist aus irgendeinem Grund offline.
  • Der Replikatsatz ist immer noch online mit einem beschreibbaren Primärknoten, da die Topologie jetzt Primär-Arbiter-Offline ist.
  • Schreibt mit w:1 wird wie gewohnt erfolgreich sein, aber diese Schreibvorgänge könnten rückgängig gemacht werden (da sie nicht auf die Mehrheit der Abstimmungsdaten enthaltenden Knoten geschrieben wurden).
  • Da der Arbiter keine Daten trägt, w:majority Schreibvorgänge schlagen fehl (oder warten auf unbestimmte Zeit), da der Arbiter als Abstimmungsknoten gezählt wird.

Aus diesem Grund wird die Verwendung eines Arbiters nicht empfohlen, wenn Sie vorhaben, w:majority zu verwenden in Ihrer Bewerbung.

Bitte beachten Sie, dass die Verwendung eines Arbiters in einem 3-Knoten-Replikatsatz, der einen Shard in einem Sharding-Cluster bildet, ebenfalls nicht empfohlen wird, da Blockverschiebungen w:majority erfordern . Der Ausfall eines datentragenden Knotens in einem Shard wirkt sich nachteilig auf Chunk-Migrationsvorgänge aus.