MongoDB
Explica cómo el journal, los checkpoints y write concern contribuyen a la durabilidad de MongoDB ante fallos de proceso, sistema o nodo.
El journal registra información necesaria para recuperar el storage engine después de un crash ocurrido entre checkpoints. La durabilidad que percibe la aplicación depende además de write concern, replication, hardware y de si la respuesta llegó al cliente.
write
→ journal
→ acknowledgement según write concern
→ checkpoint posteriorJournaling protege contra fallos del proceso o host; no protege contra un delete válido, corrupción lógica, ransomware ni credenciales comprometidas.
Un checkpoint crea un estado consistente en data files. Las operaciones posteriores todavía no incluidas se recuperan reproduciendo journal aplicable.
checkpoint T0
+ journal T0…T1
→ estado recuperado T1Sin journal, un crash podría perder cambios posteriores al checkpoint según configuración y garantías.
Write concern puede solicitar confirmación asociada al journal:
await orders.insertOne(order, {
writeConcern: {
w: 'majority',
j: true,
wtimeoutMS: 5000
}
});La interacción entre majority y journaling depende de versión, defaults y topología. No añadas opciones por superstición: documenta la garantía necesaria y confirma comportamiento actual.
Protege recuperación local del miembro.
Mantiene copias en otros miembros.
Espera confirmación de mayoría y reduce riesgo de perder un write confirmado durante failover.
Conserva puntos históricos fuera del cluster.
Ninguna capa sustituye a las demás.
write llega al primary
→ journal/replicas avanzan
→ respuesta se pierde o vence timeout
→ cliente no sabe si ocurrióAntes de repetir un efecto no idempotente, consulta por operation ID o usa una idempotency key. El journal no elimina la ambigüedad de red.
El storage engine puede agrupar operaciones para amortizar fsync. Esto mejora throughput, pero la latencia depende de disco, frecuencia y carga. No interpretes cada write como una escritura física aislada exactamente en ese instante.
La garantía efectiva depende de que el almacenamiento respete flushes. Riesgos:
Un benchmark de throughput secuencial no mide la latencia de persistencia requerida por el journal.
Writes intensivos pueden aumentar:
También influyen cantidad de índices, tamaño de documentos y write concern. Desactivar journaling para ocultar un storage lento cambia la garantía, no resuelve la causa.
El commit representa la unidad de durabilidad. Operaciones dentro de la transacción no se confirman externamente una por una. Un commit ambiguo debe tratarse mediante el protocolo de retry del driver.
No ejecutes efectos externos dentro del callback porque puede repetirse.
Un shutdown limpio permite completar tareas y cerrar el storage ordenadamente. En containers:
kill -9 como rutina;Un crash controlado en staging valida recuperación, pero nunca sustituye backup tests.
Confundirlos produce diseños inseguros. El oplog es limitado y el journal no es una API de eventos.
Observa:
Correlaciona con deploys, migraciones e index builds.
acknowledged significa majority;j por latencia sin análisis;El journal permite recuperar cambios posteriores al checkpoint ante un crash local. La durabilidad completa combina journal, write concern, replication y backup. Timeouts siguen siendo ambiguos, y una operación técnicamente persistida puede ser lógicamente incorrecta; por eso necesitas idempotencia, monitoreo y recuperación histórica.
j: true?Rendimiento y optimización.