Como funcionam os conjuntos de réplicas no MongoDB?

Question

Accepted Answer

Um **conjunto de réplicas** é um grupo de servidores MongoDB que mantêm os mesmos dados — fornecendo **alta disponibilidade** (failover automático) e **redundância**. Um nó é o **primário** (manipula escritas), outros são **secundários** (replicam os dados do primário e podem servir leituras). É o mecanismo padrão do MongoDB para confiabilidade.

## Estrutura do 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")
```

O primário manipula escritas e as replica (via **oplog**, um log de operações) para secundários, que permanecem sincronizados. Um conjunto típico possui 3 membros para resiliência.

## Failover automático (alta disponibilidade)

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

**Failover automático** é o principal valor: se o primário falhar, o conjunto de réplicas elege automaticamente um novo primário — transformando uma falha de servidor em uma breve interrupção em vez de uma interrupção total. (Um número ímpar de membros com voto evita eleições empatadas.)

## Escalonamento de leitura e preferências de leitura

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

Secundários podem servir leituras (escalonando capacidade de leitura), controlado por **preferências de leitura** — embora leituras secundárias possam ser ligeiramente obsoletas (replicação assíncrona).

## Write concern (durabilidade)

```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 durabilidade: `w: "majority"` aguarda que uma maioria de nós reconheça (mais seguro — sobrevive a falha de primário sem perda de dados) versus `w: 1` (mais rápido, mas uma escrita poderia ser perdida no failover).

## Por que isso importa

Conjuntos de réplicas são fundamentais para executar MongoDB confiável em produção, portanto compreendê-los é conhecimento importante de nível sênior para implantações de MongoDB em produção.

O valor principal é **alta disponibilidade através de failover automático**: um conjunto de réplicas (um grupo de servidores mantendo os mesmos dados, com um primário manipulando escritas e secundários replicando) elege automaticamente um novo primário se o atual falhar — transformando uma falha de servidor em uma breve interrupção em vez de uma interrupção total, o que é essencial para sistemas que devem permanecer disponíveis (e é necessário para transações e muitos recursos de produção).

Compreender a estrutura (primário, secundários, árbitro opcional, o oplog para replicação) e o mecanismo de **eleição/failover** é fundamental.

Saber que secundários podem servir **leituras** (escalonando capacidade de leitura via **preferências de leitura**, com a ressalva de possível ligeira obsolescência de replicação assíncrona) é valioso para desempenho.

Especialmente importante é compreender **write concern** — o controle de durabilidade onde `w: "majority"` garante que uma escrita seja reconhecida por uma maioria de nós (para que sobreviva ao failover de primário sem perda de dados — importante para dados críticos) versus `w: 1` (mais rápido, mas mais arriscado no failover) — uma troca fundamental entre confiabilidade/desempenho.

Como alta disponibilidade e durabilidade são essenciais para bancos de dados em produção, e como conjuntos de réplicas (com failover automático, escalonamento de leitura via secundários e write concern para durabilidade) são o mecanismo fundamental do MongoDB para eles, compreender conjuntos de réplicas — a estrutura, failover automático, preferências de leitura e especialmente write concern — é conhecimento importante de nível sênior para implantar MongoDB confiável em produção, uma preocupação frequentemente crítica e um tópico que demonstra compreensão do modelo de alta disponibilidade e durabilidade do MongoDB que é esperado para funções sênior trabalhando com o banco de dados.