Как работают наборы реплик в MongoDB?

Question

Accepted Answer

**Набор реплик** — это группа серверов MongoDB, которые хранят одинаковые данные, обеспечивая **высокую доступность** (автоматическую отработку отказа) и **избыточность**. Один узел является **первичным** (обрабатывает операции записи), остальные — **вторичными** (реплицируют данные первичного узла и могут обслуживать операции чтения). Это стандартный механизм MongoDB для обеспечения надёжности.

## Структура набора реплик

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

Первичный узел обрабатывает записи и реплицирует их (через **oplog**, журнал операций) на вторичные узлы, которые остаются синхронизированными. Типичный набор состоит из 3 членов для устойчивости.

## Автоматическая отработка отказа (высокая доступность)

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

**Автоматическая отработка отказа** — основная ценность: если первичный узел отказывает, набор реплик автоматически выбирает новый первичный узел — превращая отказ сервера в кратковременное прерывание вместо полного отключения. (Нечётное количество узлов с правом голоса избегает равенства при выборах.)

## Масштабирование чтений и предпочтения чтения

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

Вторичные узлы могут обслуживать операции чтения (масштабируя пропускную способность чтения), управляемые **предпочтениями чтения** — однако чтение со вторичных узлов может быть слегка отстающим (асинхронная репликация).

## Уровень записи (долговечность)

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

**Уровень записи** управляет долговечностью: `w: "majority"` ожидает подтверждения от большинства узлов (безопаснее — сохраняет данные при отказе первичного узла без потерь) в сравнении с `w: 1` (быстрее, но запись может быть потеряна при отработке отказа).

## Почему это важно

Наборы реплик — это основа для надёжного запуска MongoDB в production, поэтому понимание их принципа работы важно для знаний уровня senior при развёртывании production MongoDB.

Основная ценность — **высокая доступность через автоматическую отработку отказа**: набор реплик (группа серверов, хранящих одинаковые данные, где первичный узел обрабатывает записи, а вторичные узлы реплицируют) автоматически выбирает новый первичный узел при отказе текущего — превращая отказ сервера в кратковременное прерывание вместо полного отключения, что критично для систем, которые должны оставаться доступными (и требуется для транзакций и многих production функций).

Понимание структуры (первичный узел, вторичные узлы, необязательный арбитр, oplog для репликации) и механизма **выборов/отработки отказа** — это основополагающее знание.

Знание того, что вторичные узлы могут обслуживать **чтения** (масштабирование пропускной способности чтения через **предпочтения чтения**, с учётом возможного небольшого отставания из-за асинхронной репликации) — ценно для производительности.

Особенно важно понимание **уровня записи** — управление долговечностью, где `w: "majority"` гарантирует, что запись подтверждена большинством узлов (поэтому данные сохраняются при отказе первичного узла без потерь — важно для критических данных) в сравнении с `w: 1` (быстрее, но рискованнее при отработке отказа) — ключевой компромисс между надёжностью и производительностью.

Поскольку высокая доступность и долговечность критичны для production баз данных, а наборы реплик (с автоматической отработкой отказа, масштабированием чтений со вторичных узлов и уровнем записи для долговечности) являются фундаментальным механизмом MongoDB для их обеспечения, понимание наборов реплик — структуры, автоматической отработки отказа, предпочтений чтения и особенно уровня записи — это важное знание уровня senior для надёжного развёртывания MongoDB в production, часто критический вопрос и тема, демонстрирующая понимание модели высокой доступности и долговечности MongoDB, которая ожидается от senior специалистов, работающих с базой данных.