Налаштування 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 — ми знайдемо вузькі місця та запропонуємо план оптимізації.