La preocupación de escritura describe el nivel de reconocimiento solicitado a MongoDB para operaciones de escritura en una base de datos independiente. mongod, conjuntos de réplicas o clústeres fragmentados. En los clústeres fragmentados, mongos las instancias transferirán el problema de escritura a los fragmentos.
Nota
Para transacciones de múltiples documentos, configure la preocupación de escritura en el nivel de transacción, No a nivel de operación individual. No establezca explícitamente la preocupación de escritura para operaciones de escritura individuales en una transacción.
Los sets de réplicas y los clústeres fragmentados ofrecen soporte para definir un nivel de confirmación de escritura global por defecto. Las operaciones que no especifican un nivel de confirmación de escritura explícito heredan la configuración global por defecto del nivel de confirmación de escritura. El nivel de confirmación de escritura global por defecto es la 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 Cree 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> }
la opción w para solicitar un acuse de recibo de que la operación de escritura se ha propagado a un número especificado de instancias
mongodo a instanciasmongodcon etiquetas especificadas.la opción j para la solicitud de reconocimiento de que la operación de guardado se ha registrado en la bitácora en disco, y
la opción wtimeout para especificar un límite de tiempo para evitar que las operaciones de guardado se bloqueen 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.
Al usar la opción w, están disponibles los niveles de confirmación de escritura w: <value> siguientes:
Valor | Descripción |
|---|---|
Solicita confirmación de que las operaciones de escritura se han confirmado de forma duradera con la mayoría calculada de los miembros con derecho a voto que contienen datos (es decir, los miembros principales y secundarios con mayor Por ejemplo, considere un conjunto de réplicas con 3 miembros con derecho a voto, Primario-Secundario-Secundario (PSS). Para este conjunto de réplicas, lamayoría calculada es de dos, y la escritura debe propagarse al primario y al secundario para confirmar el problema de escritura 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 Después de que la operación de escritura regresa con un reconocimiento al cliente, el cliente puede Si especifica una preocupación de escritura para las 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 3 nodos con un primario y 2 secundarios. Especificar 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 personalizado solo requiere reconocimiento del primario y el primario se retira antes de que las operaciones de escritura se hayan replicado en cualquiera 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.
Si Con |
Nota
Se produce un error al especificar un nivel de confirmación de escritura que incluya
j: trueen una instanciamongodque se esté ejecutando sin registrar en la bitácora.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 a fin de lograr el nivel de confirmación de escritura después de que la operación tenga éxito en el primario. Si w es menor o igual a 1, wtimeout no se aplica. Si la operación de escritura no alcanza el nivel de confirmación de escritura dentro de este límite de tiempo, MongoDB devuelve un error de nivel de confirmación de escritura.
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
Un mongod autónomo reconoce una operación de guardado ya sea después de aplicar la escritura en la memoria o después de escribir en el registro en la bitácora en el disco. La siguiente tabla enumera el comportamiento de reconocimiento para un autónomo y los niveles de confirmación de escritura 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 especificado para w determina el número de nodos del set de réplicas que deben confirmar la escritura antes de devolver el éxito. Para cada nodo elegible del set de réplicas, la opción j determina si el nodo reconoce las escrituras después de aplicar la operación de escritura en la memoria o después de escribir en el diario 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 al sincronizarlas con la bitácora en disco (j: true).writeConcernMajorityJournalDefaultpor defecto entrueSi es
false, el reconocimiento requiere una operación de escritura en la memoria (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.
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 (
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.
Información Adicional
Recomendaciones sobre problemas de lectura y escritura
Para leer sus propias escrituras en el primario, normalmente utilice el nivel de consistencia de lectura "majority" y realice escrituras con el nivel de confirmación de escritura {
w: "majority" }.
Si debe usar un nivel de confirmación de escritura { w: n }, donde n es mayor que la mayoría calculada de los nodos del clúster, y el clúster utiliza la configuración por defecto, asegúrese de que la opción “j” del nivel de confirmación de escritura esté activada para confirmar la escritura en la bitácora. Esto se debe a que el nivel de consistencia de lectura "majority" solo le permite leer las actualizaciones que son durables en la mayoría de los nodos en el set de réplicas.
Nota
Si realiza escrituras con un nivel de confirmación de escritura { w: n } y n es mayor que la mayoría calculada, pero sin registrar en la bitácora y con la configuración del clúster por defecto, es posible que reciba una confirmación 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
Con sesiones de cliente con coherencia causal, las sesiones de cliente solo garantizan la coherencia causal 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.
Escribir inquietud no admitida en la local base de datos
La base de datos local no admite nivel de confirmación de escritura. MongoDB ignora silenciosamente cualquier nivel de confirmación de escritura configurado para una operación en una colección 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 (incluidos los árbitros) vs.
la cantidad de todos los miembros votantes que contienen datos.
Advertencia
En los casos en que el número de la mayoría calculada sea igual al número de todos los nodos votantes con datos (como en una implementación de 3 nodos primario, secundario y árbitro), el nivel de confirmación de escritura "majority" puede agotar el tiempo de espera o no confirmarse nunca si un nodo votante que contiene datos está inactivo o es inaccesible. Si es posible, utilice un nodo votante con 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 the write concern"majority"to the client.Tip
Evite usar un
"majority"nivel de confirmación de escritura con un (P-S-A) u otras topologías que requieran que todos los miembros con derecho a voto que contienen datos estén disponibles para reconocer las escrituras. Los clientes que desean las garantías de durabilidad de usar un"majority"nivel de confirmación de escritura deberían, en su lugar, implementar una topología que no requiera que todos los miembros votantes con datos estén disponibles (p. ej.: 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:
Las compilaciones de índices utilizan quórums de confirmación.
Las operaciones de escritura utilizan preocupaciones 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 votantes que contienen datos, o qué miembros votantes, incluido el principal, deben estar preparados para confirmar una creación de índice simultánea antes de que el principal ejecute la confirmación.
La preocupación de escritura es el nivel de reconocimiento de que la escritura se ha propagado a la cantidad especificada de instancias.
El quórum de confirmación especifica cuántos nodos deben estar listos para finalizar la compilación del índice antes de que el nodo principal la confirme. Por el contrario, cuando el nodo principal ha confirmado la compilación del índice, la preocupación de escritura especifica cuántos nodos deben finalizarla antes de que el comando regrese.