Para proporcionar durabilidad en caso de falla, MongoDB utiliza un registro de escritura anticipada en el disco. archivos derevista
Registro en la bitácora y motor de almacenamiento WiredTiger
Importante
El registro mencionado en esta sección se refiere al registro de escritura anticipada de WiredTiger (es decir, la bitácora) y no a la entrada de registro de MongoDB.
WiredTiger utiliza puntos de control para proporcionar una visión coherente de los datos en disco y permitir que MongoDB se recupere desde el último punto de control. Sin embargo, si MongoDB se cierra inesperadamente entre los puntos de control, es necesario registrar en la bitácora para recuperar la información que se produjo después del último punto de control.
Nota
No se puede especificar --nojournal opción o storage.journal.enabled: false para los miembros del conjunto de réplicas que utilizan el motor de almacenamiento WiredTiger.
Al registrar en la bitácora, el proceso de recuperación:
Busca en los archivos de datos para encontrar el identificador del último punto de control.
Busca en los archivos de la bitácora el registro que coincida con el identificador del último punto de control.
Aplica las operaciones de los archivos de la bitácora desde el último punto de control.
Proceso de registro en la bitácora
Al registrar en la bitácora, WiredTiger crea un registro para cada operación de escritura iniciada por el cliente. El registro de la bitácora incluye cualquier operación de escritura interna provocada por la escritura inicial. Por ejemplo, una actualización de un documento en una colección puede resultar en modificaciones en los índices; WiredTiger crea un único registro en la bitácora que incluye tanto la operación de actualización como sus modificaciones de índice asociadas.
MongoDB configura WiredTiger para que use el almacenamiento en búfer en memoria para almacenar los registros de la bitácora. Los subprocesos se coordinan para asignar y copiar en su porción del búfer. Todos los registros de la bitácora de hasta 128 KB se almacenan en búfer.
WiredTiger sincroniza los registros de bitácora almacenados en búfer con el disco bajo cualquiera de las siguientes condiciones:
Para los miembros del set de réplicas (miembros primarios y secundarios):
Si una operación de guardar incluye o implica un nivel de confirmación de escritura (write concern) de
j: true.Adicionalmente para los miembros secundarios, después de cada aplicación en lotes de las entradas del oplog.
Nota
El nivel de confirmación de escritura (write concern)
"majority"implicaj: truesi elwriteConcernMajorityJournalDefaultes verdadero.Cada 100 milisegundos (ver
storage.journal.commitIntervalMs).Cuando WiredTiger crea un nuevo archivo de diario. Puesto que MongoDB utiliza un límite de tamaño de archivo de diario de 100 MB, WiredTiger crea un nuevo archivo de diario aproximadamente cada 100 MB de datos.
Importante
Entre las operaciones de escritura, mientras los registros de la bitácora permanecen en los búferes de WiredTiger, las actualizaciones pueden perderse después de un apagado forzoso de mongod.
Tip
El comando serverStatus devuelve información sobre las estadísticas de registro en la bitácora de WiredTiger en el campo wiredTiger.log.
Journal Files
Para los archivos de registro en la bitácora, MongoDB crea un subdirectorio denominado journal en el directorio dbPath. Los archivos de registro en la bitácora de WiredTiger tienen nombres con el siguiente formato WiredTigerLog.<sequence>, donde <sequence> es un número relleno con ceros que empieza por 0000000001.
Registros de la bitácora
Los archivos de bitácora contienen un registro por cada operación de guardar iniciada por el cliente
El registro de la bitácora incluye cualquier operación de escritura interna provocada por la escritura inicial. Por ejemplo, una actualización de un documento en una colección puede resultar en modificaciones en los índices; WiredTiger crea un único registro que incluye tanto la operación de actualización como sus modificaciones de índice asociadas.
Cada registro tiene un identificador único.
El tamaño mínimo del registro de bitácora para WiredTiger es 128 bytes.
Compresión
Por defecto, MongoDB configura WiredTiger para que utilice la compresión ágil para sus datos de registro en la bitácora. Para especificar un algoritmo de compresión diferente o sin compresión, utiliza la configuración storage.wiredTiger.engineConfig.journalCompressor. Para obtener más información, consulta Cambiar el compresor de la bitácora WiredTiger.
Nota
Si un registro de log es menor o igual a 128 bytes, que es el tamaño mínimo de registro de log para WiredTiger, WiredTiger no comprime ese registro.
Límite de tamaño del archivo de bitácora
Los archivos de bitácora de WiredTiger tienen un límite de tamaño máximo de 100 MB aproximadamente. Una vez que el archivo supera ese límite, WiredTiger crea un nuevo archivo de bitácora.
WiredTiger remueve automáticamente los archivos del diario antiguos y conserva únicamente los archivos necesarios para recuperarse del último punto de control. Para determinar cuánto espacio de disco reservar para los archivos de registro en la bitácora, ten en cuenta lo siguiente:
El tamaño máximo por defecto para un punto de control es 2 GB
Quizás se necesite más espacio para que MongoDB escriba nuevos archivos de bitácora mientras se está recuperando de un punto de control
MongoDB comprime los archivos de la bitácora
El tiempo que se tarda en restaurar un punto de control depende de tu caso de uso
Si anulas el tamaño máximo del punto de control o desactivas la compresión, tus cálculos pueden ser significativamente diferentes
Por estas razones, es difícil calcular exactamente cuánto espacio adicional necesitas. Sobreestimar el espacio en disco es siempre un enfoque más seguro.
Importante
Si no reservas suficiente espacio en disco para los archivos de tu bitácora, el servidor MongoDB se bloqueará.
Preasignación
WiredTiger preasigna los archivos de bitácora.
Registro en la bitácora y motor de almacenamiento en memoria
En MongoDB Enterprise, el motor de almacenamiento en memoria forma parte de la disponibilidad general (GA). Como tus datos se guardan en la memoria, no hay un registro de la bitácora independiente. Las operaciones de escritura con un nivel de confirmación de escritura (write concern) dej: truese reconocen de inmediato.
Si algún nodo votante de un set de réplicas utiliza el motor de almacenamiento en memoria, debe establecer writeConcernMajorityJournalDefault en false.
Nota
A partir de la versión 4.2 (y 4.0.13 y 3.6.14 ), si un miembro del set de réplicas utiliza el motor de almacenamiento en memoria (votante o no votante) pero el set de réplicas tiene writeConcernMajorityJournalDefault establecido en true, el miembro del set de réplicas registra una advertencia de inicio.
Con writeConcernMajorityJournalDefault configurado en false, MongoDB no espera a 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 (p. ej., caída y reinicio) de la mayoría de los nodos en un set de réplicas determinado.