Wat is het standaard probleem bij het schrijven van mongoden in welke versie?

Het standaard schrijfprobleem in MongoDB is w:1 van zo ver terug als MongoDB 2.2 in 2012.

Er zijn drie verschillende instellingen die u kunt gebruiken om schrijfproblemen in te stellen in de huidige MongoDB-versies (versie 3.2.6 en nieuwer):

• w instelling :hoeveel knooppunten moeten het schrijven bevestigen voordat het tot een succes wordt verklaard. De standaardwaarde is 1, wat betekent dat de bevestiging van het primaire knooppunt voldoende is.
• j instelling :moeten de schrijfacties worden gejournaliseerd voordat ze worden bevestigd? Standaard is afhankelijk van writeConcernMajorityJournalDefault .
• writeConcernMajorityJournalDefault :als u w:majority opgeeft schrijf zorginstelling voor uw schrijfbewerkingen zonder j . in te stellen , wat is de impliciete j waarde? Standaard is true (schrijfacties moeten in de meerderheid van de stemknooppunten worden gejournaliseerd voordat ze worden bevestigd).

Er is ook een wtimeout instelling om te configureren hoe lang MongoDB moet wachten totdat aan de schrijfproblemen is voldaan voordat de client wordt geïnformeerd dat het schrijven niet is bevestigd. Anders kunnen schrijfopdrachten die wachten op bevrediging van schrijfproblemen voor altijd wachten in plaats van te mislukken.

De speciale instelling hier is w:majority . Dit betekent dat schrijfacties zich moeten verspreiden naar de meerderheid van de stemknooppunten (en ook aan hun tijdschriften) in een replicaset om erkend te worden. Dit is aantoonbaar de veiligste instelling terwijl het goede prestaties levert, omdat:

• Het voorkomt dat erkende schrijfbewerkingen worden teruggedraaid in het geval van fouten.
• Het regelt de verwerkingscapaciteit van de toepassing zodat deze geen schrijfacties sneller verzendt dan de replicaset aankan (vanwege hardwarebeperkingen, netwerksituatie, enz.).

Zoals je je kunt voorstellen, bevatten stemknooppunten de arbiter . Dus, in een replicaset met primair-secundair-arbiter setup, w:majority zou kunnen mislukken in een scenario waarin:

• Een van de datadragende nodes is om de een of andere reden offline.
• De replicaset is nog steeds online met een beschrijfbare primary, aangezien de topologie nu primary-arbiter-offline is.
• Schrijft met w:1 zal zoals gewoonlijk slagen, maar die schrijfbewerkingen kunnen worden teruggedraaid (aangezien het niet naar de meerderheid van de stemgegevensdragende knooppunten is geschreven).
• Omdat de arbiter geen gegevens heeft, w:majority schrijven zal mislukken (of wacht voor onbepaalde tijd) omdat de arbiter wordt geteld als een stemknooppunt.

Om deze reden wordt het gebruik van een arbiter niet aanbevolen als u van plan bent om w:majority te gebruiken in uw toepassing.

Houd er rekening mee dat het gebruik van een arbiter in een replicaset met 3 knooppunten die een shard vormt in een shard-cluster ook niet wordt aanbevolen, omdat voor het verplaatsen van chunks w:majority vereist is. . Het hebben van een data-dragende node-fout in één shard zal nadelig zijn voor chunk-migratiebewerkingen.