Автоматичний failover бази даних: де відмова вузла зупиняє сервіс
Відмова основного вузла рідко виглядає як гарна аварія — частіше це завислий процес, деградація диска або мережевий роздільник, при якому репліка формально жива, але застосунок уже не пише.
Без автоматичного failover бази даних перемикання лягає на чергового: він має помітити проблему, підтвердити, що це не хибна тривога, вручну підвищити репліку й перемкнути трафік. Поки триває це розслідування, сервіс стоїть.
Ціна ручного перемикання репліки складається з двох частин. Перша — простій бази даних: поки інженер розбирається, накопичуються помилки запису, зростають черги, частина запитів відвалюється за таймаутом.
Друга — втрата транзакцій: якщо репліка відстала від мастера, при підвищенні вона стає новим джерелом істини, і все, що не встигло доїхати, зникає безповоротно. Клієнт бачить не «база недоступна», а зникле замовлення або задвоєний платіж.
Окремий клас відмов — «тиха» деградація. Вузол відповідає на перевірки, але перестає приймати записи; реплікація стає через конфлікт або переповнення журналу.
Зовнішній моніторинг за одним ping цього не ловить, а ручний розбір займає десятки хвилин — рівно там, де рахунок іде на секунди.
Автоматичний failover влаштований не як «кнопка», а як набір умов: хто і за якими ознаками визнає вузол мертвим, як вибирається нова репліка, як захищаються від розділення мережі, щоб не підняти двох мастерів.
Нижче розбираємо, як це закривається для PostgreSQL і MySQL — від вибору нової репліки до повернення трафіку.
Як працює автоматичний failover: режими, метрики, вибір схеми
Автоматичний failover бази даних — це не «увімкнути галочку», а вибір схеми перемикання під профіль навантаження. Нижче — три робочі конфігурації, які ми розгортаємо, і чесні обмеження кожної.
Схема з кворумним арбітром
Окремий легкий вузол-арбітр голосує за підвищення репліки і не зберігає дані. Кластер переживає падіння основного вузла без ручного втручання: час відновлення вкладається в десятки секунд, Split-brain виключено. Обмеження — арбітр сам стає точкою відмови, тому його розміщують в окремій зоні доступності.
Режим синхронної реплікації
Транзакція підтверджується лише після запису на репліку — частка втрачених транзакцій падає до нуля. Ціна: затримка запису зростає на час підтвердження, а при деградації каналу можливе блокування запису. Підходить для фінансових і облікових контурів, де втрата навіть однієї транзакції неприпустима.
Асинхронна реплікація з швидким промоушеном
Запис не чекає репліку, тому затримка мінімальна. При аварії можлива втрата останніх транзакцій — вікно вимірюється секундами. Вибір для read-heavy сервісів, де швидкість важливіша за строгу узгодженість.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Кворумний арбітр | Критичний сервіс, потрібен автоматичний промоушен | Додатковий вузол в окремій зоні |
| Синхронна реплікація | Фінанси, облік, заборона втрати транзакцій | Зростання затримки запису, ризик блокування |
| Асинхронна реплікація | Read-heavy, висока пропускна здатність | Вікно втрати останніх транзакцій |
Метрики, за якими ми приймаємо схему: час відновлення, частка втрачених транзакцій, число ручних втручань за квартал. Для оркестрації використовуємо Patroni — він керує промоушеном і тримає кворум через розподілене сховище.
Розберемо ваш профіль навантаження і підберемо схему під нього.
Впровадження автоматичного перемикання: етапи інженерної роботи
Автоматичний failover бази даних не зводиться до встановлення одного демона-спостерігача: перемикання — це наслідок коректно спроєктованої топології, реплікації та правил голосування. Тому починаємо з аудиту, а не з налаштування, і доводимо до перевірки реальною відмовою.
- Аудит топології бази. Знімаємо поточну картину: де мастер, які репліки (синхронні чи асинхронні), як застосунок підключається — через пул з'єднань, проксі чи напряму за адресою. Фіксуємо точки відмови: єдиний вузол-координатор, відсутність кворуму, ручний перевід мастера.
- Проєктування схеми перемикання. Визначаємо модель: ведучий-ведений з автоматичним підвищенням або кворумна схема з розподіленим консенсусом. Задаємо пороги — скільки секунд мовчання мастера вважати відмовою, скільки реплік мають підтвердити підвищення, щоб не допустити «двох мастерів» і розходження даних.
- Налаштування реплікації. Приводимо потік даних до ладу: синхронний режим для критичних транзакцій, контроль відставання реплік, коректна обробка конфліктів після підвищення. Застосунок переводимо на адресу-посередник, який переживає зміну мастера без правки конфігурацій.
- Перевірка відмовою. Імітуємо падіння мастера, мережевий розділ, повернення старого вузла в стрій. Заміряємо час перемикання і перевіряємо, що застосунок відновив запис без ручного втручання, а дані не загубилися.
- Передача документації. Віддаємо схему топології, правила голосування, інструкції щодо планового перемикання і відкату, а також розбір сценаріїв, за яких автоматика навмисно не спрацьовує.
Порядок робіт вибудуваний так, що кожен етап перевіряємо до переходу до наступного: неперевірена реплікація на етапі проєктування обертається розходженням даних при першій же реальній відмові. Опишіть вашу поточну конфігурацію — повернемося з оцінкою та планом робіт.
Чим відрізняється автоматичний failover від ручного перемикання та балансування?
Автоматичний failover бази даних вирішує завдання, яке не закриває ні ручне перемикання, ні балансування читання. Це три різних механізми, і плутати їх — означає залишити систему без захисту на найуразливішій ділянці.
Ручне перемикання — це коли інженер помічає збій і вручну піднімає репліку в ролі лідера. Поки він не відреагував, запис стоїть: застосунки отримують помилки, транзакції відкочуються, черга накопичених операцій зростає.
Вночі, у вихідні, в момент пікового навантаження реакція займає хвилини — і весь цей час бізнес-процеси не працюють. Автоматичний failover прибирає людину з цього ланцюжка: система сама фіксує втрату лідера, обирає найактуальнішу репліку і переводить її в режим запису.
Балансування читання — про інше. Воно розподіляє запити на читання між репліками, щоб знизити навантаження на основний вузол. Це про продуктивність, а не про відмовостійкість запису: якщо лідер впав, балансувальник продовжить роздавати читання, але записувати дані буде нікуди. Тому балансування читання і автоматичний failover — не альтернативи, а два шари однієї архітектури.
Ключове поняття тут — роль лідера. У будь-який момент лише один вузол приймає запис; решта реплік наздоганяють його за журналом змін.
Автоматичний failover стежить за здоров'ям лідера і при збої передає його роль наступному вузлу, а решта реплік переналаштовуються на нового лідера. Розподіл навантаження на читання при цьому зберігається — змінюється лише точка запису.
Практичний висновок: балансування читання масштабує навантаження, але не рятує від відмови. Відмовостійкість запису забезпечує саме автоматичний failover — і тільки він скорочує простій з хвилин ручного втручання до секунд. Опишіть вашу конфігурацію — повернемося з оцінкою та планом впровадження.
Кейс: скорочення простою при відмові вузла в кластері бази даних
Клієнт прийшов із класичною картиною: провідний вузол кластера та репліка, ручне перемикання за інструкцією у wiki.
При відмові провідного черговий інженер піднімав репліку вручну — перевірка відставання, переведення в режим запису, перемикання рядка підключення в застосунку, прогрів кешу.
За логами інцидентів відновлення сервісу займало від 25 до 40 хвилин, і в третині випадків перемикання відбувалося з помилками: застосунок продовжував писати в вузол, що впав, частина транзакцій губилася, а відкат вимагав ще одного вікна простою.
Ми розібрали ланцюжок відмови і прибрали з нього людину. Кластер отримав кворумний арбітр, який підтверджує стан вузлів і не дає двом реплікам одночасно вважати себе провідними — це закриває split-brain при обриві зв'язку між майданчиками. Стан вузлів перевіряється за кількома незалежними ознаками, а не за одним пінгом.
Застосунок перемикається на новий провідний вузол через пул з'єднань із перевіркою живості: рядок підключення веде на віртуальну адресу, і зміна вузла не потребує правки конфігурації та перезапуску сервісів.
Що змінилося в метриках
| Показник | До | Після |
|---|---|---|
| Час відновлення сервісу | 25-40 хвилин | 40-90 секунд |
| Частка успішних перемикань | ~70% | 100% на навчальних і реальних відмовах |
| Ручні операції чергового | 8-12 кроків | 0 при штатній відмові |
| Втрата транзакцій при перемиканні | до кількох сотень | 0 у синхронному режимі реплікації |
Окремо перевіряли зворотний бік: автоматика не повинна спрацьовувати на короткочасних мережевих сплесках. Поріг підтвердження відмови та затримка перед перемиканням налаштовані так, що короткий збій зв'язку не запускає зміну провідного вузла, а реальна відмова — запускає. За пів року експлуатації жодного хибного перемикання.
Ручні операції залишилися тільки там, де вони доречні: планове обслуговування та повернення вузла в стрій після ремонту. Це знизило навантаження на чергових і прибрало головне джерело помилок — поспіх у момент аварії.
Patroni
Сумніви перед впровадженням: сумісність, міграція, відкат і доступи
Автоматичний failover — це надбудова над поточною реплікацією, а не заміна інфраструктури. Якщо у вас уже налаштовано потокове перенесення змін між основним вузлом і реплікою, ми додаємо шар керування: агент моніторингу, кворум для вибору нового лідера та маршрутизацію трафіку.
Існуючі схеми даних, індекси та права користувачів залишаються незмінними — змінюється лише те, хто ухвалює рішення про перемикання і як швидко.
Що якщо поточна версія бази не підтримує потрібний режим? Ми перевіряємо це на етапі розбору: звіряємо гілку, наявність розширень і топологію реплік, після чого пропонуємо або оновлення до актуальної гілки, або схему з проміжним вузлом-арбітром. Як проходить міграція?
Поетапно: спочатку репліка-кандидат вводиться в кворум, потім навантаження переноситься на неї в режимі читання, і лише після контрольного прогону перемикання стає автоматичним. Що якщо після впровадження щось піде не так?
Процедура відкату описана заздалегідь: повернення на попередній вузол, зняття агента з кворуму та відновлення ручного керування займають хвилини, а не години.
Хто отримає доступ до керуючих вузлів і як він розмежовується?
Доступи видаються за ролями: експлуатація бачить стан кластера і може ініціювати ручне перемикання, розробка — лише метрики та логи. Привілейовані операції з кворумом і конфігурацією агента доступні обмеженому колу з обов'язковим записом у журнал аудиту. Ключі та токени зберігаються в захищеному сховищі, а не в конфігураційних файлах на диску.
На руки замовник отримує повний комплект:
- Конфігурації агента моніторингу, кворуму та маршрутизатора трафіку з коментарями до кожного параметра.
- Схему поточної та цільової топології із зазначенням ролей вузлів і точок відмови.
- Політику розмежування доступів: ролі, права, порядок видачі та відкликання.
- Регламент ручного перемикання та процедуру відкату з покроковими командами.
- Набір перевірок для контролю стану кластера та пороги спрацювання.
- Документацію з експлуатації: що дивитися в першу чергу при збої і куди йти далі.
Опишіть вашу поточну топологію та версію бази — повернемося з оцінкою, планом міграції та переліком робіт під ваш контур.
Терміни впровадження автоматичного failover за етапами
Терміни залежать не від розміру бази, а від кількості точок відмови в поточній схемі: один вузол із ручним перемиканням проходиться швидше, ніж каскад реплік із балансувальником і розділенням читання/запису.
Нижче — орієнтовна тривалість за етапами, без прив'язки до календарних дат. Оцінку під ваш контур даємо після аудиту.
Етапи частково перетинаються: проєктування йде паралельно підготовці стенда, а регламенти пишуться вже під час впровадження. Найнепередбачуваніший пункт — обкатка: саме там випливають розходження у версіях, нестандартні розширення і запити, які не переживають зміну ролі. Тому стенд не скорочуємо — дешевше зловити split-brain на копії, ніж у проді.
Окремо закладаємо час на вікно спостереження після передачі: тиждень чергова зміна працює з новою схемою під нашим наглядом, і тільки потім закриваємо проєкт.
Підсумкова тривалість для типового контуру — від трьох до шести тижнів; каскад реплік і георозподіл додають до цього один-два тижні.
