Nivel de confirmación de escritura (write concern) describe el nivel de reconocimiento requerido de MongoDB para las operaciones de escritura en una instancia autónoma. mongod, sets de réplicas, o clústeres fragmentados. En clústeres particionados, las instancias mongos pasan el nivel de confirmación de escritura (write concern) a las particiones.
Nota
Para las transacciones multi-documento, se establece el nivel de confirmación de escritura al nivel de transacción, no al nivel de operación individual. No establezcas explícitamente el nivel de confirmación de escritura (write concern) para operaciones de escritura individuales en una transacción.
Los sets de réplicas y los clústeres admiten un nivel de confirmación de escritura (write concern) por defecto global. Las operaciones sin un nivel de confirmación de escritura (write concern) explícito heredan la configuración global por defecto. El nivel de confirmación de escritura (write concern) global por defecto es mayoría. Consulte setDefaultRWConcern para obtener más información.
Para obtener más información sobre cómo configurar el nivel de confirmación de escritura (write concern) para las implementaciones alojadas en MongoDB Atlas, consulta Compile una aplicación resiliente con MongoDB Atlas
Especificación de nivel de confirmación de escritura
El nivel de confirmación de escritura puede incluir los siguientes campos:
{ w: <value>, j: <boolean>, wtimeout: <number> }
w: Solicita la confirmación de que la operación de escritura se ha propagado a un número específico de instancias de
mongodo a instancias demongodcon etiquetas específicas.j: Solicita una confirmación de que la operación de guardar ha sido guardada en el diario en disco.
wtimeout: Especifica un límite de tiempo para evitar que las operaciones de escritura permanezcan bloqueadas indefinidamente.
w Opción
La opción w solicita confirmación de que la operación de guardado se ha propagado a un número especificado d e instancias de mongod o a instancias de mongod con etiquetas especificadas. Si falta el campo w en el nivel de confirmación de escritura, MongoDB establece la opción w en el nivel de confirmación de escritura por defecto.
Nota
Si utiliza el setDefaultRWConcern para establecer el nivel de confirmación de escritura por defecto, debe especificar un valor para el campo w.
La opción w admite los siguientes w: <value> niveles de confirmación de escritura (write concern):
Valor | Descripción |
|---|---|
Solicita el reconocimiento de que la mayoría calculada de los miembros con derecho a voto que contienen datos hayan escrito de manera duradera el cambio en su oplog local. Los nodos luego aplican cambios de forma asincrónica a medida que los leen de sus registros de operaciones locales. Los miembros con derecho a voto que portan datos de un set de réplicas son el miembro primario y cualquier miembro secundario con Para obtener más información, consulte Lecturas después de guardados { w: "mayoría" }.
Por ejemplo, imagine un set de réplicas con 3 nodos con derecho a voto, Primario-Secundario-Secundario (P-S-S). Para este conjunto de réplicas, la mayoría calculada es 2, y la escritura debe propagarse a los oplogs del primario y de un secundario para reconocer el nivel de confirmación de escritura (write concern) al cliente. Los miembros ocultos, demorados y de prioridad 0 con Los secundarios demorados pueden devolver el reconocimiento de guardado no antes de lo configurado en el Si especificas un Consulte el Comportamiento de reconocimiento para cuando las instancias | |
Solicita confirmación de que la operación de guardado se ha propagado al número especificado de instancias de
Por ejemplo, considera un set de réplicas de 3nodos con un primario y 2 secundarios. La especificación de Los miembros ocultos, demorados y de prioridad 0 pueden confirmar Los secundarios demorados pueden devolver el reconocimiento de guardado no antes de lo configurado en el Consulte el Comportamiento de reconocimiento para cuando las instancias | |
Solicita confirmación de que las operaciones de escritura se hayan propagado a los miembros de Los datos se pueden revertir si el nivel de confirmación de escritura (write concern) personalizado solo requiere el reconocimiento del primario y este lo abandona antes de que las operaciones de escritura se repliquen en alguno de los secundarios. Consulte el Comportamiento de reconocimiento para cuando las instancias |
j Opción
La opción j solicita el reconocimiento de MongoDB de que la operación de escritura se ha registrado en el registro en la bitácora en el disco.
Con |
Nota
Especificar un nivel de confirmación de escritura (write concern) que incluya
j: truea una instancia demongodejecutándose sin registrar en la bitácora generará un error.Si el registro en la bitácora está habilitado,
w: "majority"puede implicarj: true. La configuración del set de réplicaswriteConcernMajorityJournalDefaultdetermina el comportamiento. Consulta Comportamiento del reconocimiento para obtener más detalles.Un nivel de confirmación de escritura que incluye o implica
j: trueprovoca una sincronización inmediata del registro en la bitácora. Consulta el Proceso de registro en la bitácora.
wtimeout
Esta opción especifica un límite de tiempo, en milisegundos, para que una operación de escritura se propague a suficientes nodos para lograr el nivel de confirmación de escritura (write concern) después de que la operación tenga éxito en el primario. wtimeout no se aplica si w es menor o igual a 1. Si la operación de escritura no cumple con el nivel de confirmación de escritura (write concern) dentro de este límite de tiempo, MongoDB devuelve un error de nivel de confirmación de escritura (write concern).
wtimeout provoca que las operaciones de escritura devuelvan un error de nivel de confirmación de escritura después del límite especificado, incluso si el nivel de confirmación de escritura requerido finalmente tiene éxito. Cuando estas operaciones de escritura regresan, MongoDB no deshace las modificaciones de datos exitosas realizadas antes de que el nivel de confirmación de escritura excediera el límite de tiempo wtimeout.
Si no especificas la opción wtimeout y el nivel de confirmación de escritura es inalcanzable, la operación de escritura se bloqueará indefinidamente. Especificar un valor wtimeout de 0 es equivalente a un nivel de confirmación de escritura sin la opción wtimeout.
Nota
Para establecer un límite de tiempo en la operación de escritura del primario, utilice el método maxTimeMS().
Nivel de confirmación de escritura por defecto implícito
El nivel de confirmación de escritura por defecto implícito es w: majority. w: majority garantiza la durabilidad de escritura al requerir que los sets de réplicas esperen el registro en la bitácora en disco por defecto, controlado por writeConcernMajorityJournalDefault. Sin embargo, hay un caso límite para las implementaciones de sets de réplicas que contienen árbitros:
La mayoría de los votos de un conjunto de réplicas es igual a 1 más la mitad del número de miembros con derecho a voto, redondeada hacia abajo. Si el número de miembros con derecho a voto que contienen datos no es mayor que la mayoría de los votos, el nivel de confirmación de escritura por defecto es
{ w: 1 }.En todos los demás escenarios, el nivel de confirmación de escritura por defecto es
{ w: "majority" }.
Específicamente, MongoDB usa la siguiente fórmula para determinar el nivel de confirmación de escritura por defecto:
if [ (#arbiters > 0) AND (#non-arbiters <= majority(#voting-nodes)) ] defaultWriteConcern = { w: 1 } else defaultWriteConcern = { w: "majority" }
Por ejemplo, considera las siguientes implementaciones y sus respectivos niveles de confirmación de escritura por defecto:
Non-Arbiters | Árbitros | Nodos de votación | Mayoría de nodos de votación | Nivel de confirmación de escritura por defecto implícito |
|---|---|---|---|---|
2 | 1 | 3 | 2 |
|
4 | 1 | 5 | 3 |
|
En el primer ejemplo:
Hay 2 miembros no árbitros y 1 árbitro, para un total de 3 nodos con derecho a voto.
La mayoría de los nodos de votación (1 más la mitad de 3, redondeado hacia abajo) es 2.
El número de miembros no árbitros (2) es igual a la mayoría de los nodos de votación (2), lo que genera un nivel de confirmación de escritura implícita de
{ w: 1 }.
En el segundo ejemplo:
Hay 4 miembros no árbitros y 1 árbitro para un total de 5 nodos de votación.
La mayoría de los nodos de votación (1 más la mitad de 5, redondeado hacia abajo) es 3.
El número de miembros que no son árbitros (4) es mayor que la mayoría de los nodos con derecho a voto (3), lo que resulta en un nivel de confirmación de escritura implícito de
{ w: "majority" }.
En un clúster particionado, las operaciones DDL (Lenguaje de definición de datos) se ejecutan con el nivel de confirmación de escritura "majority". Si especifica un nivel de confirmación de escritura diferente, la operación reemplaza el nivel de confirmación de escritura proporcionado con "majority".
Comportamiento del reconocimiento
La opción w y la opción j determinan cuándo las instancias de mongod confirman las operaciones de escritura.
Autónomo
Una mongod autónoma reconoce una operación de escritura después de aplicarla en la memoria o después de guardar en el diario en disco. La siguiente tabla enumera el comportamiento de acuse de recibo para una instancia autónoma con los niveles de confirmación de escritura (write concern) relevantes:
j no está especificado | j:true | j:false | |
|---|---|---|---|
| En memoria | On-disk journal | En memoria |
| Registro en la bitácora en disco cuando se ejecuta en modo journaling | On-disk journal | En memoria |
Nota
Con writeConcernMajorityJournalDefault establecido en false, MongoDB no espera que las escrituras w: "majority" se registren en la bitácora en disco antes de confirmar las escrituras. Por lo tanto, "majority" las operaciones de escritura podrían revertirse en caso de una pérdida transitoria (por ejemplo, caída y reinicio) de la mayoría de los nodos en un set de réplicas determinado.
Sets de réplicas
El valor w determina el número de miembros del set de réplicas que deben reconocer la operación de guardar antes de devolver el éxito. Para cada nodo elegible, la opción j determina si el nodo reconoce las escrituras después de aplicando la escritura en la memoria o después de escribir en el registro en disco.
w: "majority"Cualquier nodo con derecho a voto del set de réplicas que contenga datos puede contribuir al reconocimiento de guardado de las operaciones de escritura
"majority".La siguiente tabla enumera cuándo el nodo puede confirmar la operación de guardado en función del valor j:
jno está especificadoEl reconocimiento depende del valor de
writeConcernMajorityJournalDefault:Si
true, el reconocimiento requiere que MongoDB haga que las escrituras sean duraderas sincronizándolas con el diario en disco, equivalente aj: true.writeConcernMajorityJournalDefaultpor defecto entrueSi
false, el reconocimiento requiere una operación de escritura en memoria, equivalente aj: false.
j: trueEl reconocimiento requiere que MongoDB haga que las escrituras sean duraderas al sincronizarlas con la bitácora en disco.
j: falseEl reconocimiento requiere una operación de escritura en la memoria.
Normalmente, si
j: falseestá configurado, no es necesario escribir la operación en el registro en disco. Sin embargo, siwriteConcernMajorityJournalDefault: trueestá configurado, es necesario registrar la operación en el registro en la bitácora incluso sij: falseestá configurado.Si se configuran
j: falseywriteConcernMajorityJournalDefault: true, las operaciones de guardado se registran en el diario de manera asíncrona.Los guardados que tienen
w: majorityconfigurado no se reconocen como completos hasta que el registro se vacía en el disco.w: majoritylas escrituras esperan a que se complete el snapshot de lectura"majority", independientemente de la configuración dej. Esto se debe a que si se establecewriteConcernMajorityJournalDefault: true, el snapshot de lectura mayoritaria se basa en la mayoría de las escrituras registradas en la bitácora.Después de que la operación de escritura devuelva un reconocimiento
w: majoritya la aplicación del cliente, la aplicación puede leer el resultado de la acción de escritura si se establece el nivel de consistencia de lecturamajority.
Para obtener detalles sobre el comportamiento, consulta el comportamiento de
w: "majority".w: <number>Cualquier nodo portador de datos del set de réplicas puede contribuir al reconocimiento de escritura de w: <number> operaciones de escritura.
La siguiente tabla enumera cuándo el nodo puede confirmar la operación de guardado en función del valor j:
jno está especificadoEl reconocimiento requiere una operación de escritura en la memoria, equivalente a
j: false.j: trueEl reconocimiento requiere que MongoDB haga que las escrituras sean duraderas al sincronizarlas con la bitácora en disco.
j: falseEl reconocimiento requiere una operación de escritura en la memoria.
Nota
Los miembros ocultos, demorados y de prioridad 0 pueden confirmar w: <number> operaciones de guardado.
Los secundarios demorados pueden devolver el reconocimiento de guardado no antes de lo configurado en el secondaryDelaySecs.
Lecturas después de { w: "mayoría" } guardados
A partir de MongoDB 8.0, { w: "majority" } operaciones de guardado devuelven un acuse de recibo después de que la mayoría de los nodos que contienen datos escriban de forma duradera la entrada del oplog. Los nodos luego aplican los cambios de manera asíncrona a medida que los leen desde sus(oplogs) locales. En versiones anteriores, MongoDB esperaba hasta que los nodos aplicaran la operación de guardar antes de devolver el reconocimiento.
Las queries en secundarios inmediatamente después de un reconocimiento de guardado de { w: "majority" } pueden leer desde la colección antes de que el secundario aplique los cambios del guardado.
Si tu aplicación lee de secundarios y requiere acceso inmediato a los cambios de { w: "majority" } guardados, ejecuta estas operaciones en una sesión causalmente coherente.
Información Adicional
Recomendaciones sobre problemas de lectura y escritura
Para leer tus propias escrituras en el principal, utiliza la "majority" nivel de consistencia de lectura y el nivel de confirmación de escritura (write concern) { w: "majority" }.
Si utilizas un nivel de confirmación de escritura { w: n } donde n es superior a la mayoría calculada de los nodos del clúster y el clúster utiliza la configuración predeterminada, habilita la opción "j" de write concern para confirmar el guardado en la bitácora. La "majority" nivel de consistencia de lectura solo permite leer actualizaciones que sean duraderas en la mayoría de los nodos del set de réplicas.
Nota
Si realizas escrituras con un nivel de confirmación de escritura (write concern) { w: n } y n es mayor que la mayoría calculada, sin registrar en la bitácora y con la configuración por defecto del clúster, es posible que recibas un reconocimiento de escritura antes de que la escritura sea durable en la mayoría de los nodos.
Sesiones causalmente coherentes y niveles de confirmación de escritura
Las Sesiones de cliente causalmente coherentes garantizan la coherencia causal solo si:
las operaciones de lectura asociadas utilizan el
"majority"nivel de consistencia de lectura, ylas operaciones de escritura asociadas utilizan el nivel de confirmación de escritura
"majority".
Para obtener más detalles, consulte la coherencia causal.
w: "majority" Comportamiento
Con
writeConcernMajorityJournalDefaultestablecido enfalse, MongoDB no espera que las escriturasw: "majority"se registren en la bitácora en disco antes de confirmar las escrituras. Por lo tanto,"majority"las operaciones de escritura podrían revertirse en caso de una pérdida transitoria (por ejemplo, caída y reinicio) de la mayoría de los nodos en un set de réplicas determinado.Los nodos ocultos, demorados y de prioridad 0 con
members[n].votesmayor que0pueden confirmar las operaciones de guardado"majority".Los secundarios demorados pueden devolver el reconocimiento de guardado no antes de lo configurado en el
secondaryDelaySecs.
A partir de MongoDB 5.0, los nodos del set de réplicas en el estado
STARTUP2no participan en mayorías de escritura.
nivel de confirmación de escritura (write concern) no es compatible con la base de datos local
La base de datos local no admite nivel de confirmación de escritura (write concern). MongoDB ignora silenciosamente cualquier nivel de confirmación de escritura (write concern) configurado para las operaciones en las colecciones de la base de datos local.
Cálculo de la mayoría para el nivel de confirmación de escritura
Tip
El rs.status() devuelve el campo writeMajorityCount que contiene el número de mayoría calculado.
La mayoría para el nivel de confirmación de escritura "majority" se calcula como el menor de los siguientes valores:
la mayoría de todos los miembros con derecho a voto, incluyendo los árbitros
el número de todos los nodos con derecho a voto que posean datos
Advertencia
Si la mayoría calculada es igual al número de todos los nodos con datos que pueden votar, como en una implementación Primary-Secondary-Arbiter de 3nodos, el nivel de confirmación de escritura (write concern) "majority" puede agotar el tiempo de espera o nunca ser confirmada si un nodo con datos que puede votar está caído o no se puede acceder a él. Si es posible, utilice un miembro votante que contenga datos en lugar de un árbitro.
Por ejemplo, considere lo siguiente:
Un set de réplicas con 3 nodos votantes, primario-secundario-secundario (P-S-S):
La mayoría de todos los nodos con derecho a voto es 2.
La cantidad total de miembros con derecho a voto que contienen datos es 3.
The calculated majority is 2, the minimum of 2 and 3. The write must propagate to the primary and one of the secondaries to acknowledge the write concern"majority"to the client.Un set de réplicas con 3 miembros con derecho a voto, Primario-Secundario-Árbitro (P-S-A):
La mayoría de todos los nodos con derecho a voto es 2.
La cantidad total de miembros con derecho a voto que contienen datos es 2.
The calculated majority is 2, the minimum of 2 and 2. Since the write can only be applied to data-bearing members, the write must propagate to the primary and the secondary to acknowledge write concern"majority"to the client.Tip
Evite usar
"majority"nivel de confirmación de escritura (write concern) con P-S-A u otras topologías que requieran que todos los miembros votantes que almacenan datos estén disponibles para acuse de recibo correctamente las escrituras. Para las garantías de durabilidad de un"majority"nivel de confirmación de escritura (write concern), implemente una topología que no requiera que todos los miembros que contienen datos y tienen derecho a voto estén disponibles, como P-S-S.
Advertencia
Evita implementar más de un árbitro en un set de réplicas. Consulta Preocupaciones con múltiples árbitros.
Agregar un árbitro a un set de réplicas existente:
Por lo general, si hay dos o menos miembros que contengan datos en el set de réplicas, es posible que primero debas configurar el nivel de confirmación de escritura a nivel de clúster para el set de réplicas.
Consulte el nivel de confirmación de escritura para todo el clúster para obtener más información sobre por qué podría necesitar establecer el nivel de confirmación de escritura para todo el clúster.
No necesitas cambiar el nivel de confirmación de escritura a nivel de clúster antes de iniciar un nuevo set de réplicas con un árbitro.
Procedencia de nivel de confirmación de escritura
MongoDB rastrea el nivel de confirmación de escritura provenance, que indica el origen de un nivel de confirmación de escritura particular. Es posible que vea provenance en las métricas de getLastError, objetos de error de nivel de confirmación de escritura y registros de MongoDB.
La siguiente tabla muestra los posibles valores del nivel de confirmación de escritura provenance y su significado:
Origen | Descripción |
|---|---|
| El nivel de confirmación de escritura se especificó en la aplicación. |
| El nivel de confirmación de escritura se originó a partir de un valor por defecto personalizado. Vea |
| El nivel de confirmación de escritura se originó en el campo |
| El nivel de confirmación de escritura (write concern) se originó en el servidor en ausencia de todas las demás especificaciones de nivel de confirmación de escritura (write concern). |
Nivel de confirmación de escritura en contraste con quórum de confirmación
Existen diferencias importantes entre los quórums de confirmación y los niveles de confirmación de escritura:
La creación de índices utiliza quórums de confirmación.
Las operaciones de guardado utilizan el nivel de confirmación de escritura.
Cada nodo que lleva datos en un clúster es un miembro votante.
El quórum de confirmación especifica cuántos miembros con derecho a voto que contienen datos o qué miembros con derecho a voto, incluido el primario, deben estar preparados para comprometerse a una creación de índices simultánea antes de que el primario ejecute la confirmación.
El nivel de confirmación de escritura es el nivel de reconocimiento de que la escritura se propagó a la cantidad especificada de instancias.
Modificado en la versión 8.0: El quórum de confirmación especifica cuántos miembros deben estar listos para completar la creación de índices antes de que el primario confirme la creación de índices. Por el contrario, cuando el primario ha confirmado la creación de índices, el nivel de confirmación de escritura especifica cuántos nodos deben replicar la entrada del oplog de creación de índices antes de que el comando devuelva éxito.
En versiones anteriores, cuando el nodo primario confirmaba la creación de índices, el nivel de confirmación de escritura especificaba cuántos nodos debían completar la creación de índices antes de que el comando devolviera éxito.