MongoDB на VDS: WiredTiger cache, journaling и quorum в replica set

MongoDB на VDS обычно упирается не в «магические» параметры, а в три приземлённые вещи: память (WiredTiger cache), диск (журналирование и чекпоинты) и отказоустойчивость (quorum и elections в replica set). Если эти три слоя настроены разумно, то production перестаёт быть лотереей: производительность стабильнее, сбои предсказуемее, а восстановление — проверяемым процессом.

Как MongoDB реально расходует память: WiredTiger cache

WiredTiger — дефолтный движок MongoDB. Его кэш — главный потребитель RAM в процессе mongod, и именно он определяет, сколько данных и индексов вы держите «под рукой» без походов на диск. При этом MongoDB использует память не только под WiredTiger cache, и на VDS важно оставить запас ОС.

Что ещё живёт в RAM кроме кэша

• Файловый кэш ОС (page cache): даже с WiredTiger активно читаемые блоки будут жить в кэше ядра; это сглаживает I/O и задержки.
• Соединения и рабочие буферы: всплески при агрегациях, сортировках и больших батчах могут заметно увеличить RSS.
• Служебные структуры и метаданные: часть в WiredTiger cache, часть — в памяти процесса и ядра.
• Фоновые активности: чекпоинты, компрессия, репликация и журналирование сами по себе RAM не «съедают», но при дефиците памяти усиливают конкуренцию за I/O.

cacheSizeGB: почему «поставить побольше» — не всегда правильно

Рекомендация «отдать MongoDB половину RAM» часто работает, но на VDS (где важны предсказуемость, соседи и лимиты) лучше мыслить от рисков. Слишком большой WiredTiger cache означает:

• меньше памяти остаётся ОС под page cache и системные демоны;
• выше шанс «ступенек» по latency во время чекпоинтов и сбросов грязных страниц при перегруженном диске;
• больше риск OOM при пиковых агрегациях/сортировках и большом числе соединений.

Слишком маленький кэш — обратная проблема: больше чтений с диска, выше нагрузка на storage, хуже p99 по чтению и запись начинает упираться в I/O.

Практичный алгоритм выбора размера кэша

Как стартовая точка для VDS удобно идти от простого: сначала гарантируйте запас под ОС и пики приложения, и только потом «докручивайте» кэш по метрикам.

• Если сервер только под MongoDB: начните с 50% RAM, но оставьте минимум 2–4 ГБ под ОС; на небольших VDS чаще разумен диапазон 4–24 ГБ кэша.
• Если на узле есть приложение/агенты/бэкапы: начните с 30–40% RAM под кэш.
• Если storage с заметной латентностью: не выжимайте RAM «в ноль» — page cache часто даёт более ровную задержку, чем огромный WiredTiger cache на слабом диске.

Задать размер можно параметром storage.wiredTiger.engineConfig.cacheSizeGB. Пример фрагмента mongod.conf:

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8

Дальше — только измерения: смотрите, не начинается ли агрессивный eviction, как ведёт себя «грязный» кэш, и нет ли постоянного давления по памяти (swap, OOM, падение page cache). Если eviction частый и p99 растёт на чтениях — кэш мал. Если RSS подпирает лимит и ОС постоянно «выдавливает» память — кэш великоват.

Цель в production: MongoDB должна держать в RAM рабочие индексы и горячие данные, а ОС — сохранять способность кешировать и обслуживать I/O без постоянного memory pressure.

Journaling: цена надёжности и как не убить диск

Journaling — журнал предзаписи, который защищает от потери подтверждённых записей при падении процесса или узла. В WiredTiger журналирование включено по умолчанию, и в production отключать его обычно не стоит, если вы не готовы принять потерю части «подтверждённых» данных при аварии.

Что именно даёт journaling

• Сохранность подтверждённых записей при креше между чекпоинтами.
• Быстрый crash recovery: MongoDB доигрывает журнал до согласованного состояния.
• Более предсказуемое поведение write concern в репликации (если он настроен по смыслу).

Почему journaling проявляется как высокие задержки

Журналирование — это дополнительные операции записи и периодические flush/fsync на диске. На VDS с «не самым бодрым» storage оно часто проявляется как:

• рост latency на записи (особенно при burst-нагрузке);
• очереди на диске и spikes по iowait;
• замедление на фоне конкуренции с чекпоинтами и бэкапами.

Практика для VDS: сначала I/O, потом тонкая настройка

Для типичного production (с чтением и записью) главная оптимизация journaling — не «выключить», а обеспечить нормальный диск и не мешать ОС работать с кэшем:

• предсказуемый SSD/NVMe и адекватные лимиты IOPS;
• по возможности разнос данных и логов по разным томам;
• разумный cacheSizeGB, чтобы не вытеснить page cache;
• write concern выбирайте по бизнес-рискам, а не по случайному примеру.

Если вы только планируете размещение, выбирайте VDS для MongoDB с понятными характеристиками по диску и гарантированной памятью: в MongoDB именно RAM и storage определяют «нервность» p95/p99.

Для приложений с активной записью полезно заранее продумать кэширование на уровне сервиса (чтобы разгружать чтения) и сделать его контролируемым. Если у вас типичный LAMP/LEMP-стек, посмотрите материал про кэширование в PHP через Redis/Memcached — иногда это дешевле и надёжнее, чем бесконечно наращивать MongoDB.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Replica set quorum и elections: почему «2 ноды» — это ловушка

Replica set — базовый механизм высокой доступности MongoDB. Но доступность определяется не количеством нод само по себе, а тем, есть ли кворум голосов для принятия решений. Самая частая ошибка — поставить 2 узла и ожидать автоматического failover.

Что такое quorum в replica set

