Come funzionano i replica set in MongoDB?

Question

Accepted Answer

Un **replica set** è un gruppo di server MongoDB che mantengono gli stessi dati — fornendo **alta disponibilità** (failover automatico) e **ridondanza**. Un nodo è il **primary** (gestisce le scritture), gli altri sono **secondaries** (replicano i dati del primary e possono servire letture). È il meccanismo standard di MongoDB per l'affidabilità.

## La struttura del replica set

```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")
```

Il primary gestisce le scritture e le replica (tramite l'**oplog**, un registro delle operazioni) ai secondaries, che rimangono sincronizzati. Un set tipico ha 3 membri per resilienza.

## Failover automatico (alta disponibilità)

```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.
```

Il **failover automatico** è il valore principale: se il primary fallisce, il replica set elegge automaticamente un nuovo primary — trasformando un guasto del server in una breve interruzione piuttosto che in un'interruzione del servizio. (Un numero dispari di membri votanti evita elezioni in parità.)

## Scaling delle letture e read preferences

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

I secondaries possono servire letture (scalando la capacità di lettura), controllate dalle **read preferences** — sebbene le letture dai secondaries possono essere leggermente non aggiornate (replicazione asincrona).

## Write concern (durabilità)

```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)
```

La **write concern** controlla la durabilità: `w: "majority"` attende il riconoscimento da una maggioranza di nodi (più sicuro — sopravvive al failover del primary senza perdita di dati) rispetto a `w: 1` (più veloce ma una scrittura potrebbe andare persa durante il failover).

## Perché è importante

I replica set sono fondamentali per eseguire MongoDB in modo affidabile in produzione, quindi comprenderli è una conoscenza importante a livello senior per i deployment di MongoDB in produzione.

Il valore principale è l'**alta disponibilità tramite failover automatico**: un replica set (un gruppo di server che mantengono gli stessi dati, con un primary che gestisce le scritture e secondaries che replicano) elegge automaticamente un nuovo primary se quello attuale fallisce — trasformando un guasto del server in una breve interruzione piuttosto che in un'interruzione totale, essenziale per i sistemi che devono rimanere disponibili (ed è richiesto per le transazioni e molte funzionalità di produzione).

Comprendere la struttura (primary, secondaries, arbiter opzionale, l'oplog per la replicazione) e il meccanismo di **elezione/failover** è fondamentale.

Sapere che i secondaries possono servire **letture** (scalando la capacità di lettura tramite **read preferences**, con la consapevolezza della potenziale leggera non aggiornamento dovuta alla replicazione asincrona) è prezioso per le prestazioni.

Particolarmente importante è comprendere la **write concern** — il controllo della durabilità dove `w: "majority"` assicura che una scrittura sia riconosciuta da una maggioranza di nodi (quindi sopravvive al failover del primary senza perdita di dati — importante per i dati critici) rispetto a `w: 1` (più veloce ma più rischioso durante il failover) — un compromesso affidabilità/prestazioni fondamentale.

Poiché l'alta disponibilità e la durabilità sono essenziali per i database in produzione, e poiché i replica set (con failover automatico, scaling delle letture tramite secondaries, e write concern per la durabilità) sono il meccanismo fondamentale di MongoDB per realizzarli, comprendere i replica set — la struttura, il failover automatico, le read preferences, e soprattutto la write concern — è una conoscenza importante a livello senior per il deployment affidabile di MongoDB in produzione, una preoccupazione frequentemente critica e un argomento che dimostra la comprensione del modello di alta disponibilità e durabilità di MongoDB che ci si aspetta per i ruoli senior che lavorano con il database.