Адміністрування MongoDB: де ламається продуктивність
Майже будь-яка деградація продуктивності бази починається непомітно: колекції зростають, робочий набір даних перестає вміщатися в пам'ять, і запити, які раніше відповідали миттєво, починають читати з диска.
Час відповіді збільшується не лінійно — на певному обсязі він зростає в рази, а пікове навантаження перестає вкладатися в початково виділені ресурси.
Друга типова точка — відсутність плану запитів як постійної практики.
Запит без відповідного індексу проходить по всій колекції, і його вартість зростає пропорційно її розміру: повільні запити MongoDB знаходять уже після скарг, коли причина розмита, а не на етапі рев'ю нового шаблону звернення.
Регулярна діагностика бази даних показує, які операції читають документи марно і які індекси не використовуються взагалі.
Масова запис дає окремий клас відмов. Оновлення великої кількості документів, перебудова індексу або важка агрегація утримують ресурси й вибудовують чергу операцій — блокування під час запису змушують паралельні звернення чекати й обриватися через перевищення часу очікування.
Поруч іде неконтрольоване зростання журналів і тимчасових файлів: вільне місце закінчується швидше, ніж приходить оповіщення.
Жоден із цих збоїв не лікується додаванням ресурсів наосліп.
Їх закриває системне адміністрування MongoDB: схема індексів під реальні звернення, ліміти й терміни зберігання журналів, пакетний запис з обмеженням паралелізму, метрики й оповіщення щодо затримки, черг і вільного місця. Розбираємо, як це закривається крок за кроком.
Що дає порядок у базі: швидкість відгуку та стійкість
Порядок у базі проявляється не у звітах, а в поведінці сервісу під навантаженням. Запит без відповідного індексу читає колекцію повністю, і час відповіді зростає разом з обсягом даних.
Оптимізація запитів MongoDB починається з розбору повільних операцій і підбору складених індексів під реальні умови вибірки — відгук перестає залежати від того, наскільки виросла колекція.
Реплікація будується на наборі з кількох вузлів: у разі збою основного роль переїжджає на вторинний автоматично, застосунки продовжують працювати на тій самій адресі. Відмовостійкість бази забезпечує топологія, а не регламент «зателефонувати й підняти руками».
Час відновлення залежить не лише від перемикання ролі. Якщо вторинні вузли відстають від основного, переїзд небезпечний — частину записів можна втратити.
Тому ми контролюємо затримку застосування операцій, виносимо важкі вибірки на окремий вузол і тримаємо запас по диску, щоб відновлення вимірювалося секундами, а не зупинкою сервісу.
Ще один клас відмов — переповнення: журнали й тимчасові файли сортування займають диск раніше, ніж він закінчиться за даними. Обмеження розміру й терміну зберігання журналів, винесення сортувань за межі пам'яті та контроль вільного місця знімають цей сценарій повністю.
Моніторинг тут не прикраса. Ми відстежуємо повільні операції, відставання реплік, зростання індексів і дисковий простір, а тривоги налаштовуємо на метрики, за якими справді ухвалюють рішення.
Схеми розгортання: один вузол, репліка, шардований кластер
Схему розміщення обирають не за обсягом даних, а за вимогами до доступності та профілем навантаження.
Одиночний вузол тримає невеликі сервіси й тестові контури, де короткий простій припустимий; набір реплік — базова схема для робочих систем; розділення за вузлами підключають, коли робочий набір і потік запису перестають вкладатися в один сервер.
Різниця принципова: набір реплік зберігає ті самі дані на кількох вузлах — це відмовостійкість, автоперемикання при збої та розвантаження читання.
Шардування ділить колекції між вузлами за ключем, і кожен шард залишається набором реплік, тобто надійність не скасовується, а надбудовується. Помилка в ключі дає перевантажений шард, який гальмує всю систему, — ключ проєктують за реальними запитами.
| Варіант | Коли підходить | Що дає | Обмеження |
|---|---|---|---|
| Одиночний вузол | Внутрішні сервіси, тести, невелике навантаження | Проста експлуатація | Простій при збої, немає резерву, стеля за обсягом і записом |
| Набір реплік | Робочі системи з вимогою до доступності | Автоперемикання, читання з реплік, копії з вторинного вузла | Запис іде через первинний вузол — зростання запису не дає |
| Шардований кластер | Дані й запис не вміщаються в один вузол | Зростання обсягу й запису додаванням шардів | Складніша експлуатація, ключ змінювати дорого, потрібні маршрутизувальні процеси |
Перехід між схемами планують заздалегідь: з одиночного вузла на набір реплік переходять майже без простою, а шардування або закладають одразу, або вводять окремою міграцією з перерозподілом даних на живому кластері.
Адміністрування MongoDB: етапи впровадження та перевірки
Порядок робіт вибудовуємо так, щоб кожна зміна була оборотною, а ваша команда розуміла, що саме змінилося і навіщо.
Спочатку фіксуємо поточний стан, потім проєктуємо схему даних і реплікації, далі перевіряємо все на реальному навантаженні — і лише після цього передаємо базу в експлуатацію з регламентами та навчанням.
-
Аудит бази даних. Знімаємо профіль повільних операцій, статистику за колекціями та індексами, розмір робочого набору, поведінку журналу. На виході — перелік вузьких місць з оцінкою впливу на відгук, а не звіт загального вигляду.
-
Проєктування схеми реплікації. Визначаємо кількість вузлів, пріоритети виборів, розміщення читальних реплік і рівень підтвердження запису. Окремо описуємо поведінку при відмові вузла та порядок повернення його в набір за індивідуальним розрахунком.
-
Налаштування ролей доступу. Розводимо застосунки, аналітиків і адміністраторів за окремими обліковими записами з мінімально достатніми правами, для службових задач заводимо окремі ролі. Ключі та паролі йдуть у сховище секретів, а не лежать у конфігураційних файлах.
-
Індекси та параметри під профіль запитів. Додаємо відсутні складені індекси, прибираємо дублікати, перевіряємо, що плани виконання перестали йти в повний перебір колекції.
-
Перевірка під навантаженням. Відтворюємо профіль реальних запитів і окремо проганяємо відмови: падіння вузла, втрату зв'язку між майданчиками, відновлення з резервної копії. Вимірюємо відгук і час перемикання, фіксуємо класи відмов, які база переживає без втручання.
-
Передача бази в експлуатацію. Передаємо документацію за схемою та ролями, регламент резервного копіювання з перевіреним відновленням, налаштовані оповіщення за ключовими метриками та навчання вашої команди типових операцій.
Після передачі залишаємося на зв'язку: розбираємо інциденти й допомагаємо зі змінами, доки ваші інженери не почнуть вести базу самостійно.
Артефакти й документація, які залишаються в команди
Комплект документації збираємо так, щоб за ним можна було працювати без нас: ті самі конфігурації, що застосовані в робочому контурі, лежать у системі контролю версій з історією змін, а не в листуванні.
Кожен документ відповідає на конкретне питання чергового або нового інженера — що зламається, якщо зробити крок, і як відкотитися.
- Документація щодо бази: топологія контуру, призначення кожного вузла, параметри запуску з поясненням, чому вибрано такі значення і що буде при їх зміні.
- Схема реплікації: ролі вузлів, порядок вибору основного, поведінка при втраті вузла або цілої зони, процедура планового перемикання.
- Політики доступу: ролі застосунків і людей, розділення прав на читання й запис, сервісні облікові записи, порядок ротації.
- Регламент резервного копіювання: частота й глибина зберігання копій, де лежать, хто перевіряє відновлення і з якою періодичністю.
- Карта метрик: які показники знімаємо, межі норми, на що дивиться оповіщення і кого воно будить першим.
- Інструкції для чергового: покрокові дії при відмові вузла, переповненні сховища, деградації запитів — з точками, де потрібно зупинитися й покликати нас.
- Журнал змін: що і коли змінювалося, з якою метою, які проблеми це вирішило.
Документація оновлюється разом з конфігурацією, а не заднім числом, тому нею можна користуватися при передачі задач іншій команді або під час перевірки. Якщо всередині вашої команди вже є свої стандарти оформлення — підлаштуємо комплект під них, щоб він не ліг мертвим вантажем.
Кейс: прибрали деградацію під навантаженням і стабілізували відгук
Клієнт — сервіс із вечірнім піком замовлень, база MongoDB на реплікації з одним основним вузлом. До кінця дня відгук просідав: медіана відповіді на вибірку за замовленнями зростала з 0,2 до 1,9 секунди, а частина запитів йшла в таймаут.
Адміністрування зводилося до ручної реакції — алерти приходили вже після того, як клієнти бачили помилки, і інциденти розбирали за фактом.
Що було вузьким місцем
Основні вибірки йшли за індексами, що не підтримують сортування: рушій читав колекцію повністю й сортував результат у пам'яті.
Паралельно робочий набір виріс вище за обсяг пам'яті, тому читання йшли на диск, а важкі агрегації звітів запускалися в ті самі години, що й пік продажів.
Що змінили
- Переписали індекси під фактичні шаблони запитів — з урахуванням сортування й покриття полів, щоб вибірка закривалася індексом.
- Винесли звітні агрегації у вікно низького навантаження й на вторинні вузли.
- Увімкнули повільний лог із порогом і профілювальник на час розбору, далі — вибірково.
- Налаштували оповіщення за часткою запитів поза індексом, відставанням реплікації та зростанням черги очікувань.
- Обмежили робочий набір: архівація закритих замовлень і видалення застарілих технічних записів.
Що стало
Медіана відгуку на піку — 0,25 секунди, 95-й процентиль упав з 4 секунд до 0,6. Таймаути на читання зникли й не поверталися за весь час спостереження, включно з розпродажами.
Відставання реплікації під навантаженням залишається в межах секунд, а зростання колекцій більше не випереджає пам'ять — вузьке місце закрито на рівні схеми індексів і розкладу задач, а не разового налаштування.
Що робити, якщо база вже працює без реплікації
Ситуація типова: одиночний вузол тримає і запис, і читання, відмовостійкості немає, а зупиняти сервіс заради перебудови не можна. Повна зупинка й не потрібна — наявний вузол стає першим учасником набору реплік, дані при цьому залишаються на місці.
Далі до нього додаються другий і третій учасники: вони проходять повну синхронізацію, а потім докатують журнал операцій, поки первинний вузол продовжує обслуговувати запити.
Відставання журналу видно в моніторингу — коли воно вимірюється секундами, набір готовий до робочих перемикань.
Перемикання без простою впирається в рядок підключення застосунку: поки в конфігу вказано конкретний хост, зміна первинного вузла обернеться простоєм.
Переводимо його на адресу набору реплік заздалегідь, одночасно вмикаємо підтвердження запису більшістю вузлів і режим читання з вторинних — так підтверджені записи не втрачаються при відмові, а читання розвантажує первинний вузол.
Перевірку цілісності даних робимо до і після: контрольні суми колекцій, збіг лічильників документів і складу індексів між вихідним вузлом і кожним новим учасником. Журнал операцій має покривати все вікно синхронізації, інакше учасник піднімається заново повною копією бази.
План переходу фіксуємо письмово: вікно низького навантаження, критерії «йдемо/стоп» на кожному кроці, старий вузол залишається точкою відкату, поки набір не відпрацює під навантаженням кілька діб.
Сценарій — міграція бази, зміна первинного вузла, відкат — проганяємо на копії до продакшну: так перехід на реплікацію займає години, а не нічний аврал.
Часті технічні сумніви щодо налаштування та моніторингу
Сумніви щодо налаштування найчастіше про навантаження: чи не почне сам моніторинг MongoDB гальмувати робочу базу, чи не виросте час відповіді після ввімкнення профілювання, і як переконатися, що копія справді відновлюється.
Нижче — те, що інженери запитують до старту робіт. Відповіді про перевірюваний результат, а не про обіцянки.
Моніторинг не додасть навантаження на запис?
Заміри знімаємо з вторинних вузлів, профілювальник вмикаємо з порогом за тривалістю — у вибірку потрапляють лише повільні операції. Витрати на заміри залишаються в межах кількох відсотків, зате видно, які колекції формують навантаження.
Як переконатися, що резервна копія відновлюється?
Копія вважається робочою лише після розгортання на окремому контурі: піднімаємо стенд зі знімка, звіряємо контрольні суми колекцій і проганяємо типові запити застосунку. Перевірка відновлення копій стає регулярною процедурою з протоколом.
Коли пора шардувати?
Зазвичай пізніше, ніж здається: спочатку дивимося плани виконання запитів, склад і порядок полів в індексах, розмір робочого набору й піки навантаження на запис.
Часто достатньо ретенції та винесення аналітики — шардування залишаємо на випадок, коли дані перестають вміщатися на один сервер.
А якщо вузьке місце не там, де очікували?
Зіставляємо профіль повільних операцій, очікування блокувань і статистику звернень до індексів, потім відтворюємо сценарій на стенді під навантаженням. Діагностика вузького місця спирається на заміри до і після правки, тому внесок кожного налаштування видно окремо.
Обговоримо задачу: що перевірити у вашій базі насамперед
Щоб оцінка робіт по базі була точною, а не «плюс-мінус», нам потрібні вхідні дані щодо інфраструктури та профілю навантаження. Нижче мінімальний набір — він збирається за одну розмову, після чого ми рахуємо обсяг адміністрування MongoDB, порядок змін і точки ризику.
- топологія: скільки вузлів у наборі реплік, чи є шардування, де розміщені читальні вузли;
- профіль навантаження: співвідношення читання й запису, пікові години, розмір робочого набору та загальний обсяг даних;
- поточні параметри: конфігурація серверів, розмір журналу операцій, політика підтвердження запису, налаштування кешу;
- резервні копії: чим знімаються, з якою періодичністю і коли останнього разу перевіряли відновлення на окремому стенді;
- схема колекцій та індекси: які індекси не використовуються, чи є колекції з необмеженим зростанням;
- метрики за останній місяць: графіки затримок запитів, промахів кешу, відставання реплік і помилок із боку застосунків;
- доступи та вікна: як організовано доступ інженерів і які вікна припустимі для планових робіт;
- обмеження: вимоги регуляторів, ізоляція контурів, що не можна змінювати без окремого погодження.
За цими вхідними даними ми повертаємося з планом робіт: етапи, послідовність змін, точки відкату й перевірки після кожного кроку. Далі — старт: спочатку знімаємо базові метрики, щоб ефект від налаштувань було видно в цифрах, а не на словах. Опишіть задачу й надішліть те, що вже є по базі — обговоримо, з чого почати у вашому випадку.
