Nivel 2 · 25 min

Replicación

La replicación de MongoDB proporciona alta disponibilidad y durabilidad de datos a través de replica sets. Entender el oplog, los write concerns y las read preferences es esencial para construir sistemas con las garantías de consistencia correctas.

Arquitectura del Replica Set

Un replica set es un grupo de instancias MongoDB que mantienen los mismos datos. Deployment típico: 1 primary + 2 secondaries (mínimo para failover automático). El primary acepta todas las escrituras. Los secondaries replican desde el primary via el oplog y pueden servir lecturas. Un árbitro participa en elecciones pero no contiene datos. Disparadores de elección: el primary se vuelve no disponible (sin heartbeat por 10 segundos), el primary hace stepdown. Miembros ocultos (priority 0, hidden: true) reciben replicación pero son invisibles para aplicaciones, usados para analytics y backups.

Oplog y Write Concern

El oplog (operations log) es una colección capped especial (local.oplog.rs) que registra todas las operaciones de escritura en forma idempotente. Los secondaries hacen tail del oplog y reproducen operaciones. Write concern controla el acknowledgment: w:0 (fire and forget), w:1 (solo primary, default), w:majority (la mayoría de los miembros del replica set debe acknowledge), j:true requiere que el primary haga flush a disco antes de acknowledger. Para durabilidad: w:majority + j:true asegura que las escrituras sobrevivan a un fallo del primary. El write concern agrega latencia: elegí según tu trade-off durabilidad vs latencia.

Read Preference y Consistencia

La read preference controla qué miembro del replica set sirve las lecturas. primary: todas las lecturas desde primary (consistencia fuerte, default). primaryPreferred: lecturas desde primary si disponible, secondary si no. secondary: todas las lecturas desde secondaries (posible stale data — replication lag). secondaryPreferred: lecturas desde secondaries, fallback a primary. nearest: miembro de menor latencia de red. La consistencia causal (MongoDB 3.6+) garantiza que dentro de una sesión, las lecturas nunca van hacia atrás en el tiempo.

Puntos clave

w:majority + j:true provee la garantía de durabilidad más fuerte: las escrituras sobreviven a un fallo del primary. w:1 es más rápido pero arriesga pérdida de datos si el primary falla antes de que los secondaries repliquen.
Leer desde secondaries puede devolver stale data. La cantidad de stale depende del replication lag. Usá sesiones causalmente consistentes si las lecturas deben ver sus propias escrituras.
El tamaño del oplog debe cubrir tu ventana de replication lag. Si un secondary cae detrás y el oplog sobreescribe entradas no leídas, el secondary debe re-sincronizarse desde cero (costoso).

Code example

// Write with majority durability\ndb.orders.insertOne(\n  {orderId: '123', amount: 99.99},\n  {writeConcern: {w: 'majority', j: true, wtimeout: 5000}'}'\n)\n\n// Read from nearest secondary (analytics)\ndb.orders.find({status: 'completed}).readPref('nearest')\n\n// Check replication lag\nrs.printReplicationInfo()\nrs.printSecondaryReplicationInfo()