Hvordan fungerer replica sets i MongoDB?

Question

Accepted Answer

Et **replica set** er en gruppe MongoDB-servere, der vedligeholder de samme data — og tilbyder **høj tilgængelighed** (automatisk failover) og **redundans**. En node er **primary** (håndterer skrivninger), andre er **secondaries** (replikerer primary's data og kan betjene læsninger). Det er MongoDB's standardmekanisme for pålidelighed.

## Replica set-strukturen

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

Primary håndterer skrivninger og replikerer dem (via **oplog**, en log over operationer) til secondaries, som forbliver synkroniserede. Et typisk set har 3 medlemmer for modstandsdygtighed.

## Automatisk failover (høj tilgængelighed)

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

**Automatisk failover** er hovedværdien: hvis primary fejler, vælger replica set automatisk en ny primary — og omdanner en serversvigt til en kort afbrydelse i stedet for et komplet serviceafbrud. (Et ulige antal stemmeberettigede medlemmer undgår uafgjorte valg.)

## Læseskalering og læseindstillinger

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

Secondaries kan betjene læsninger (skalering af læsekapacitet), styret af **read preferences** — selvom secondary-læsninger kan være lidt forældet (asynkron replikering).

## Write concern (holdbarhed)

```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** kontrollerer holdbarhed: `w: "majority"` venter på, at et flertal af noder bekræfter (mere sikkert — overlever primary-fejl uden datatab) versus `w: 1` (hurtigere men en skrivning kunne gå tabt ved failover).

## Hvorfor det betyder noget

Replica sets er fundamentale for at køre MongoDB pålideligt i produktion, så forståelse af dem er vigtig senior-niveau-viden for produktions-MongoDB-deployments.

Kernværdien er **høj tilgængelighed gennem automatisk failover**: et replica set (en gruppe servere, der vedligeholder de samme data, med en primary, der håndterer skrivninger, og secondaries, der replikerer) vælger automatisk en ny primary, hvis den nuværende fejler — og omdanner en serversvigt til en kort afbrydelse i stedet for et totalt serviceafbrud, hvilket er essentielt for systemer, der skal forblive tilgængelige (og er påkrævet for transaktioner og mange produktionsfunktioner).

Forståelse af strukturen (primary, secondaries, valgfri arbiter, oplog for replikering) og **valg-/failover-mekanismen** er grundlæggende.

At vide, at secondaries kan betjene **læsninger** (skalering af læsekapacitet via **read preferences**, med forbeholdet om potentiel lille forældethed fra asynkron replikering), er værdifuldt for ydeevne.

Especielt vigtigt er forståelse af **write concern** — holdbarhedskontrollen, hvor `w: "majority"` sikrer, at en skrivning bekræftes af et flertal af noder (så den overlever primary-failover uden datatab — vigtig for kritiske data) versus `w: 1` (hurtigere men mere risikabelt ved failover) — en vigtig pålidelighed/ydeevne-afvejning.

Da høj tilgængelighed og holdbarhed er essentielle for produktionsdatabaser, og da replica sets (med automatisk failover, læseskalering via secondaries, og write concern for holdbarhed) er MongoDB's fundamentale mekanisme for dem, er forståelse af replica sets — strukturen, automatisk failover, læseindstillinger og især write concern — vigtig senior-niveau-viden for pålidelig MongoDB-implementering i produktion, et ofte kritisk område og et emne, der demonstrerer forståelse af MongoDB's høj-tilgængeligheds- og holdbarhedsmodel, som forventes for senior-roller, der arbejder med databasen.