Перейти к содержанию

8. Production: практики и антипаттерны

Сводка для введения кластера в production: ёмкость (RAM, CPU, диск, IOPS), стратегия бэкапов, rolling updates без простоя кворума. В конце — типичные антипаттерны, которые ломают SLA.

Capacity planning (ёмкость)

Ресурс На что смотреть
RAM Рабочий набор + WiredTiger cache (~40–50% от RAM на выделенном узле — ориентир, не догма); рост индексов в memory
CPU Агрегации, маршаллинг BSON, сжатие; всплески при миграции chunks (шарды)
Диск Данные + индексы + oplog + запас под компактацию/миграции; рост с запасом месяцев вперёд
IOPS / latency Пишущий primary чувствителен к «медленному» диску; secondaries — к задержке репликации

Best practice: моделируйте нагрузку на staging с близким объёмом данных и профилем запросов; смотрите метрики cache hit, queue, opcounters.

Оценка объёма (ориентиры из кластера)

// Размер БД и коллекций (mongosh)
db.stats()
db.getCollectionNames().forEach(function (n) {
  const s = db[n].stats()
  // Вывести только крупное (порог подберите сами)
  if (s.size > 1024 * 1024 * 100) {
    print(`${n}: data ${(s.size / 1024 / 1024).toFixed(1)} MB, index ${(s.totalIndexSize / 1024 / 1024).toFixed(1)} MB`)
  }
})

Disk sizing (размер и класс диска)

  • Запас свободного места: алерты до критического порога (например <15–20% — уточняйте под политику и файловую систему).
  • Рост data: TTL/архивация там, где продукт позволяет; шардирование — не замена планирования диска на каждом шарде.
  • Тип носителя: NVMe/SSD для production-нагрузки; для secondaries тот же класс, если они обслуживают чтение SLA.
# mongod.conf — ограничение кэша WT освобождает часть RAM под ОС/процессы (пример)
storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8

Стратегия бэкапов

Элемент Смысл
RPO Сколько данных допустимо потерять (интервал бэкапа + oplog для PITR)
RTO За сколько времени восстановиться
Где хранить Другой регион/аккаунт; шифрование; срок хранения
Проверка Раз в квартал — тест restore на изолированный кластер

Сочетания: снимки томов (быстро на больших данных) + периодический mongodump логических БД; для PITR — политика по oplog / managed backup.

Best practice: «есть скрипт бэкапа» без восстановленного инцидента на staging = непроверенный DR.

Rolling updates (обновление без остановки сервиса)

Типичный порядок для replica set:

  1. Обновить secondary (один узел): заменить бинарник/образ, перезапуск, дождаться SECONDARY и repl lag ≈ 0.
  2. Повторить для остальных secondaries.
  3. rs.stepDown(60) на текущем primary или снять primary последним плановым переключением; обновить бывший primary.
  4. Проверить featureCompatibilityVersion по документации релиза (шаг до/после обновления — строго по гайду версии).
// Перед обновлением мажорной версии часто проверяют FCV (читаемость интерфейса зависит от версии)
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

// Установка FCV после успешного обновления всех членов — только по официальному чеклисту релиза
// db.adminCommand({ setFeatureCompatibilityVersion: "7.0" })

Production: читайте release notes и upgrade path; на шардированном кластере порядок: config servers → шарды → mongos (уточняйте для вашей версии).

Антипаттерны

Антипаттерн Почему больно
Нет индексов под реальные запросы COLLSCAN, рост latency, диск и CPU; конкуренция с репликацией
Плохой shard key Hot shard, перекос, дорогие миграции; broadcast-запросы
Один узел в production Нет отказоустойчивости; обновления и бэкапы без кворума сложнее
«Сами себе бэкап» без теста restore Инцидент = потеря данных или многодневный простой

Иллюстрация «индекс был нужен»:

// До: полное сканирование коллекции
db.events.find({ type: "error", day: "2025-03-15" }).explain("executionStats")

// После создания составного индекса под фильтр
db.events.createIndex({ day: 1, type: 1 })
db.events.find({ type: "error", day: "2025-03-15" }).explain("executionStats")

Сводный production checklist

# Практика
1 Replica set (или шард) с осознанным writeConcern
2 Индексы + explain в CI/перед релизом тяжёлых запросов
3 Мониторинг lag, диск, cache, connections
4 Бэкапы с проверкой восстановления
5 Плановые rolling обновления и отдельный runbook на отказ majority

Дополнительные материалы