Preoccupazione per la scrittura di MongoDB:3 avvertenze da conoscere

'Scrivere preoccupazione' in MongoDB descrive il livello di riconoscimento della scrittura che puoi aspettarti da esso. È un'impostazione piuttosto importante da ricordare nelle operazioni di scrittura e il suo comportamento è utile per comprenderlo, specialmente nelle distribuzioni MongoDB distribuite (ad esempio set di repliche e cluster partizionati). In questo post, discutiamo di 3 problemi quando si utilizza la preoccupazione di scrittura di MongoDB.

Preoccupazione per la scrittura di MongoDB

La documentazione di MongoDB definisce il problema di scrittura come "il livello di riconoscimento richiesto da MongoDB per le operazioni di scrittura su un mongod autonomo o per replicare set o cluster partizionati. “

In parole povere, un problema di scrittura è un'indicazione di "durabilità" passata insieme alle operazioni di scrittura su MongoDB. Per chiarire, esaminiamo la sintassi:

{ 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.

* Puoi trovare la sintassi dettagliata nella documentazione di Write Concern Specification.

* Scopri di più sui diversi "tag" che puoi utilizzare per i valori comuni relativi ai problemi di scrittura nel nostro blog Capire la durabilità e la sicurezza in scrittura in MongoDB.

Esempio:

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

Il problema di scrittura dell'inserto sopra può essere letto come segue: riconosci questa scrittura quando "almeno 2 membri del set di repliche l'hanno scritta nei loro diari entro 5000 msec o restituiscono un errore '. Un valore di preoccupazione di scrittura per l'opzione era maggioranza, il che significa "richiede il riconoscimento che le operazioni di scrittura si sono propagate alla maggior parte dei nodi di voto, incluso il primario. “

L'importanza della preoccupazione per la scrittura è evidente. L'aumento dei valori di w aumenta la latenza delle scritture diminuendo anche la probabilità di perdersi. La scelta dei valori corretti per i problemi di scrittura dipende dai requisiti di latenza e durabilità delle scritture eseguite.

Con questo come sfondo su cosa sia un problema di scrittura, passiamo ai tre avvertimenti da ricordare quando si utilizza un problema di scrittura.

ATTENZIONE 1: l'impostazione del problema di scrittura sui set di repliche senza wtimeout può causare il blocco indefinito delle scritture

La definizione di maggioranza (applicabile da MongoDB 3.0 in poi) afferma che il riconoscimento è richiesto dalla maggioranza dei "nodi votanti". Nota che "Se non specifichi il wtimeout opzione e il livello di problema di scrittura è irraggiungibile, l'operazione di scrittura si bloccherà a tempo indeterminato. “

Ciò può avere conseguenze impreviste, ad esempio, considera un set di repliche 2+1 (cioè un primario, un secondario e un arbitro). Se la tua unica replica di lettura non funziona, tutte le scritture con un problema di scrittura w l'opzione "maggioranza" si bloccheranno a tempo indeterminato. Lo stesso accadrà se l'opzione w è impostata su 2. Un altro esempio estremo è nel caso di un set di repliche 3+2 (primario, 2 secondari e 2 arbitri, configurazione non consigliata). Tutte le scritture di "maggioranza" verranno bloccate anche se un singolo nodo di dati non è disponibile poiché il numero maggioritario, in questo caso, è 3.

Il modo più semplice per alleviare questo problema è specificare sempre un valore di wtimeout in modo che la query possa scadere se non è possibile applicare il problema di scrittura. Tuttavia, in caso di tali errori di timeout, MongoDB non annulla le scritture già eseguite con successo su alcuni membri prima che si verificasse il timeout.

Al momento non ci sono impostazioni per garantire che una scrittura raggiunga la maggior parte dei nodi che sono attualmente raggiungibili, quindi fai attenzione a impostare il valore della preoccupazione di scrittura w in base alla topologia, desiderata durata e disponibilità.

ATTENZIONE 2: potresti perdere dati anche con w:maggioranza

Sembra intuitivo che una volta che una scrittura è stata riconosciuta dalla maggioranza dei membri votanti, la sua durata è garantita. Tuttavia, non è il caso! Ricorda che quando l'opzione j non è specificata, una scrittura viene confermata subito dopo che è stata scritta in memoria.

Quindi, una tale scrittura può andare persa se un'interruzione di corrente improvvisa elimina la maggior parte dei nodi a cui si era propagata la scrittura (e prima di syncPeriodSecs, ovvero prima che potesse essere scaricato su disco).

Per garantire la durabilità delle scritture, è meglio non disattivare il journaling sul database e impostare l'opzione j su true. Infatti, a partire da MongoDB 3.6, il --nojournal flag è stato ritirato per i membri del set di repliche che utilizzano il motore di archiviazione WiredTiger.

Con un valore w di "maggioranza" e l'opzione j non specificata su un set di repliche, l'esatto comportamento di durabilità dipende dal valore della configurazione del set di repliche writeConcernMajorityJournalDefault. Se impostato su true (e quando l'inserimento nel diario è abilitato), riconosce le scritture dopo che sono state scritte nei diari della maggioranza dei membri votanti.

A parte:anche con l'inserimento nel journal attivato, le tue scritture potrebbero comunque andare perse nel motore di archiviazione MMAPv1 se si verifica un'interruzione entro la durata di commitIntervalMs. Il motore di archiviazione WiredTiger, d'altra parte, forza una sincronizzazione dei file journal quando riceve una scrittura con l'opzione j impostata su true. E, anche con j impostato su false, una scrittura di "maggioranza" riconosciuta su un'ultima distribuzione basata su WiredTiger può essere persa solo quando la maggior parte dei nodi di dati si arresta in modo anomalo contemporaneamente.

CAVEEAT 3: w:0 mentre si imposta j:true non migliora le prestazioni di scrittura

Questo è abbastanza facile da ragionare una volta che ci pensi, ma altrettanto facile da dimenticare. L'impostazione dell'opzione w su 0 viene solitamente eseguita per scrivere nel database in modo "indimenticabile", quando si ha una buona dose di fiducia nell'infrastruttura del database e ci si preoccupa più della latenza che della durabilità di ogni scrittura. Tuttavia, se imposti l'opzione j su true, la tua opzione w verrà effettivamente sovrascritta poiché il database assicurerà che la scrittura venga scritta nel diario su disco prima di tornare.

Se stai utilizzando i problemi di scrittura per garantire il successo delle tue operazioni di scrittura, assicurati di ricordare questi tre avvertimenti cruciali! Siamo qui per aiutarti, quindi sentiti libero di connetterti con qualsiasi domanda tramite Twitter o via e-mail.