Administrar el registro en diario en MongoDB

MongoDB, como cualquier otra base de datos, puede fallar al ejecutar una operación de escritura. En ese caso, necesitamos una estrategia que mantenga la operación en algún lugar para que la base de datos pueda reanudarse cuando vuelva a funcionar.

En MongoDB, utilizamos el registro en diario mediante el cual hay un registro de escritura anticipada en los archivos de diario en el disco para mantener los datos disponibles en caso de falla. El motor de almacenamiento WiredTiger puede usar puntos de control para proporcionar una vista consistente de los datos en el disco y permitir que MongoDB se recupere desde el último punto de control, pero solo si no se cerró inesperadamente. De lo contrario, para la información que ocurrió durante el último punto de control, se debe haber habilitado el registro en diario para recuperar dichos datos.

El procedimiento para el proceso de recuperación es el siguiente:la base de datos buscará en los archivos de datos para encontrar el identificador del último punto de control, use este identificador para buscar en los archivos de diario el registro que coincida y luego aplique las operaciones en los archivos de diario desde el último punto de control.

Cómo funciona el registro en diario en el motor de almacenamiento WiredTiger

Para cada cliente que inicia una operación de escritura, WiredTiger crea un registro de diario que se compone de operaciones de escritura internas que fueron activadas por la escritura inicial. Considere un documento en una colección que se actualizará y esperamos que su índice también se modifique. WiredTiger creará un único registro diario que incorporará la operación de actualización y las modificaciones de índice correspondientes.

Este registro se almacenará en un búfer en memoria cuya capacidad máxima es de 128kB. Luego, el motor de almacenamiento sincroniza estos registros diarios almacenados en búfer en el disco cuando se cumple cualquiera de los siguientes:

Una operación de escritura incluye/implica una preocupación de escritura de j:verdadero.
WiredTiger crea un nuevo archivo de diario que se encuentra después de cada 100 MB de datos.
Después de cada 100 milisegundos dependiendo de storage.journal.commitIntervalMs.
En caso de miembros del conjunto de réplicas:
- Instancia de operaciones en espera de entradas de oplog, es decir, operaciones de lectura realizadas como parte de sesiones causalmente coherentes y consultas de exploración de reenvío contra el oplog.
- Después de cada aplicación por lotes de las entradas de oplog en el caso de los miembros secundarios.

En caso de un cierre forzoso de mongod, si las operaciones de escritura estaban en proceso, las actualizaciones pueden perderse incluso si los registros del diario permanecen en los búferes de WiredTiger.

Compresión de datos de diarios

La configuración predeterminada en MongoDB indica a WiredTiger que use una compresión ágil para los datos del diario. Esto se puede cambiar según el algoritmo de compresión que desee mediante la configuración storage.wiredTiger.engineConfig.journalCompressor. Estos registros solo se comprimen si su tamaño es superior a 128 bytes, que es el tamaño mínimo de registro de WiredTiger.

Limitación del tamaño de un archivo de diario

El tamaño máximo de un archivo de diario es de 100 MB y, por lo tanto, si el archivo supera este límite, se creará uno nuevo.

Después de que el archivo de diario se haya usado en la recuperación o, más bien, haya archivos más antiguos que el que se puede usar para recuperarse del último punto de control, WiredTiger los elimina automáticamente.

Asignación previa

Los archivos de diario se pueden preasignar con el motor de almacenamiento WiredTiger si el proceso mongod determina que es más eficiente preasignar archivos de diario que crear nuevos.

Cómo funciona el registro en diario en el motor de almacenamiento en memoria

El motor de almacenamiento en memoria se estableció como parte de la disponibilidad general (GA) a partir de la versión 3.2.6 de MongoDB Enterprise. Con este motor de almacenamiento, los datos se guardan en la memoria, por lo tanto, no hay una técnica de registro por separado. Si hay alguna operación de escritura con un problema de escritura (j:verdadero), se reconocerá de inmediato.

Para un conjunto de réplicas con un miembro con derecho a voto mediante el motor de almacenamiento en memoria, se debe configurar writeConcernMajorityJournalDefault en falso. De lo contrario, si se establece en verdadero, el conjunto de réplicas registrará una advertencia de inicio.

Cuando esta opción se establece en false, la base de datos no esperará a que se escriba w:“la mayoría” de escritura en el diario en disco antes de reconocer las escrituras. La desventaja de este enfoque es que, con la mayoría de las operaciones de escritura, es posible que se produzca una reversión en caso de una pérdida transitoria (como un reinicio o un bloqueo) de la mayoría de los nodos en un conjunto de réplicas determinado.

Si usa el motor de almacenamiento MMapv1, la preasignación de diario se puede desactivar usando la opción --nopreallocation al iniciar mongod.

Con el motor de almacenamiento WiredTiger, a partir de la versión 4.0 de MongoDB, no es posible especificar la opción --nojournal o incluso la opción storage.journal.enabled:false para los miembros del conjunto de réplicas que usan el motor de almacenamiento WiredTiger.

Gestionar el diario

Deshabilitar el registro en diario

