Налаштування автоматичного Failover при збої: Patroni, Redis Sentinel

Чому без автоматичного failover сервіс лежить годинами

Ніч, вузол бази перестав відповідати. Репліка формально жива, але піднятися сама не може: ручне перемикання ролей прописано в регламенті, а мастер-вузол у конфігурації один.

Додаток продовжує писати, частина запитів іде на застарілу копію, кеш віддає дані, яких у базі вже немає, — і сервіс виглядає робочим, поки розсинхрон реплік не проявиться поверненнями та розбіжностями у звітах.

Ціна такої відмови не в залізі, що впало. Поки черговий інженер дістається до ноутбука, отримує доступи й вручну перемикає роль, минає від півгодини до кількох годин; простій при відмові вузла вимірюється не часом перезапуску, а часом реакції людини.

Єдина точка відмови тут — не сервер, а один черговий з телефоном: другий збій підряд розгрібати нікому, а рішення ухвалюється за непрямими ознаками.

Найважче — вихід з аварії. Вузол, що повернувся, зберігає свою версію даних, і треба вручну вирішити, чия копія ведуча, що перелити, а що відкинути. Помилка на цьому кроці тихо потрапляє в робочу базу: частина записів губиться, частина дублюється в замовленнях і платежах.

Автоматичний failover прибирає з цієї схеми очікування людини: кластер сам бачить, що вузол не відповідає, і передає роль живій копії, а той, що повернувся, тримає відключеним від запитів до звірки. Розбираємо, як це закривається і що перевіряють до включення автоматики.

Що змінюється після впровадження перемикання без людини

Головна зміна — відновлення перестає залежати від того, хто опинився на чергуванні. Кластер сам визначає, що ведучий вузол недоступний, знімає з нього роль і піднімає нового ведучого, а додатки через менеджер підключень переходять на актуальну адресу без правки конфігів.

Patroni тримає стан у розподіленому сховищі узгодження, тому рішення ухвалюється за фактом втрати кворуму, а не за чиєюсь командою.

Цільовий час відновлення стає проєктним параметром, а не побажанням. Пороги виявлення, таймаути та умови голосування налаштовуються під профіль навантаження: від збою до приймання запитів новим ведучим минають одиниці хвилин замість годин ручного розбору.

Після перемикання сервіс перевіряється автоматично — пул з'єднань піднімається, тривога знімається, подія залишається в журналі з точним часом кожного кроку.

Зникає цілий клас відмов «черговий не встиг зреагувати». Нічна зміна перестає бути точкою відмови: інженер розбирає вже пережиту ситуацію, дивиться журнал перемикання й вирішує, чи потрібна планова робота. Графік чергувань розвантажується, а розбір інцидентів зміщується в бік профілактики.

Доступність сервісу перестає оцінюватися на око. Ми виводимо метрики: час до виявлення, час до відновлення, кількість перемикань та їхні причини, частка сценаріїв, що пройшли без участі людини. За ними видно, де ще залишається ручний крок — і його закривають наступною ітерацією.

Режими автоматичного failover: ручний, автомат, гібрид

Вибір режиму визначається тим, хто ухвалює фінальне рішення — черговий інженер чи координатор кластера.

Patroni утримує лідер-ключ у розподіленому сховищі й при втраті зв'язку знімає роль з вузла, а сторожовий механізм кешу (Redis Sentinel) при недоступності мастера збирає голоси й підвищує репліку.

Швидкість реакції — секунди проти хвилин у людини, але автоматика працює лише при живому кворумі кластера.

Другий фактор — топологія. На двох майданчиках кворум зібрати нічим, і тоді автоматика небезпечніша, ніж корисна: обидві сторони вважають себе живими й пишуть паралельно.

Тут виручає гібридна схема — координатор піднімає тривогу й готує кандидата, а переведення підтверджує інженер. Коли своєї команди на чергуванні немає, частину завдань закриває керований сервіс, але параметри перемикання в ньому задає провайдер.

Режим фіксуємо на етапі проєктування й перевіряємо на навчальному збої: заміряємо час переведення до приймання трафіку й переконуємося, що дані не розійшлися.

Як проходить впровадження: від аудиту до передачі в експлуатацію

