MongoDB replica sets: write concern, read preference, failover

⚙️ Теория

🧩 Replica Set модель

MongoDB replica set состоит из:

primary для записей;
secondary для репликации;
election механизма при смене primary.

⚖️ Write Concern и Read Preference

writeConcern определяет подтверждение записи (например majority).

readPreference определяет, откуда читать (primary, secondary, и т.д.).

Trade-off:

выше консистентность -> часто выше latency;
ниже latency на чтении -> возможны stale reads.

🔄 Failover поведение

При потере primary replica set проводит election. Во время переключения возможны кратковременные ошибки записи/чтения в зависимости от настроек клиента.

⚠️ Анти-паттерны

использовать слабый write concern для критичных транзакций;
читать с secondary там, где нужна свежесть данных;
не тестировать driver retry/timeout policy при election.

❓ Что нужно уметь объяснить

Почему `majority` write concern часто нужен для критичных данных?

Он уменьшает риск потери подтвержденных записей при аварийных сценариях и election.

Почему secondary reads могут удивлять бизнес?

Потому что данные могут отставать от primary (replication lag).

Что критично в client settings?

Корректные таймауты, retry semantics и read/write policy под конкретный SLA.

🧪 Практика

1. Проверка статуса replica set

rs.status()
rs.printReplicationInfo()

2. Настройка write concern/read preference (пример)

// readPreference можно задать в connection string / driver config:
// mongodb://db1,db2,db3/?replicaSet=rs0&readPreference=primary&w=majority

db.orders.insertOne(
  { orderId: 42, status: 'open' },
  { writeConcern: { w: 'majority', wtimeout: 5000 } }
)

3. Guardrails

мониторить replication lag и election frequency;
явно задавать read/write policy на уровне сервиса;
проводить failover drills в staging.

🧾 Вывод

Надежность MongoDB зависит от осознанного выбора write concern/read preference и проверенной реакции приложений на election/failover.

📚 Ссылки

✅ Проверка источников

MongoDB Documentation