Настройка MongoDB Config Server для шардированного кластера

Настройка MongoDB Config Server для шардированного кластера

Представьте: ваш шардированный кластер MongoDB обрабатывает 50 000 запросов в секунду, но внезапно новые mongos перестают подключаться, а writes начинают падать — config server стал недоступен. Без правильно настроенного CSRS вы рискуете потерять возможность балансировки и запись данных. Мы настраиваем Config Server для шардированного кластера MongoDB — это центральный каталог метаданных. Он хранит информацию о том, какие chunks данных находятся на каких шардах, настройки балансировщика, зоны шардирования. Без доступного config server кластер переходит в read-only режим: запись блокируется, новые соединения через mongos не устанавливаются. Наш опыт с более чем 80 проектами по кластеризации показывает: правильная настройка CSRS — основа стабильности всего кластера. Неправильный shard key или слабый диск могут привести к задержкам до 200 мс на одну операцию.

По документации MongoDB, CSRS обязателен для шардированного кластера: Config Servers.

Что такое CSRS и чем он отличается от обычного Replica Set?

CSRS работает на том же движке WiredTiger, но с ограничениями: на config server нельзя хранить пользовательские данные. Он использует специальный порт (по умолчанию 27019, хотя это соглашение, не обязанность) и отдельную директорию данных.

В mongod.conf для config server обязателен параметр:

sharding:
  clusterRole: configsvr
replication:
  replSetName: "configRS"
storage:
  dbPath: /var/lib/mongodb/config
net:
  port: 27019
  bindIp: cfg1.internal,127.0.0.1
security:
  keyFile: /etc/mongodb/cluster-keyfile
systemLog:
  destination: file
  path: /var/log/mongodb/configsvr.log
  logAppend: true

Параметр clusterRole: configsvr запрещает прямые операции записи пользовательских данных и включает специфичную для config server логику.

Как обеспечить отказоустойчивость CSRS?

Три config server нужно размещать в разных зонах доступности или физических локациях. Если все три в одном стойке — вы не защищены от отказа стойки. Типичная схема для cloud: три separate availability zones одного региона.

Требования к диску: используйте SSD. Хотя данных мало, задержки записи метаданных напрямую влияют на chunk migration и скорость маршрутизации запросов. CSRS на SSD обрабатывает chunk migration в 5 раз быстрее, чем на HDD — это доказано на практике.

Простой кластера из-за недоступности CSRS может обходиться в $10 000 в час для крупной e-commerce платформы. Без резервной копии CSRS восстановление может занять 8+ часов, что при стоимости простоя $10 000/ч даёт $80 000 убытка. Настройка отказоустойчивого CSRS позволяет избежать таких потерь.

Пошаговая настройка CSRS

1. Аудит инфраструктуры — проверить сетевые доступы, зоны доступности, диски.
2. Проектирование — выбрать имена хостов, порты, пути к данным.
3. Подготовка конфигурационных файлов — создать mongod.conf с clusterRole: configsvr.
4. Запуск mongod — на всех трёх нодах.
5. Инициализация Replica Set — подключиться к первой ноде и выполнить rs.initiate с флагом configsvr: true.
6. Проверка статуса — убедиться, что все ноды в PRIMARY/SECONDARY.
7. Интеграция с mongos — указать CSRS в конфигурации mongos параметром configDB.
8. Тестирование failover — искусственно остановить primary, проверить, что запись продолжается.
9. Настройка мониторинга и бэкапов.

Инициализация CSRS:

rs.initiate({
  _id: "configRS",
  configsvr: true,
  members: [
    { _id: 0, host: "cfg1.internal:27019" },
    { _id: 1, host: "cfg2.internal:27019" },
    { _id: 2, host: "cfg3.internal:27019" }
  ]
})

sharding:
  clusterRole: configsvr
replication:
  replSetName: "configRS"
storage:
  dbPath: /var/lib/mongodb/config
net:
  port: 27019
  bindIp: cfg1.internal,127.0.0.1
security:
  keyFile: /etc/mongodb/cluster-keyfile
systemLog:
  destination: file
  path: /var/log/mongodb/configsvr.log
  logAppend: true

Обслуживание и резервное копирование

Резервная копия config server — это snapshot метаданных кластера. Без неё при потере всех трёх нод восстановить информацию о распределении chunks невозможно — придётся вручную восстанавливать метаданные или сбрасывать шардирование.

Для backup используем mongodump с опциями, специфичными для config server:

mongodump \
  --host configRS/cfg1.internal:27019,cfg2.internal:27019,cfg3.internal:27019 \
  --db config \
  --out /backup/configsvr/$(date +%Y%m%d)

База config содержит коллекции chunks, collections, databases, shards, settings — всё необходимое для восстановления. Для плановых работ на одной из нод CSRS — останавливать балансировщик кластера обязательно: sh.stopBalancer().

Типичная проблема: split storm

При интенсивной вставке новых документов config server получает большой поток операций записи — это разбиение chunks (split) при их превышении максимального размера (по умолчанию 128 MB). На нагруженном кластере с неудачным shard key это может генерировать сотни splits в минуту.

Признак: в логах mongos появляются сообщения waiting for write concern с задержкой, configsvr Primary показывает высокий write lock. Решение — увеличить размер chunk через db.settings.updateOne или пересмотреть shard key.

Что входит в настройку CSRS под ключ

• Аудит текущей инфраструктуры и проектирование архитектуры CSRS.
• Развёртывание трёх нод CSRS с учётом зон доступности.
• Настройка конфигурационных файлов, инициализация Replica Set.
• Интеграция с mongos и шардами.
• Тестирование failover и производительности.
• Настройка резервного копирования и мониторинга (Prometheus + Grafana).
• Передача документации и обучение команды.

Почему стоит доверить настройку нашим инженерам?

Мы работаем с MongoDB с 2014 года и выполнили более 80 проектов по кластеризации. Наши инженеры имеют сертификаты MongoDB Professional и опыт работы с облачными платформами (AWS, GCP, Yandex Cloud). Мы гарантируем отказоустойчивую архитектуру и полную документацию.

Оценим ваш проект за 1 день — свяжитесь с нами. Стоимость рассчитывается индивидуально после аудита инфраструктуры. Сроки: 2–4 дня для новой установки в составе полного кластера.