El nivel de confirmación de escritura (write concern) describe el nivel de reconocimiento solicitado por MongoDB para las operaciones de escritura en un mongod autónomo, sets de réplicas o clústeres. En clústeres fragmentados, las instancias mongos transmiten el nivel de confirmación de escritura (write concern) a los shards.
Nota
Para transacciones multi-documento, estableces el nivel de confirmación de escritura a nivel de transacción, no a nivel de operación individual. No establezcas explícitamente el nivel de confirmación de escritura 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 implementaciones alojadas en MongoDB Atlas, consulta Crear 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 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, se puede consultar Lecturas después de guardados { w: "mayoría" }.
Por ejemplo, consideremos un conjunto de réplicas con 3 miembros con derecho a voto, Primario-Secundario-Secundario (P-S-S). Para este conjunto de réplicas, la mayoría calculada 2es, y la escritura debe propagarse a los oplogs del primario y de un secundario para confirmar la escritura al cliente. Losmiembros ocultos, retrasados y de prioridad con mayor 0 Los secundarios demorados pueden devolver el reconocimiento de guardado no antes de lo configurado en el Si especifica una preocupación de escritura para las Consulte Comportamiento de confirmación para saber cuándo | |
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, retrasados y de prioridad pueden confirmar las operaciones de 0 Los secundarios demorados pueden devolver el reconocimiento de guardado no antes de lo configurado en el Consulte Comportamiento de confirmación para saber cuándo | |
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 Comportamiento de confirmación para saber cuándo |
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.
|
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 de transacciones está habilitado,
w: "majority"puedej: trueimplicar. LawriteConcernMajorityJournalDefaultconfiguración del conjunto de réplicas determina el comportamiento. Consulte Comportamiento de confirmación 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
La preocupación implícita por escritura w: majority predeterminada es. w: majority garantiza la durabilidad de la escritura al requerir que los conjuntos de réplicas esperen el registro en disco de forma predeterminada, controlado writeConcernMajorityJournalDefault por. Sin embargo, existe un caso límite para las implementaciones de conjuntos 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 fragmentado, lasoperaciones DDL (Lenguaje de Definición de Datos) se ejecutan con la condición de "majority" escritura. Si especifica una condición de escritura diferente, la operación anula la condición de escritura proporcionada "majority" con.
Comportamiento del reconocimiento
La opción w y la opción j determinan cuándo las instancias reconocen las operaciones de mongod 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 false en, MongoDB no espera a que escrituras w: "majority" "majority" se registren en el registro en disco antes de confirmarlas. Por lo tanto, operaciones de escritura podrían revertirse en caso de una pérdida transitoria (por ejemplo, un fallo y reinicio) de la mayoría de los nodos en un conjunto de réplicas determinado.
Sets de réplicas
El valor w determina la cantidad de miembros del conjunto de réplicas que deben confirmar la escritura antes de devolver éxito. Para cada miembro elegible, la opción j determina si el miembro confirma las escrituras después de aplicarlas en memoria o después de escribirlas en el registro en disco.
w: "majority"Cualquier miembro votante portador de datos del conjunto de réplicas puede contribuir a la confirmación de escritura de las
"majority"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 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
w: "majority"comportamiento, consulte Comportamiento.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, retrasados y de prioridad pueden confirmar las operaciones de 0 w: <number> escritura.
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 utiliza una preocupación de { w: n } escritura donde n es mayor que la mayoría calculada de los nodos del clúster y el clúster utiliza la configuración predeterminada, habilite la opción de preocupación de escritura "j" para confirmar la escritura en el registro. La preocupación de "majority" lectura solo le permite leer actualizaciones que son duraderas en la mayoría de los nodos del conjunto 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 preocupación de
"majority"escritura.
Para obtener más detalles, consulte la coherencia causal.
w: "majority" Comportamiento
Con
writeConcernMajorityJournalDefaultestablecidofalseen, MongoDB no espera a que escriturasw: "majority""majority"se registren en el registro en disco antes de confirmarlas. Por lo tanto, operaciones de escritura podrían revertirse en caso de una pérdida transitoria (por ejemplo, un fallo y reinicio) de la mayoría de los nodos en un conjunto de réplicas determinado.Losmiembros ocultos, retrasados y de prioridad con mayor 0
members[n].votesque0pueden reconocer"majority"operaciones de escritura.- 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.
El nivel de confirmación de escritura 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 la preocupación de escritura se calcula como el menor de los siguientes "majority" 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 miembros votantes que poseen datos, como en una implementación de árbitro 3primario-secundario con miembros, la preocupación de escritura "majority" puede expirar o no ser reconocida nunca si un miembro votante que posee datos está inactivo o no está disponible. Si es posible, utilice un miembro votante que posea 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.
La mayoría calculada 2 es, el mínimo de 2 3y. La escritura debe propagarse al primario y a uno de los secundarios para confirmar la preocupación de escritura al
"majority"cliente.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.
La mayoría calculada 2 es, el mínimo de 2 2y. Dado que la escritura solo se puede aplicar a los miembros que contienen datos, la escritura debe propagarse al primario y al secundario para confirmar la preocupación de escritura
"majority"al cliente.Tip
Evite usar write concern con P-S-A u otras topologías que requieran que todos los miembros votantes
"majority""majority"que contienen datos estén disponibles para confirmar las escrituras. Para las garantías de durabilidad de una write concern, implemente una topología que no requiera que todos los miembros votantes que contienen datos 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.