Il problema di scrittura predefinito in MongoDB è stato w:1 da MongoDB 2.2 nel 2012.
Ci sono tre diverse impostazioni che puoi usare per impostare il problema di scrittura nelle attuali versioni di MongoDB (versione 3.2.6 e successive):
wimpostazione :quanti nodi dovrebbero riconoscere la scrittura prima di dichiararla riuscita. Il valore predefinito è 1, il che significa che il riconoscimento del nodo primario è sufficiente.jimpostazione :le scritture devono essere registrate su giornale prima di essere riconosciute? L'impostazione predefinita dipende dawriteConcernMajorityJournalDefault.- writeConcernMajorityJournalDefault
:se specifichi
w:majorityscrivi impostazione di preoccupazione per le tue scritture senza impostarej, qual è il implicitojvalore? L'impostazione predefinita ètrue(le scritture devono essere registrate su diario nella maggior parte dei nodi di voto prima di essere riconosciute).
C'è anche un wtimeout impostazione
per configurare per quanto tempo MongoDB deve attendere che il problema di scrittura sia soddisfatto prima di informare il client che la scrittura non è stata riconosciuta. In caso contrario, le scritture in attesa che il problema di scrittura sia soddisfatto possono attendere per sempre invece di fallire.
L'impostazione speciale qui è w:majority . Ciò significa che le scritture devono propagarsi alla maggioranza dei nodi di voto (e anche ai loro diari) in un set di repliche da riconoscere. Questa è probabilmente l'impostazione più sicura pur fornendo buone prestazioni, perché:
- Evita il rollback delle scritture riconosciute in caso di errori.
- Regola il throughput dell'applicazione in modo che non invii le scritture più velocemente di quanto il set di repliche possa gestire (a causa di vincoli hardware, situazione della rete, ecc.).
Come hai immaginato, i nodi di voto includono l'arbitro . Pertanto, in un set di repliche con configurazione dell'arbitro primario-secondario, w:majority potrebbe fallire in uno scenario in cui:
- Uno dei nodi portanti dati è offline per qualche motivo.
- Il set di repliche è ancora online con un primario scrivibile, poiché la topologia è ora primario-arbitro-offline.
- Scrive con
w:1avrà esito positivo come al solito, ma è possibile eseguire il rollback di tali scritture (dal momento che non è stato scritto nella maggior parte dei nodi con dati di voto). - Dato che l'arbitro non ha dati,
w:majorityle scritture falliranno (o attenderà indefinitamente) poiché l'arbitro viene conteggiato come nodo di voto.
Per questo motivo, non è consigliabile utilizzare un arbitro se prevedi di utilizzare w:majority nella tua applicazione.
Tieni presente che anche l'utilizzo di un arbiter in un set di repliche a 3 nodi che forma uno shard in un cluster suddiviso in partizioni non è consigliato, poiché gli spostamenti dei blocchi richiedono w:majority . L'errore di un nodo contenente dati in uno shard sarà dannoso per le operazioni di migrazione dei blocchi.