Порядок робіт не залежить від того, що саме захищаємо — кластер бази, кеш чи чергу повідомлень. Спершу фіксуємо поточний стан і реальні точки відмови: без цього автоматичний failover спрацьовує не там, де очікується, і додає аварій замість того, щоб їх закривати.

1. Аудит інфраструктури: інвентаризація вузлів, топологія реплікації, відставання реплік, поточні таймаути й те, хто перемикає роль сьогодні — черговий за інструкцією чи скрипт.
2. Проєктування відмовостійкості: кворум, кількість синхронних реплік, поведінка при втраті зв'язку між майданчиками. Окремо розбираємо розщеплення кластера, коли обидві сторони вважають себе головними.
3. Налаштування керуючого шару — Patroni: пріоритети перемикання, інтервали перевірок живості, поріг застарівання, порядок вибору нового лідера.
4. Налаштування клієнтського доступу: єдина точка підключення, щоб додаток переживав зміну лідера без правки конфігурацій і перезапуску.
5. Перевірка відмови на бойовому контурі: гасимо вузол, заміряємо час перемикання, втрати записів і поведінку додатка. Навчання повторюємо до відтворюваного результату.
6. Регламент експлуатації: алерти, зони відповідальності чергових, порядок повернення вузла в кластер і правила відкату на попередню схему.
7. Передача: документація, схеми, навчання зміни й розбір першого інциденту вже разом з вашою командою.

Після передачі схема живе без нас: у чергових є інструкція на кожен сценарій, а у вас — зрозуміла межа, за якою починається наша підтримка.

Конфігурації, схеми та регламенти, які залишаються у вас

Автоматичний failover тримається не на одному скрипті, а на наборі артефактів, які можна прочитати, перевірити й передати іншому інженеру.

Ми віддаємо їх у придатному для репозиторію вигляді: конфігурації — у системі контролю версій, схеми — в описі кластера, регламенти — у базі знань команди.

• Робоча конфігурація кластера: параметри Patroni (кворум, таймаути, синхронний режим) та Redis Sentinel (quorum, час до оголошення вузла недоступним) з коментарем, чому вибрано саме таке значення.
• Схема відмовостійкості: топологія вузлів, точки відмови, шар консенсусу, поведінка при розділенні мережі й порядок відновлення після split-brain.
• Правила перемикання: за яких умов роль переходить на репліку, хто ініціює перехід, що відбувається з асинхронною реплікацією та можливою втратою останніх транзакцій.
• Регламент чергування: рівні спрацьовування алертів, зона відповідальності чергового, точки ескалації та чек-лист перших дій після збою.
• Журнал перевірок: календар навчань з відключенням лідера, заміри часу перемикання, знайдені проблеми з відміткою про усунення.
• Інструкції для чергових: сценарії «впав лідер», «немає кворуму», «репліка відстала» з командами діагностики та порядком відкату.
• Схема моніторингу: метрики стану кластера, затримка реплікації, статус консенсусу, пороги алертів і прив'язка до чергового.

Розбір впровадження: база під навантаженням і кеш поруч

Кластер основної бази й кешу жив без автоматичного перемикання: при відмові ведучого вузла черговий піднімав репліку вручну за чек-листом, а додаток продовжував ходити на вузол кешу, що впав, до перезапуску.

За квартал спостережень — шість відмов, перемикання від 20 до 40 хвилин, і після кожного залишався ризик роз'їханої реплікації.

Що змінили

Автоматичний failover зібрали на двох рівнях. Базу перевели на Patroni: конфігурація кластера живе в розподіленому сховищі, вибори нового ведучого йдуть без людини, а правила кворуму не дають підняти другий ведучий при розділенні мережі.

Кеш отримав схему зі спостерігачами, які голосують за переведення клієнтів на живу репліку — додаток не чекає перезапуску.

Після налаштування перемикання вкладається в 20–30 секунд і йде без участі чергового, інцидентів за квартал — один замість шести: коротке зростання затримок замість відмови сервісу.

Втрат підтверджених транзакцій немає — синхронний запис віддає підтвердження клієнту лише після приймання потрібною кількістю вузлів.

Окремий ефект — зникла ручна звірка реплік після кожного перемикання: цілісність даних тримає сам кластер, а не інженер з чек-листом. Залізо й мережа відмовляють і далі, але відмова стала короткою подією за регламентом, а не інцидентом з нічним розбором.

