Репликация и шардирование MongoDB

Replica set даёт отказоустойчивость и масштабирование чтения. Sharded cluster распределяет данные по машинам, когда один узел не тянет объём или запись. Базовые операции с данными — CRUD и схемы; производительность запросов и пайплайны — индексы и агрегации.

1. Replica set

Группа узлов с одними и теми же данными: один primary принимает записи, secondaries тянут oplog.

При падении primary — выборы нового primary.

Прод: обычно 3 data-bearing члена (2 + arbiter только если осознаёте риск меньшего числа полных копий).

2. Write concern и read concern

db.orders.insertOne(
  { sku: "A1", qty: 1 },
  { writeConcern: { w: "majority", j: true, wtimeout: 5000 } }
)

• w: "majority" — типичный выбор для важных данных.
• j: true — ожидание durable записи журнала (детали зависят от storage engine и диска).

Read preference:

Чтение с secondaries разгружает primary, но клиент может не увидеть только что записанное без учёта lag и read concern.

3. Oplog

Oplog — capped-коллекция на primary; secondaries применяют операции. Размер oplog влияет на окно, в которое secondary может отвалиться и ещё догнаться без полного resync.

Мониторьте lag и алерты на рост отставания.

4. Sharded cluster

Приложение → mongos → shard (обычно replica set) × N
                ↓
         config servers (метаданные чанков)

Данные режутся по shard key (поле или составной ключ в shard key index).

5. Выбор shard key

Плохой ключ → jumbo chunks или hot shard.

Хорошо: высокая кардинальность, равномерное распределение (часто hashed shard key).

Плохо: монотонный ключ без хеша, если все вставки бьют в один «хвост»; очень низкая кардинальность (мало чанков, мало параллелизма).

Перешардировать «легко» нельзя: часто новая коллекция с правильным ключом и миграция.

6. Балансировка

Balancer переносит chunks между шардами при перекосе. При массовой загрузке иногда временно отключают balancer по процедуре — только с пониманием рисков.

7. Zones

Zone sharding — привязка диапазонов shard key к регионам или классам железа (например, данные EU на европейские шарды).

8. Change streams (кратко)

Change streams — подписка на поток изменений в коллекции (аналог tail oplog с фильтром). Требуется replica set; в шардированном кластере watch идёт через mongos, события приходят с метаданными шарда. Для чтения «сразу после своей записи» с secondary комбинируйте readConcern: { level: 'majority' } у записи и чтения; иначе учитывайте replication lag. Не используйте change streams как единственный журнал аудита без TTL/архивации и бэкапа oplog-окна.

9. Когда шардировать

Шардирование увеличивает операционную сложность: больше узлов, backup каждого шарда, сложнее отладка без shard key в фильтре.

10. Резервное копирование

• mongodump / mongorestore — для небольших объёмов и отдельных коллекций.
• Для крупных replica set и шардов — решения уровня Atlas, Ops Manager или согласованные снимки с учётом консистентности между шардами.

11. Чек-лист эксплуатации

• Replica set с кворумом и мониторингом lag
• Для критичных записей writeConcern: majority
• Чтение со secondaries осознанно
• Shard key выбран до роста данных; запросы таргетят шард где возможно
• План восстановления и тест backup
• Change streams: окно oplog и мониторинг отставления

См. также

• Индексы и агрегации в MongoDB
• Потоковая репликация PostgreSQL — сравнение идей HA в реляционной СУБД