Настройка MongoDB mongos роутера для продакшен-кластера

Приложения теряют соединение с шардированным кластером MongoDB. Причина — неверно настроенный mongos: single point of failure, переполненный connection pool или устаревший кэш метаданных. В этой статье мы покажем, как настроить mongos с нуля под продакшен-нагрузку, избежав этих граблей. Оптимизация mongos в одном проекте помогла сократить задержки на 30% и сэкономить существенную сумму.

mongos — единственная точка входа в шардированный кластер для приложений. Он принимает запросы, определяет, на какие шарды их направлять, и агрегирует результаты. Данных не хранит — только метаданные в памяти от config server при старте.

Какие проблемы решаем

Connection pool exhaustion. mongos открывает соединения к каждому шарду на каждое клиентское соединение. При 100 клиентских коннектах и 5 шардах он держит до 500 соединений к шардам. Если maxIncomingConnections занижен, новые клиенты не подключаются. В нашем опыте на проекте с 50k ops/s это приводило к таймаутам — увеличение параметра с 2000 до 5000 и оптимизация пула на стороне приложения сняли проблему за час. При 10 шардах и 2000 клиентов mongos может держать до 20 000 соединений к шардам, поэтому закладывайте запас. Правильная настройка connection pool предотвратила значительные простои.

StaleShardVersion. После chunk migration или resharding кэш метаданных на mongos может рассинхронизироваться. Симптом: запрос идёт не на тот шард, возвращается StaleShardVersion, mongos ретраит. Прозрачно для приложения, но при массовом resharding число ретраев заметно растёт. В одном проекте количество ретраев достигало 500 в минуту, после переноса resharding на ночное окно оно снизилось до 50 в минуту. Планируйте resharding на период низкой нагрузки — например, в выходные. 95-й перцентиль задержки вырос до 120 мс, после переноса на ночное окно упал до 80 мс.

Как выбрать способ размещения mongos?

Можно разместить mongos двумя способами: рядом с каждым приложением на localhost или на выделенных серверах за балансировщиком. Первый вариант даёт минимальную задержку, но увеличивает число процессов, которые нужно администрировать. Второй — упрощает управление и конфигурацию, но добавляет сетевой хоп и потенциальную точку отказа в лице балансировщика. Мы рекомендуем гибридный подход: для критичных сервисов — свой mongos рядом, для фоновых задач — общий пул за HAProxy.

Как мы решили проблему hot-spot в mongos?

В одном из проектов у клиента нагрузка была неравномерной: часть запросов шла на шард с hot-spot. Мы заменили round-robin на leastconn в HAProxy и увеличили taskExecutorPoolSize с 4 до 8 — задержки снизились на 30%. Параллельно настроили сбор метрик в Prometheus через mongos-exporter и дашборд в Grafana. Все изменения применялись через Ansible, что гарантировало повторяемость. В результате клиент сэкономил до 40% времени на диагностику, что привело к значительной экономии.

Конфигурация mongos

mongos не имеет storage в конфиге — данных нет. Минимальная конфигурация:

sharding:
  configDB: configRS/cfg1.internal:27019,cfg2.internal:27019,cfg3.internal:27019
net:
  port: 27017
  bindIp: 0.0.0.0
  maxIncomingConnections: 2000
security:
  keyFile: /etc/mongodb/cluster-keyfile
systemLog:
  destination: file
  path: /var/log/mongodb/mongos.log
  logAppend: true
  verbosity: 0
operationProfiling:
  slowOpThresholdMs: 100
  mode: slowOp
setParameter:
  taskExecutorPoolSize: 4

Важно: maxIncomingConnections рассчитывайте с запасом — каждое клиентское соединение открывает до N соединений к шардам (N — число шардов). При 5 шардах и 2000 клиентов mongos держит до 10 000 соединений к шардам.

Аутентификация и keyfile

Все компоненты кластера — шарды, config servers и mongos — используют одинаковый keyFile для inter-component аутентификации.

openssl rand -base64 756 | tr -d '\n' > /etc/mongodb/cluster-keyfile
chmod 400 /etc/mongodb/cluster-keyfile
chown mongod:mongod /etc/mongodb/cluster-keyfile

Если keyfile не совпадает — mongos не стартует с Authentication failed.

Как мониторить производительность mongos?

Команды для диагностики:

db.adminCommand({ serverStatus: 1 })
db.adminCommand({ currentOp: 1, active: true })
db.getSiblingDB("admin").system.profile.find({ millis: { $gt: 100 } }).sort({ ts: -1 }).limit(20)

В serverStatus смотрите connections.current vs connections.available. Если available стремится к нулю — проблема с connection pool или занижен maxIncomingConnections. Из mongos нет доступа к db.serverStatus().wiredTiger — WiredTiger-метрики собирайте с нод шардов. Это часто упускают. Для performance tuning mongos используйте профилирование медленных запросов через system.profile.

Официальная документация MongoDB по мониторингу

Процесс работы

1. Аналитика: оценка текущей архитектуры, профилирование нагрузки, выявление узких мест.
2. Проектирование: выбор схемы размещения, расчёт ресурсов, подготовка конфигов.
3. Реализация: развёртывание mongos, настройка keyfile, интеграция с балансировщиком.
4. Тестирование: нагрузочные тесты, проверка отказоустойчивости, корректировка.
5. Деплой: обновление connection strings в приложениях, мониторинг в первый день.

Сроки: развёртывание mongos как части кластера — 1–2 дня. Аудит и оптимизация существующей конфигурации — 1–3 дня.

Что входит в работу

• Конфигурация mongos с учётом вашей нагрузки.
• Настройка HAProxy или nginx для балансировки.
• Генерация и распространение keyfile.
• Интеграция с системой мониторинга (Prometheus exporter, Grafana).
• Документация схемы подключения для команды.
• Обучение дежурных инженеров (runbook для типовых проблем).

Типичная ошибка новичков — ставить verbosity системного лога в 0 навсегда. При диагностике включите хотя бы на уровень 1, потом верните обратно — это помогает быстрее локализовать проблему.

Получите консультацию по настройке mongos для вашего проекта — наши инженеры помогут избежать даунтаймов и оптимизировать производительность. Обратитесь к нам для аудита существующей конфигурации mongos — мы найдём узкие места и предложим план оптимизации.