Для выборов primary нужен кворум голосов, обычно это majority от voting members. Если большинство недоступно, выборы не завершатся и primary не будет. Итог: кластер может остаться без возможности записывать, даже если один узел «жив».

Почему 2 узла без третьего голоса не дают нормальный failover

• При падении одной ноды оставшаяся не имеет большинства (1 из 2) и не может стать primary.
• При сетевом разделении split brain сдерживается, но ценой отсутствия primary при потере quorum.

Рабочие варианты для малого продакшена

• 3 узла: классика. Три узла с данными или 2 с данными + 1 с данными в другой зоне.
• 2 узла + arbiter: арбитр хранит только голос, не данные. Это компромисс для экономии ресурсов, но он не повышает read capacity и не является источником данных.

Если нужен автоматический failover, «два узла» почти всегда неверная точка старта. Нужен третий голос — данные или хотя бы arbiter.

Как elections влияют на приложение

Elections происходят при падении primary, деградации сети, проблемах диска или при плановом stepdown. Для приложения это обычно означает кратковременные ошибки записи и переподключение драйвера, а также рост latency на время переизбрания.

• Проверьте, что драйвер поддерживает retryable operations там, где это безопасно для вашей логики.
• Следите за длительностью election и частотой stepdown: частые выборы почти всегда симптом (сеть, диск, перегрузка, «шумный» сосед по I/O).
• Разносите узлы по разным хостам и зонам доступности, если цель — переживать отказ площадки.

Минимальный набор mongod.conf для production на VDS

Тюнинг MongoDB — не про сотни флагов. Важно выставить базовые вещи, которые влияют на безопасность, предсказуемость и эксплуатацию.

Базовый каркас конфигурации

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8

systemLog:
  destination: file
  path: /var/log/mongodb/mongod.log
  logAppend: true

net:
  port: 27017
  bindIp: 127.0.0.1

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

Что здесь важно в первую очередь

• net.bindIp: по умолчанию держите доступ локальным и публикуйте наружу только через приватную сеть или защищённый доступ. Так вы уменьшаете поверхность атаки.
• systemLog.logAppend: облегчает ротацию и расследование инцидентов.
• storage.journal.enabled: для production обычно должен быть true.

Что обычно не стоит тюнить без измерений

• агрессивные настройки компрессии «ради экономии диска», если вы упираетесь в CPU;
• нестандартные параметры чекпоинтов в надежде «убрать лаги» (часто вы просто переносите их в другое место);
• эксперименты с THP/huge pages без понимания профиля нагрузки (обычно важнее стабильный диск и адекватный cacheSizeGB).

Backup/restore: что считать рабочим бэкапом

Ключевой вопрос эксплуатации — не «как сделать бэкап», а «как восстановиться»: сможете ли вы подняться в понятное время и с понятной точкой консистентности. Поэтому restore-тест — часть процесса, а не опция «на потом».

Логические дампы

Логический бэкап (dump/restore) удобен тем, что независим от файловой системы и легко переносится. Но он:

• может быть медленным на больших объёмах;
• нагружает CPU и диск во время снятия;
• часто даёт RTO больше, чем хочется.

Файловые снапшоты

Снапшоты томов дают быстрое восстановление, но критична консистентность. В replica set типовая практика — снимать снапшот со secondary, чтобы не давить primary. После этого обязательно проверять восстановление на отдельном стенде.

Минимальный регламент проверки восстановления

1. Поднимите отдельный экземпляр MongoDB из последнего бэкапа.
2. Проверьте критичные коллекции, индексы и базовые контрольные запросы.
3. Зафиксируйте фактическое время восстановления и сравните с целевыми RPO/RTO.

Если вы публикуете MongoDB-сервисы наружу (например, админ-панели, API или закрытые интерфейсы), защитите их корректным TLS. Для этого удобнее использовать нормальные SSL-сертификаты и централизованно управлять сроками и обновлением, чем собирать «зоопарк» самоподписанных решений.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Чек-лист: быстрый аудит MongoDB production на VDS

1. RAM: выставлен адекватный cacheSizeGB, есть запас ОС, нет регулярного OOM или свопинга.
2. Disk/I/O: journaling включён, диск не умирает под очередями, spikes объяснимы (чекпоинты/бэкапы) и не выходят за SLO.
3. Replica set: есть quorum (3 голоса), elections редкие и предсказуемые, драйверы корректно переживают failover.
4. Backup/restore: есть сценарий восстановления и он протестирован, измерены RPO/RTO.
5. Конфиг: bindIp ограничен, логи пишутся, параметры меняются только после измерений.

Типовые симптомы и что проверять в первую очередь

Симптом: p99 записи «плавает» и иногда скачет в разы

• проверьте I/O (очереди, iowait) во время скачков;
• сопоставьте со временем чекпоинтов и бэкапов;
• убедитесь, что cacheSizeGB не съедает память ОС под page cache.

Симптом: частые elections и stepdown

• диагностируйте сеть между узлами (потери, jitter, перегрузка);
• ищите признаки проблем с диском (рост латентности записи и fsync);
• проверьте, что у кластера стабильный quorum и нет «хлопающего» арбитра.

Симптом: бэкап есть, но восстановление «не взлетает»

• индексы создаются слишком долго — учитывайте это в RTO;
• снапшот снимался неконсистентно — нужен корректный процесс и тест;
• restore делается на слишком слабый диск или CPU — восстановление может быть медленнее, чем вам кажется по продакшену.

Вывод

Для MongoDB на VDS критично не «накрутить параметры», а выстроить баланс: разумный WiredTiger cache, включённый journaling с адекватным диском и replica set с реальным quorum, чтобы elections были редкими и не превращались в аварию для приложения. Добавьте к этому проверяемый backup/restore — и эксплуатация станет заметно спокойнее.