Preocupación de escritura de MongoDB:3 advertencias que debe conocer

'Preocupación de escritura' en MongoDB describe el nivel de reconocimiento de escritura que puede esperar de él. Es una configuración bastante importante para recordar en sus operaciones de escritura y su comportamiento es útil para comprender, especialmente en implementaciones distribuidas de MongoDB (es decir, conjuntos de réplicas y clústeres fragmentados). En esta publicación, discutimos 3 errores al usar MongoDB sobre la escritura.

Preocupación de escritura de MongoDB

La documentación de MongoDB define la preocupación de escritura como "el nivel de reconocimiento solicitado de MongoDB para operaciones de escritura en un mongod independiente o en conjuntos de réplicas o en clústeres fragmentados". “

En pocas palabras, un problema de escritura es una indicación de la "durabilidad" que se pasa junto con las operaciones de escritura a MongoDB. Para aclarar, veamos la sintaxis:

{ w: <value>, j: <boolean>, wtimeout: <number> }
Where*,
 w can be an integer | "majority" | , it represents the number of members that must acknowledge the write. Default value is 1.
 j Requests that a write be acknowledged after it is written to the on-disk journal as opposed to just the system memory. Unspecified by default.
wtimeout specifies timeout for the applying the write concern. Unspecified by default.

* Puede encontrar la sintaxis detallada en la documentación de la especificación de inquietudes de escritura.

* Obtenga más información sobre las diferentes "etiquetas" que puede usar para los valores comunes de preocupación de escritura en nuestro blog Comprensión de la durabilidad y la seguridad de escritura en MongoDB.

Ejemplo:

db.inventory.insert(
    { sku: "abcdxyz", qty : 100, category: "Clothing" },
    { writeConcern: { w: 2, j: true, wtimeout: 5000 } }
)

La preocupación de escritura del inserto anterior se puede leer de la siguiente manera:reconozca esta escritura cuando "al menos 2 miembros del conjunto de réplicas la hayan escrito en sus diarios dentro de los 5000 mseg o devuelvan un error '. Un valor de preocupación de escritura para la opción fue mayoritario, lo que significa que "solicita reconocimiento de que las operaciones de escritura se han propagado a la mayoría de los nodos de votación, incluido el principal". “

La importancia de la preocupación por la escritura es evidente. El aumento de los valores de w aumenta la latencia de las escrituras y también disminuye la probabilidad de que se pierdan. La elección de los valores correctos para el problema de escritura depende de los requisitos de latencia y durabilidad de las escrituras que se están realizando.

Con eso como base de lo que es un problema de escritura, pasemos a las tres advertencias que se deben recordar cuando se usa el problema de escritura.

ADVERTENCIA 1: Configurar la preocupación de escritura en conjuntos de réplicas sin un tiempo de espera puede provocar que las escrituras se bloqueen indefinidamente

La definición mayoritaria (aplicable a MongoDB 3.0 en adelante) anterior establece que se solicita reconocimiento a la mayoría de los "nodos de votación". Tenga en cuenta que “Si no especifica el wtimeout opción y el nivel de preocupación de escritura es inalcanzable, la operación de escritura se bloqueará indefinidamente. “

Esto puede tener consecuencias inesperadas, por ejemplo, considere un conjunto de réplicas 2+1 (es decir, una principal, una secundaria y un árbitro). Si su única réplica de lectura falla, entonces todas las escrituras con una preocupación de escritura w opción de "mayoría" se bloquearán indefinidamente. Lo mismo sucederá si la opción w se establece en 2. Otro ejemplo extremo es el caso de un conjunto de réplicas 3+2 (primario, 2 secundarios y 2 árbitros, configuración no recomendada). Todas las escrituras "mayoritarias" se bloquearán incluso si un solo nodo de datos no está disponible, ya que el número mayoritario, en este caso, es 3.

La forma más sencilla de aliviar este problema es especificar siempre un valor de tiempo de espera para que la consulta se agote si no se puede aplicar la preocupación de escritura. Sin embargo, en el caso de tales errores de tiempo de espera, MongoDB no deshace las escrituras exitosas realizadas en algunos de los miembros antes de que se agote el tiempo de espera.

Actualmente tampoco hay una configuración para garantizar que una escritura llegue a la mayoría de los nodos a los que se puede acceder actualmente, así que tenga cuidado al establecer el valor de la preocupación de escritura w en función de la topología deseada durabilidad y disponibilidad.

ADVERTENCIA 2: Puede perder datos incluso con w:mayoría

Parece intuitivo que una vez que la mayoría de los miembros votantes reconoce una escritura, su durabilidad está garantizada. Sin embargo, ¡ese no es el caso! Recuerde que cuando no se especifica la opción j, se reconoce una escritura justo después de que se haya escrito en la memoria.

Por lo tanto, una escritura de este tipo se puede perder si un corte de energía extraño elimina la mayoría de los nodos a los que se había propagado la escritura (y antes de syncPeriodSecs, es decir, antes de que pudiera descargarse a disco).

Para garantizar la durabilidad de las escrituras, es mejor no desactivar el registro en diario en su base de datos y establecer la opción j en verdadero. De hecho, al iniciar MongoDB 3.6, el --nojournal la bandera ha quedado obsoleta para los miembros del conjunto de réplicas que usan el motor de almacenamiento WiredTiger.

Con un valor w de "mayoría" y la opción j no especificada en un conjunto de réplicas, el comportamiento de durabilidad exacto depende del valor de la configuración del conjunto de réplicas writeConcernMajorityJournalDefault. Cuando se establece en verdadero (y cuando el diario está habilitado), reconoce las escrituras después de que hayan sido escritas en los diarios de la mayoría de los miembros con derecho a voto.

Aparte:incluso con el registro en diario activado, es posible que sus escrituras se pierdan en el motor de almacenamiento MMAPv1 si se produce una interrupción dentro de la duración de commitIntervalMs. El motor de almacenamiento WiredTiger, por otro lado, fuerza una sincronización de los archivos de diario cuando recibe una escritura con la opción j establecida en verdadero. Y, incluso con j establecido en falso, una escritura "mayoritaria" reconocida en una implementación basada en WiredTiger más reciente se puede perder solo cuando la mayoría de los nodos de datos fallan simultáneamente.

ADVERTENCIA 3: w:0 al configurar j:true no mejora el rendimiento de escritura

Esto es bastante fácil de razonar una vez que lo piensas, pero igualmente fácil de olvidar. La configuración de la opción w en 0 generalmente se realiza para escribir en la base de datos en una forma de "disparar y olvidar", cuando tiene bastante confianza en la infraestructura de la base de datos y se preocupa más por la latencia que por la durabilidad de cada escritura. Sin embargo, si establece la opción j en verdadero, su opción w se anulará efectivamente ya que la base de datos se asegurará de que la escritura se escriba en el diario en disco antes de regresar.

Si está utilizando preocupaciones de escritura para garantizar el éxito de sus operaciones de escritura, asegúrese de recordar estas tres advertencias cruciales. Estamos aquí para ayudar, así que no dude en comunicarse con cualquier pregunta a través de Twitter o por correo electrónico.