¿Cómo funcionan los conjuntos de réplicas en MongoDB?

Question

Accepted Answer

Un **conjunto de réplicas** es un grupo de servidores MongoDB que mantienen los mismos datos — proporcionando **alta disponibilidad** (failover automático) y **redundancia**. Un nodo es el **primario** (maneja escrituras), otros son **secundarios** (replican los datos del primario y pueden servir lecturas). Es el mecanismo estándar de MongoDB para confiabilidad.

## La estructura del conjunto de réplicas

```text
PRIMARY (1)   → receives all WRITES; replicates changes to secondaries
SECONDARIES (2+) → copy the primary's data (via the oplog); can serve READS
ARBITER (optional) → votes in elections but holds no data (for odd vote counts)

Write → Primary → replicated to Secondaries (via the operations log "oplog")
```

El primario maneja escrituras y las replica (a través del **oplog**, un registro de operaciones) a los secundarios, que se mantienen sincronizados. Un conjunto típico tiene 3 miembros para resiliencia.

## Failover automático (alta disponibilidad)

```text
If the PRIMARY fails:
  → the secondaries detect it and hold an ELECTION
  → a secondary is automatically elected as the NEW PRIMARY
  → the application (via the driver) reconnects to the new primary
  → minimal downtime, no manual intervention
→ This automatic failover is the key high-availability benefit.
```

El **failover automático** es el valor principal: si el primario falla, el conjunto de réplicas elige automáticamente un nuevo primario — convirtiendo una falla de servidor en una breve interrupción en lugar de una interrupción total. (Un número impar de miembros votantes evita elecciones empatadas).

## Escalado de lecturas y preferencias de lectura

```js
// reads can be directed to secondaries to offload the primary
db.collection.find().readPref("secondaryPreferred");
// read preferences: primary (default), secondary, nearest, etc.
```

Los secundarios pueden servir lecturas (escalando capacidad de lectura), controlado por **preferencias de lectura** — aunque las lecturas secundarias pueden estar ligeramente atrasadas (replicación asincrónica).

## Write concern (durabilidad)

```js
// write concern: how many nodes must acknowledge a write before it's confirmed
db.collection.insertOne(doc, { writeConcern: { w: "majority" } });
// w: 1 (primary only — fast, less safe) vs w: "majority" (safer — survives failover)
```

**Write concern** controla la durabilidad: `w: "majority"` espera que una mayoría de nodos reconozca (más seguro — sobrevive a fallos del primario sin pérdida de datos) versus `w: 1` (más rápido pero una escritura podría perderse en failover).

## Por qué es importante

Los conjuntos de réplicas son fundamentales para ejecutar MongoDB de manera confiable en producción, por lo que entenderlos es un conocimiento importante de nivel senior para despliegues MongoDB en producción.

El valor central es **alta disponibilidad a través de failover automático**: un conjunto de réplicas (un grupo de servidores que mantienen los mismos datos, con un primario que maneja escrituras y secundarios que replican) elige automáticamente un nuevo primario si el actual falla — convirtiendo una falla de servidor en una breve interrupción en lugar de una interrupción total, lo cual es esencial para sistemas que deben mantenerse disponibles (y es requerido para transacciones y muchas características de producción).

Entender la estructura (primario, secundarios, árbitro opcional, el oplog para replicación) y el mecanismo de **elección/failover** es fundamental.

Saber que los secundarios pueden servir **lecturas** (escalando capacidad de lectura mediante **preferencias de lectura**, con la advertencia de posible ligero retraso por replicación asincrónica) es valioso para rendimiento.

Especialmente importante es entender **write concern** — el control de durabilidad donde `w: "majority"` asegura que una escritura es reconocida por una mayoría de nodos (por lo que sobrevive a failover del primario sin pérdida de datos — importante para datos críticos) versus `w: 1` (más rápido pero más riesgoso en failover) — un equilibrio clave entre confiabilidad y rendimiento.

Ya que alta disponibilidad y durabilidad son esenciales para bases de datos en producción, y ya que los conjuntos de réplicas (con failover automático, escalado de lecturas mediante secundarios, y write concern para durabilidad) son el mecanismo fundamental de MongoDB para ellas, entender conjuntos de réplicas — la estructura, failover automático, preferencias de lectura, y especialmente write concern — es un conocimiento importante de nivel senior para desplegar MongoDB de manera confiable en producción, una preocupación frecuentemente crítica y un tema que demuestra comprensión del modelo de alta disponibilidad y durabilidad de MongoDB que se espera para roles senior trabajando con la base de datos.