MongoDB
Explica cómo write concern define el reconocimiento de escrituras mediante w, majority, journaling y timeouts, y qué garantías ofrece cada combinación.
Write concern define qué confirmación espera el cliente después de una escritura. Controla cuántos miembros deben reconocerla, si debe confirmarse el journal y cuánto tiempo se espera antes de devolver un timeout.
await collection.updateOne(
filter,
update,
{
writeConcern: {
w: 'majority',
j: true,
wtimeoutMS: 5000
}
}
);Atomicidad describe si una operación se aplica completa dentro de su unidad; write concern describe cuándo el cliente considera suficientemente confirmada la escritura.
El primary confirma que aceptó la operación. Tiene menor coordinación que majority, pero una escritura todavía no confirmada por mayoría puede tener menor tolerancia a ciertos failovers.
Espera confirmación de la mayoría calculada por el replica set. Mejora durabilidad frente a failover, pero no significa que todos los nodos hayan aplicado el cambio.
Puede exigirse un número concreto de miembros. Debe ser coherente con la topología; una exigencia imposible genera espera y timeout.
En configuraciones avanzadas pueden definirse write concerns por tags para exigir confirmación en regiones o tipos de nodo específicos. Esto requiere diseño operacional cuidadoso.
j: true exige la confirmación asociada al journal según las garantías y configuración de la versión. El journal ayuda a recuperar cambios después de un crash del proceso o host entre checkpoints.
Journaling no reemplaza replication ni backup. Un delete válido también se escribe en el journal.
wtimeoutMS limita cuánto espera el cliente por la confirmación requerida.
operación aplicada en primary
→ réplicas tardan
→ vence wtimeout
→ cliente recibe errorEl timeout no prueba que la escritura no ocurrió. Antes de repetir un efecto no idempotente, consulta estado o usa una clave de operación.
Una conexión puede romperse después del commit pero antes de la respuesta. Para manejarlo:
Con w: 1, el primary puede responder antes de que una mayoría confirme. Si falla en la ventana crítica, la aplicación debe comprender las garantías reales de su topología y versión.
Con majority, la latencia depende de miembros saludables, red, disco y replication lag. Un secondary lento o indisponible puede afectar capacidad para alcanzar la mayoría según configuración.
Las operaciones dentro de una transacción no se consideran durables individualmente fuera del commit. El write concern relevante se aplica al commit según API y restricciones.
await session.withTransaction(async () => {
await accounts.updateOne(fromFilter, debit, { session });
await accounts.updateOne(toFilter, credit, { session });
}, {
writeConcern: { w: 'majority' }
});El commit puede devolver UnknownTransactionCommitResult; el driver debe reintentar el commit de forma compatible, no volver a ejecutar efectos externos.
Un bulk utiliza write concern para su confirmación. Si ocurre timeout, puede haber operaciones aplicadas parcialmente desde la perspectiva del lote. Ordered y unordered no convierten el bulk en all-or-nothing.
Garantías más fuertes pueden aumentar latencia porque esperan replication y persistencia. Sin embargo, reducir write concern para ocultar disco lento o lag es una mala solución. Primero investiga:
Suelen justificar majority y diseños idempotentes.
Pueden aceptar una política distinta si la pérdida está documentada.
La fuente de verdad puede permitir garantías menores.
La decisión pertenece al requisito de pérdida aceptable, no a una preferencia global sin análisis.
acknowledged: true no implica backup.$inc después de un error ambiguo;Write concern es una política de confirmación y durabilidad distribuida. majority reduce el riesgo de perder writes confirmados durante failover, pero no equivale a todos los nodos ni a backup. Los timeouts son ambiguos y requieren idempotencia, reconciliación y observabilidad.
w?j?Read preference.