Чому MongoDB Replica Set деградує під навантаженням
Типовий старт — одна інсталяція на одному сервері: поки запис невеликий, вона справляється. Навантаження на базу зростає разом із кількістю користувачів і фонових завдань, а точка відмови залишається рівно одна.
Перший же збій обладнання переводить проєкт у ручне відновлення: підняти копію, відновити журнальні записи, перевірити цілісність і тільки потім відкрити доступ.
Ціна такого сценарію — не сам збій, а час. Простій бази даних вимірюється годинами й тягне за собою черги фонових завдань, повторні спроби клієнтів і втрачені замовлення.
Гірше те, що відновлення ніхто не репетирував: копії знімаються за розкладом, але ніхто не вимірював, скільки займає підйом із них під реальним навантаженням.
Replica Set закриває цю діру: кілька вузлів тримають ту саму колекцію даних, розбіжності передаються потоком операцій, а ролі перемикаються автоматично.
Відмовостійкість MongoDB не вмикається сама по собі — вона рівно настільки надійна, наскільки акуратно задані кворум, правило підтвердження запису й пріоритети вузлів.
Зібраний «на око» набір із трьох процесів перемикається довго, а відсталий вторинний вузол робить відкат на нього безглуздим.
Реплікація MongoDB — це ще й розподіл читання. Далі розбираємо, як це закривається: де налаштування за замовчуванням шкодять, які параметри правлять першими і як перевірити, що відмова вузла пройде без чергового.
Що дає кластер із реплік: доступність і класи відмов
Кластер реплік у MongoDB — це один вузол, що приймає записи, і кілька копій, які отримують зміни через журнал операцій.
Запис підтверджується лише після того, як його прийняла більшість голосуючих учасників: саме ця властивість, а не сам факт трьох копій, дозволяє втратити вузол без втрати даних. Читання при цьому можна розводити по копіях, знімаючи навантаження з основного.
Класи відмов різняться ціною:
- Відмова вторинного вузла — кластер її не помічає, читальний трафік іде на копії, що залишилися.
- Відмова вузла-лідера — вибори нового займають секунди, застосунок перепідключається сам, без ручного перемикання.
- Втрата стійки або майданчика — при розподілі копій по зонах доступності кворум зберігається, база продовжує писати.
- Розрив зв’язку між майданчиками — правило більшості не дає двом частинам одночасно вважати себе головними.
Висока доступність бази вимірюється тут часом відновлення: воно зменшується з годин ручного розбору до десятків секунд автоматичного перемикання, а частка відмов, що потребують втручання чергового, скорочується.
Планові роботи — оновлення, заміна вузла, зміна конфігурації — перестають бути вікном простою, бо виконуються по одному учаснику за раз.
Гарантії тримаються не на кількості копій, а на налаштуваннях: рівень підтвердження запису, пріоритети учасників, відкладена копія для захисту від помилкового видалення. Три вузли без цього — просто три копії.
Набір реплік MongoDB: порівняння топологій і режимів
Вибір топології визначається не розміром даних, а тим, який клас відмов потрібно пережити і скільки супроводу ви готові за це платити.
Набір реплік із трьох вузлів закриває відмову одного сервера, але не рятує від втрати майданчика; шардування вирішує стелю за обсягом і записом, але додає маршрутизацію, балансування й окремий контур експлуатації.
Перед порівнянням фіксуємо два параметри, що задають поведінку при збої: підтвердження запису (скільки вузлів мають зафіксувати операцію) і пріоритети читання (читаємо з ведучого чи допускаємо затримку реплікації). Далі вибір зводиться до чотирьох варіантів.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Один вузол | Розробка, стенди, внутрішні сервіси без вимог до доступності | Відмова сервера — простій і відновлення з резервної копії, автоматичного перемикання немає |
| Набір реплік, 3 вузли | Базовий робочий варіант: відмовостійкість без зростання складності | Потрібен непарний кворум для виборів; дані мають уміщатися на одному вузлі |
| Набір реплік із розміщенням по майданчиках | Потрібно пережити втрату стійки або майданчика | Зростає затримка підтвердження запису; потрібне тегування зон і контроль арбітра |
| Шардований кластер | Потік запису або обсяг не вміщається на один вузол | Балансувальник, ключ шардування, маршрутизатори; складність експлуатації зростає необоротно |
Для більшості сервісів стартовий режим розгортання — набір реплік: автоматичне перемикання при відмові вузла плюс можливість розвантажити читання репліками.
До шардування переходять, коли впирається запис або диск, і планують його заздалегідь — вибрати ключ шардування постфактум майже завжди боляче.
Етапи впровадження: від аудиту схеми до передачі в експлуатацію
Впровадження відмовостійкого кластера — це не одна команда в терміналі, а послідовність перевірюваних кроків, де кожен наступний спирається на результат попереднього.
Ми не починаємо налаштування, поки не розуміємо профіль навантаження й стан бази: інакше набір збереться, але вибори первинного вузла проходитимуть не там, де потрібно, а застосунок продовжить чекати відповіді від недоступного вузла.
- Аудит бази. Дивимося розмір робочого набору, характер запитів, вузькі місця за індексами, поточні налаштування підтвердження запису й читання. Окремо фіксуємо, які дані обов’язково мають бути синхронними, а які допускають відставання репліки.
- Проєктування схеми кластера. Визначаємо кількість вузлів, пріоритети при виборах, розміщення по зонах відмов, ролі вузлів даних і арбітра, план адресації та портів.
- Оновлення конфігурації та підготовка середовища. Параметри реплікації, виділення дисків під журнал і дані, таймаути виборів, автентифікація між вузлами й права сервісних облікових записів.
- Розгортання та первинна синхронізація. Піднімаємо вузли, ініціалізуємо набір, ведемо відставання реплік до нуля й перевіряємо, що читання з реплік віддає консистентні дані.
- Перевірка перемикання. Планова зміна первинного вузла, імітація відмови, поведінка драйверів і застосунку при перепідключенні, зворотний перехід без втрати записів.
- Регламенти й моніторинг. Резервні копії з вторинного вузла, контроль черги реплікації, пороги оповіщень, порядок планового обслуговування без простою.
- Передача в експлуатацію. Документація по кластеру, розбір типових збоїв із вашою командою, схема ескалації та вікно супроводу після запуску.
Кожен етап закінчується артефактом: звітом аудиту, схемою розміщення, конфігурацією, протоколом перевірки перемикання. Так передача в експлуатацію йде не за словами, а за підтвердженою поведінкою системи.
Артефакти проєкту: конфігурації, схеми й регламенти обслуговування
Після здачі проєкту в замовника залишається не лише робочий кластер, а й комплект документів, за яким його можна експлуатувати без нас.
Усе, що ми налаштовували вручну, фіксується в репозиторії й передається разом із доступами: інженеру, який прийде пізніше, не доведеться відновлювати логіку за непрямими ознаками.
- Конфігурація реплік — файли налаштувань кожного вузла з ролями, пріоритетами виборів, тегами зон і параметрами журналу операцій. За ними видно, який вузол приймає запис і як поводитиметься кластер при відмові.
- Схема кластера — топологія розміщення вузлів по зонах доступності, напрямки реплікації та перелік точок відмов з оцінкою наслідків.
- Політики доступу — роздільні облікові записи для застосунку, моніторингу й резервного копіювання, ролі з мінімально потрібними правами, автентифікація між вузлами та шифрування трафіку.
- Регламент обслуговування — порядок планового перемикання основного вузла, введення й виведення реплік, оновлення гілки та контролю відставання.
- Резервне копіювання — розклад, тип копій, термін зберігання, місця розміщення й обов’язкова перевірка відновлення на окремому контурі.
- Моніторинг і оповіщення — набір метрик із порогами спрацювання та список тих, хто отримує повідомлення.
- Інструкція з типових інцидентів — покрокові дії при втраті основного вузла, розсинхроні реплік і втраті кворуму.
- Передача доступів і розбір — підсумкова зустріч із командою замовника: проходимо по кожному документу й відповідаємо на запитання.
Кейс: переведення бази на набір реплік без простою
Клієнт прийшов з одним вузлом MongoDB і нічним знімком: планове обслуговування сервера означало вікно недоступності, а відмова диска — відновлення з архіву.
Індекс на 40 ГБ після збою перебудовувався майже годину, застосунок у цей час віддавав помилки, і ніхто не міг точно сказати, скільки записів втрачено між останнім знімком і відмовою.
Розгорнули набір реплік із трьох вузлів у різних зонах доступності: первинний приймає запис, два вторинних тримають копію й голосують за нового лідера.
Пріоритети налаштували так, щоб роль первинного забирав вузол із швидким диском, а журнал операцій покривав не менше доби — цього достатньо, щоб підняти відсталу репліку без повної синхронізації.
Метрики після впровадження: перемикання при відмові вузла скоротилося з ручних 20-40 хвилин до 10-15 секунд автоматично, вікно планових робіт пішло в нуль — вузли оновлюються по одному, набір увесь час зберігає кворум.
Частка записів, підтверджених більшістю реплік, зросла до 100%, тому перемикання більше не відкочує дані.
Інженери замовника отримали схему топології, перевірки стану набору й порядок дій при втраті вузла. З набору можна вивести будь-яку репліку для ремонту й повернути її назад — відкат до попереднього стану залишається можливим на кожному кроці.
Чим набір реплік відрізняється від шардованого кластера?
Набір реплік (MongoDB replica set) закриває задачу відмовостійкості: ті самі дані лежать на кількох вузлах, запис приймає ведучий, решта тримають копії й можуть віддавати читання.
Випав вузол або пішов на планове обслуговування — вибори піднімають нового ведучого, запис не зупиняється. Пропускна здатність запису при цьому все одно обмежена можливостями одного вузла.
Шардування — це вже масштабування бази: колекції діляться за ключем шарда між вузлами, і кожен шард сам є набором реплік. Зростає і обсяг, і сумарний потік запису.
Плата — додатковий шар маршрутизації та сервери конфігурації: більше вузлів під наглядом, а невдалий ключ шарда дає перевантажений шард, і перерозподіляти дані доводиться вручну.
Різниця replica set і шардування в тому, що саме впирається в стелю. Якщо боляче від відмов, планових робіт і відставання вторинних вузлів — достатньо реплікації. Якщо робочий набір не вміщається в ресурси одного вузла або один вузол не перетравлює потік запису — потрібен шард.
На практиці підходи поєднують: набір реплік — базовий захист у бойовому середовищі, шардування додають поверх, коли даних і навантаження стало більше, ніж тягне вузол.
Порядок розумний — спочатку відмовостійкість, потім масштабування: перехід на шардування це окрема міграція з вибором ключа, налаштуванням маршрутизації та перевіркою, що дані розподілилися рівномірно.
Технічні сумніви щодо експлуатації кластера
Сумніви зазвичай з’являються вже в експлуатації, коли кластер працює під навантаженням.
Нижче — відповіді на запитання, які найчастіше піднімають на цьому етапі: як поводиться застосунок при зміні ведучого вузла, скільки вузлів достатньо, як перевірити перемикання і навіщо копії при працюючій реплікації.
Застосунок упаде, коли ведучий вузол зміниться?
Ні, якщо в рядку підключення перелічені всі вузли набору, а не одна адреса: драйвер відстежує зміну ведучого й перепідключається сам.
Помітна лише коротка затримка на запитах у момент вибору — тому операції, чутливі до таймауту, переводимо на повтор із захистом від подвійного застосування.
Скільки вузлів тримати в наборі?
Три — мінімум для автоматичного вибору ведучого: два вузли з даними плюс арбітр або три повних. Парне число без арбітра кворуму не дає, і відмова одного вузла перетворюється на зупинку запису. Четвертий і п’ятий вузли додають під аналітику й георозподіл.
Як переконатися, що перемикання працює?
Примусовим пониженням ведучого на стенді: фіксуємо, за який час набір вибирає нового і скільки запитів втрачає застосунок. Перевірку повторюємо за регламентом і обов’язково на вузлі із затримкою застосування операцій — інакше відмова виявиться в момент реальної аварії.
Чи потрібні копії, якщо є реплікація?
Так. Реплікація захищає від відмови вузла, але не від помилкового видалення колекції, псування даних або втрати майданчика. Копію знімаємо з окремого вузла узгодженим знімком, зберігаємо поза кластером і раз на місяць перевіряємо відновленням на окремому стенді.
Обговоримо задачу: що потрібно від вас для старту
Для первинної оцінки не потрібен доступ до вашого продакшену й повна інвентаризація — достатньо опису задачі та поточної схеми.
Чим конкретніші вхідні дані, тим точніша оцінка й план робіт: налаштування MongoDB Replica Set помітно різниться для трьох вузлів в одній зоні та для розподіленої конфігурації з окремим вузлом-арбітром.
Що надіслати для старту:
- поточну топологію: де розміщені вузли, як застосунок звертається до бази, чи є проміжний балансувальник з’єднань;
- режим роботи MongoDB — одиночний вузол, набір реплік або шардування, і чи плануєте змінювати схему;
- профіль навантаження: співвідношення читання й запису, пікові вікна, добовий обсяг змін, розмір колекцій;
- вимоги до доступності: скільки вузлів допустимо втратити без зупинки сервісу і який час перемикання на новий основний вважаєте прийнятним;
- обмеження за вікном робіт, рівнями доступу й мережевими зонами між майданчиками;
- поточні точки болю — ручне перемикання, розходження даних, зростання затримок при реплікації, поведінка при плановому обслуговуванні.
За цими вхідними ми повертаємося з оцінкою трудомісткості, планом робіт за етапами й строками, а також із переліком ризиків, які бачимо до початку.
Далі узгоджуємо схему відпрацювання відмов, порядок перевірки на тестовому контурі й те, як виглядатиме передача експлуатації вашій команді. Опишіть задачу у вільній формі — повернемося з оцінкою та планом.
