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 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, considera un set de réplicas con 3 miembros con derecho a voto, Primario-Secundario-Secundario (P-S-S). Para este set de réplicas, la mayoría calculada es dos, y la escritura debe propagarse a los oplogs del primario y de un secundario para confirmar el nivel de confirmación 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 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.
Lecturas después de { w: "mayoría" } guardados
A partir de MongoDB 8.0, las escrituras de { w: "majority" } devuelven un reconocimiento después de que la mayoría de los nodos que contienen datos escriben de manera duradera la entrada del registro de operaciones (oplog). Los nodos luego aplican los cambios de forma asincrónica a medida que los leen de sus registros de operaciones locales. En versiones anteriores, MongoDB esperaba hasta después de que los miembros aplicaran la escritura para devolver el reconocimiento.
Las queries en los secundarios inmediatamente después de que una escritura { w: "majority" } devuelva un acuse de recibo pueden leer de la colección antes de que el secundario aplique los cambios de guardado.
Si su aplicación lee desde los secundarios y requiere acceso inmediato a los cambios realizados en las escrituras { w: "majority" }, ejecute estas operaciones en una sesión causalmente coherente.
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:
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.