Налаштування 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 дні для нової установки у складі повного кластеру.