Чим відрізняється перемикання ролей у базі від кешу?

У кластері бази роль ведучого вузла може бути тільки одна: якщо після збою піднімуться два ведучі, вони почнуть приймати записи незалежно, і цілісність даних опиниться під питанням.

Тому автоматичний failover тут — це не просто вибір нового вузла, а доказ, що попередній ведучий зупинений: кворум, підтвердження від реплік, затримка на ухвалення рішення. Кластер свідомо довше залишається недоступним на запис, ніж міг би.

У кеші пріоритет зворотний. Дані відновлювані з бази, тому втрата кешу — не аварія, а холодний старт: запити разом ідуть у сховище, і навантаження на нього зростає кратно.

Ролі в кластері перерозподіляються простіше, але ціна помилки — не розходження записів, а сплеск затримок на всьому сервісі, поки кеш не прогріється.

Звідси різні вимоги до налаштування: для бази задаємо кворум, таймаути й порядок підтвердження, для кешу — швидкість перемикання й коректний прогрів.

Перевіряємо це навчаннями: гасимо ведучий вузол і дивимося, скільки живе деградація, чи коректно змінилася роль і як швидко відновився кеш.

Що найчастіше запитують про відмовостійкість

Перед стартом робіт сумніви у замовника та його інженерів зазвичай одні й ті самі — від хибних спрацьовувань до того, хто відповідає за експлуатацію після здачі. Розбираємо їх заздалегідь, щоб не з'ясовувати це в момент аварії.

Що буде при розщепленні кластера?

Запис дозволено рівно одному вузлу, решта переводяться в режим тільки для читання й отримують заборону приймати зміни. Втративши зв'язок з більшістю, попередній лідер сам складає повноваження. Сценарій з двома джерелами конфліктних даних стає неможливим.

Як перевірити перемикання, не зупиняючи сервіс?

Навчання проводимо на живій конфігурації з ізоляцією одного вузла, а не всього контуру — додаток продовжує обслуговувати запити. Заміряємо, за скільки новий лідер прийняв навантаження і чи залишилися незавершені операції. Окремо дивимося на репліки, що відстали: вузол, який не наздогнав журнал, підвищувати не можна.

Хто відповідає за експлуатацію після запуску?

Передаємо не тільки налаштування, а й правила: як читати стан кластера, що робити при відсталій репліці, коли перемикання запускають вручну. Прогоняємо ці сценарії з вашою командою на навчаннях. Далі можливий супровід з обумовленими термінами реакції або чергуванням інженера.

Обговоримо вашу схему відмовостійкості

Щоб розрахувати поведінку кластера при відмові, потрібні факти, а не формулювання «хочемо відмовостійкість».

Нам важливі профіль навантаження, допустиме вікно недоступності й те, як додатки переживають зміну лідера, — від цього залежить вибір між синхронною та асинхронною реплікацією, пороги перемикання й кількість вузлів кворуму. Тому для оцінки та плану надішліть:

• схему поточного контуру: скільки вузлів, де розміщені, як налаштовані Patroni та Redis Sentinel, чи є окремий вузол для голосування;
• опис навантаження: пікові запити за секунду, частка операцій запису, обсяг даних і швидкість його зростання;
• вимоги до відновлення: допустимий час недоступності, допустима втрата останніх операцій, поведінка при мережевому розділенні;
• конфігурації та актуальні гілки використовуваних СУБД і Redis, а також схему резервного копіювання;
• історію збоїв: як система поводилася при відмовах вузлів і мережі за останній період, де перемикання не спрацьовувало;
• обмеження на доступи, вікна обслуговування та вимоги щодо розміщення даних у конкретних контурах.

У відповідь повернемо оцінку та план робіт: цільову схему розміщення вузлів, режими реплікації й пороги перемикання, порядок поетапного впровадження з перевіркою на навчальних відмовах — обрив зв'язку, зупинка лідера, повернення вузла в стрій.

Окремим блоком опишемо передачу в експлуатацію: інструкції для чергової зміни, набір оповіщень, критерії, за якими перемикання вважається штатним.

Опишіть задачу у вільній формі — повернемося з оцінкою та планом.