Docs Menu
Docs Home
/
Manual de base de datos
/

Nivel de confirmación de escritura

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 para implementaciones alojadas en MongoDB Atlas, consulta Crear una aplicación resiliente con MongoDB Atlas

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 mongod o a instancias mongod con 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.

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
"majority"

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 members[n].votes 0 que). { w: "majority" } es la prioridad de escritura predeterminada para la mayoría de las implementaciones de MongoDB.Consulte la prioridad de escritura predeterminada implícita.

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 members[n].votes mayor que 0 pueden confirmar "majority" operaciones de guardado.

Los secundarios demorados pueden devolver el reconocimiento de guardado no antes de lo configurado en el secondaryDelaySecs.

Después de que la operación de escritura regresa con un reconocimiento al cliente, el cliente puede w: "majority" "majority" leer el resultado de esa escritura con un readConcern.

Si especificas un nivel de confirmación de escritura "majority" para operaciones de guardar documentos individuales y múltiples y la operación no se replica a la mayoría calculada de los miembros del set de réplicas antes de que devuelva una respuesta, entonces los datos eventualmente se replican o se revierten. Consulta wtimeout.

Consulte el Comportamiento de reconocimiento para cuando las instancias mongod confirman el guardado.

<number>

Solicita confirmación de que la operación de guardado se ha propagado al número especificado de instancias de mongod. Por ejemplo:

w: 1

Solicita confirmación de que la operación de escritura se ha propagado al mongod autónomo o al primario en un set de réplicas. Los datos se pueden revertir si el primario se desactiva antes de que las operaciones de escritura se hayan replicado en cualquiera de los secundarios.

ADVERTENCIA: Si las operaciones de escritura utilizan el nivel de confirmación de escritura { w: 1 }, el directorio de rollback puede excluir las escrituras enviadas después de un oplog hole si el primario se reinicia antes de que se complete la operación de escritura.

w: 0

No solicita confirmación de la operación de escritura. Sin embargo, w: 0 puede devolver información sobre excepciones de socket y errores de red a la aplicación. Los datos se pueden revertir si el primario se desactiva antes de que las operaciones de escritura se hayan replicado en cualquiera de los secundarios.

Si especificas w: 0, pero incluyes j: true, este j: true prevalece para solicitar el reconocimiento de recibo del mongod autónomo o del primario de un set de réplicas.

w mayor que 1 requiere el reconocimiento del primario y de tantos secundarios con datos como sea necesario para cumplir con el nivel de confirmación de escritura especificado. Los secundarios no necesitan ser miembros con derecho a voto para cumplir con el umbral de nivel de confirmación de escritura.

Por ejemplo, considera un set de réplicas de 3 nodos con un primario y 2 secundarios. Especificar w: 2 requeriría el reconocimiento del nodo primario y de uno de los nodos secundarios. Especificar w: 3 requeriría el reconocimiento del primario y de ambos secundarios.

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.

Consulte el Comportamiento de reconocimiento para cuando las instancias mongod confirman el guardado.

<custom write concern name>

Solicita confirmación de que las operaciones de escritura se hayan propagado a los miembros de tagged que cumplan con el nivel de confirmación de escritura personalizado definido en settings.getLastErrorModes. Para ver un ejemplo, consulte niveles de confirmación de escritura personalizadas en varios centros de datos.

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 mongod confirman el guardado.

Tip

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.

j

Si j: true, solicita el reconocimiento de que las instancias de mongod, como se especifica en el valor w: <value>, han escrito en la bitácora en disco. j: true no ofrece por sí solo garantías de que el guardado no se revierta debido a la conmutación por error del primario del set de réplicas.

Con j: true, MongoDB solo devuelve la respuesta una vez que la cantidad solicitada de miembros, incluido el primario, ha escrito en la bitácora. Anteriormente, el nivel de confirmación de escritura j: true en un set de réplicas solo requería que el primario escribiera en la bitácora, independientemente del nivel de confirmación de escritura w: <value>.

Nota

  • Se produce un error al especificar un nivel de confirmación de escritura que incluya j: true en una instancia mongod que se esté ejecutando sin registrar en la bitácora.

  • Si el registro en la bitácora está habilitado, w: "majority" puede implicar j: true. La configuración del set de réplicas writeConcernMajorityJournalDefault determina el comportamiento. Consulta Comportamiento del reconocimiento para obtener más detalles.

  • Un nivel de confirmación de escritura que incluye o implica j: true provoca una sincronización inmediata del registro en la bitácora. Consulta el Proceso de registro en la bitácora.

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().

A partir de MongoDB,5.0 la preocupación de escritura predeterminada implícita es. Sin embargo, existe un caso extremo para las implementaciones w: majority 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

{ w: 1 }

4

1

5

3

{ w: "majority" }

  • 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".

La opción w y la opción j determinan cuándo las instancias de mongod confirman las operaciones de escritura.

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

w: 1

En memoria

On-disk journal

En memoria

w: "majority"

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.

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:

j no está especificado

El reconocimiento depende del valor de writeConcernMajorityJournalDefault:

  • Si es true, el reconocimiento requiere una operación de escritura en el diario del disco (j: true).

    writeConcernMajorityJournalDefault por defecto en true

  • Si es false, el reconocimiento requiere una operación de escritura en la memoria (j: false).

j: true

El reconocimiento requiere una operación de escritura en el diario del disco.

j: false

El reconocimiento requiere una operación de escritura en la memoria.

Normalmente, si j: false está configurado, no es necesario escribir la operación en el registro en disco. Sin embargo, si writeConcernMajorityJournalDefault: true está configurado, es necesario registrar la operación en el registro en la bitácora incluso si j: false está configurado.

Si se configuran j: false y writeConcernMajorityJournalDefault: true, las operaciones de guardado se registran en el diario de manera asíncrona.

  • Los guardados que tienen w: majority configurado no se reconocen como completos hasta que el registro se vacía en el disco.

  • w: majority las escrituras esperan a que se complete el snapshot de lectura "majority", independientemente de la configuración de j. Esto se debe a que si se establece writeConcernMajorityJournalDefault: 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: majority a 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 lectura majority.

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:

j no está especificado

El reconocimiento requiere una operación de escritura en la memoria (j: false).

j: true

El reconocimiento requiere una operación de escritura en el diario del disco.

j: false

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

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.

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, y

  • las operaciones de escritura asociadas utilizan el nivel de confirmación de escritura "majority".

Para obtener más detalles, consulte la coherencia causal.

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

  • Los nodos ocultos, demorados y de prioridad 0 con members[n].votes mayor que 0 pueden 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 STARTUP2 no participan en mayorías de escritura.

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.

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:

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.

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

clientSupplied

El nivel de confirmación de escritura se especificó en la aplicación.

customDefault

El nivel de confirmación de escritura se originó a partir de un valor por defecto personalizado. Vea setDefaultRWConcern.

getLastErrorDefaults

El nivel de confirmación de escritura se originó en el campo settings.getLastErrorDefaults del set de réplicas.

implicitDefault

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

Volver

“snapshot”

En esta página