El registro en diario solo se puede deshabilitar para implementaciones independientes y no se recomienda para sistemas de producción. Para MongoDB versión 4.0 y posteriores, no se puede especificar ni la opción --nojournal ni storage.journal.enabled:false cuando se trata de miembros del conjunto de réplicas que utilizan el motor de almacenamiento WiredTiger.

Para deshabilitar el registro en diario, inicie mongod con la opción de línea de comando --nojournal.

Supervisar el estado del diario

Para obtener las estadísticas del diario, use el comando db.serverStatus() que devuelve wiredTiger.log.

Obtener Confirmación de confirmación

Usamos la opción de preocupación de escritura con j para obtener el reconocimiento de compromiso. {j:verdadero}. El registro en diario debe estar habilitado en este caso, de lo contrario, la instancia de mongod puede producir un error.

Si el diario está habilitado, w:“mayoría”, esto puede implicar j:verdadero.

Para un conjunto de réplicas, cuando j:verdadero, la configuración requiere que solo el principal escriba en el diario, independientemente de la w: preocupación de escritura.

Sin embargo, incluso si j:true está configurado para un conjunto de réplicas, pueden ocurrir reversiones debido a la conmutación por error principal del conjunto de réplicas.

Recuperación de datos de apagado inesperado

Todos los archivos de diario en el directorio de diario se reproducen cada vez que MongoDB se reinicia desde un bloqueo antes de que se detecte el servidor. Dado que esta operación se registrará en la salida del registro, no será necesario ejecutar --repair.

Cambiar el compresor de WiredTiger Journal

El compresor Snappy es el algoritmo de compresión predeterminado para la revista. Sin embargo, uno puede cambiar esto dependiendo de la configuración de la instancia de mongod.

Para una instancia mongod independiente:

Establezca storage.wiredTiger.engineConfig.journalCompressor en un nuevo valor para actualizarlo. La forma más adecuada de hacerlo es a través del archivo de configuración, pero si usa las opciones de línea de comandos, debe actualizar la opción de línea de comandos --wiredTigerJournalCompressor durante el reinicio.
Apague la instancia de mongod conectándose a un shell de mongo de la instancia y emita el comando:db.shutdownServer() o db.getSiblingDB('admin ).apagarServidor()
Reinicie la instancia de mongod:
1. Si usa el archivo de configuración, use:mongod -f
2. Si usa opciones de línea de comandos, actualice wiredTigerJournalCompressor:
```
Mongod --wiredTigerJournalCompressor <differentCompressor|none>
```

Para un miembro del conjunto de réplicas:

Apague la instancia de mongod:db.shutdownServer() o db.getSiblingDB(‘admin).shutdownServer()
Realice los siguientes cambios en el archivo de configuración:
1. Establezca storage.journal.enabled en falso.
2. Comenta la configuración de replicación
3. Establezca el parámetro disabledLogicalSessionCacheRefresh en verdadero.

i.e

storage:

   journal:

      enabled: false

#replication:

#   replSetName: replA

setParameter:

   disableLogicalSessionCacheRefresh: true

Reiniciar la instancia de mongod:
1. Si usa el archivo de configuración, use:mongod -f
2. Si usa las opciones de línea de comandos:incluya la opción --nojournal, elimine cualquier opción de línea de comandos de replicación es decir --replSet y establece el parámetro disabledLogicalSessionCacheRefresh en verdadero
```
mongod --nojournal --setParameter disableLogicalSessionCacheRefresh=true
```

Apague la instancia de mongod:

db.shutdownServer() or db.getSiblingDB(‘admin).shutdownServer()

Actualice el archivo de configuración para prepararse para un reinicio del miembro del conjunto de réplicas con el nuevo compresor de diario:elimine el almacenamiento. journal.enabled, elimine los comentarios de la configuración de replicación para la implementación, elimine la opción disabledLogicalSessionCacheRefresh y, por último, elimine storage.wiredTiger.engineConfig.journalCompressor.

storage:

   wiredTiger:

      engineConfig:

         journalCompressor: <newValue>

replication:

   replSetName: replA

Reiniciar la instancia de mongod como miembro del conjunto de réplicas

Si usa el archivo de configuración, use:mongod -f
Si usa las opciones de la línea de comandos:elimine las opciones --nojournal y --wiredTigerJournalCompressor. Incluya las opciones de la línea de comandos de replicación y elimine el parámetro disabledLogicalSessionCacheRefresh.

mongod --wiredTigerJournalCompressor <differentCompressor|none> --replSet ...

Conclusión

Para que MongoDB garantice la durabilidad de una operación de escritura, se utiliza el registro en diario mediante el cual los datos se escriben en el disco con anticipación Inicio sesión. Por mucho que el motor de almacenamiento WiredTiger (que es el más preferido) pueda recuperar datos a través de los últimos puntos de control, si MongoDB se cierra inesperadamente y no se ha habilitado el registro en diario, la recuperación de dichos datos se vuelve imposible. De lo contrario, si el diario está habilitado, MongoDB puede volver a aplicar las operaciones de escritura al reiniciar y mantener un estado coherente.