Чому падає PostgreSQL високої доступності під час відмови вузла
Кластер із трьох вузлів виглядає відмовостійким рівно до першої відмови основного вузла. Потік реплікації обривається, підтвердження синхронного запису перестають надходити, репліка переходить у режим лише для читання: база формально жива, але нові дані приймати не може. Два сервери з трьох здорові, а запис стоїть.
Далі починається ручне перемикання за інструкцією: підняти репліку, перевести її в роль основного вузла, переписати конфігурацію, перенести віртуальну адресу, старий сервер перезібрати як репліку.
У спокійному режимі це десятки хвилин, вночі без доступу до консолі — довше, і кожен крок руками залишає місце для помилки.
Застосунок при цьому продовжує тримати з'єднання з недоступним вузлом. Пул не знає, що за адресою немає сервера, і видає все нові підключення туди ж — перезапуск сервісів або правка рядків підключення стають окремою задачею. У підсумку простій бази даних розтягується на години, хоча база на той момент уже піднята.
Окрема ціна — стан після аварії. Частина транзакцій не доїхала до репліки, після перебудови вона відстає й наздоганяє основний потік годинами. Якщо підняли другий вузол і не погасили старий, основних вузлів стає два, і розходження даних доводиться розбирати порядково.
Причина не в залізі, а у відсутності автоматики: рішення про відмову не приймається за формальним правилом, новий основний вузол не обирається, адреса не переїжджає.
Далі розбираємо, як це закривається зв'язкою Patroni з розподіленим сховищем стану та єдиною точкою входу для застосунків.
Що дає відмовостійкий кластер: вимірюваний ефект
Ручне відновлення після відмови основного вузла — це десятки хвилин простою: застосунок накопичує помилки підключення, зростає черга необроблених задач, черговий вручну піднімає репліку й перевіряє цілісність даних.
Кластер високої доступності на Patroni робить це сам — недоступність бази даних вимірюється секундами, а не хвилинами.
Час відновлення. Ключова метрика — скільки минає від зникнення основного вузла до приймання нових записів.
Пороги перевірки здоров'я та кількість підтверджених реплік налаштовуємо так, щоб автоматичне перемикання вкладалося в одиниці-десятки секунд, але не спрацьовувало хибно на короткочасних мережевих збоях. Транзакції, уже підтверджені клієнту, при цьому не втрачаються.
Автоматичне перемикання. Частка відмов, які кластер обробляє без людини, прямує до ста відсотків: вузол випав — роль основного перейшла до репліки, застосунок перепідключився за тією ж адресою.
Руки інженера залишаються потрібні лише для планових робіт: оновлення, зміни топології, переїзду між майданчиками.
Які відмови зникають. Відмовостійкий кластер закриває цілий клас аварій: розщеплення, коли запис іде у два вузли одразу, і читання застарілих даних з відсталої репліки.
Під навантаженням з'являється передбачуваність — читання розподіляється між репліками, запис іде на основний вузол, а вихід однієї репліки застосунок узагалі не помічає.
Варіанти організації PostgreSQL: порівняння підходів
Різниця між схемами видна не в спокійній роботі, а в момент відмови: скільки транзакцій втрачено і скільки часу база не приймає запис. Нижче — чотири варіанти, які ми розгортаємо на практиці, з обмеженнями, про які варто знати до впровадження, а не під час збою.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Потокова реплікація з гарячим резервом | Читання та звіти йдуть на репліки, допустима втрата останніх секунд даних | Перемикання робиться руками, є вікно недоступності на запис, відставання репліки переноситься на нового лідера |
| Синхронний резерв | Дані критичні: розрахунки, облік, обмін із зовнішніми системами | Зростає час підтвердження запису; при відвалі резерву потрібна політика — чекати чи продовжувати без синхронності |
| Керований кластер під нашим контролем | Потрібне автоматичне перемикання та налаштування параметрів під профіль навантаження | Потребує моніторингу, регулярних навчань з перемикання та дисципліни в оновленнях |
| Зовнішній керований сервіс | Своєї команди експлуатації немає, навантаження типове та передбачуване | Менше контролю над параметрами та розширеннями, переїзд до іншого постачальника дорогий |
Вибір визначається двома числами: допустимим часом недоступності та допустимим обсягом втрачених транзакцій. Там, де втрати неприпустимі, ми збираємо кластер з автоматичним перемиканням ролей (Patroni) і синхронним резервом, а гарячий резерв залишаємо під читання та звітність.
Етапи впровадження: аудит, схема, налаштування, перевірка, передача
Порядок робіт вибудуваний так, щоб кожне рішення перевірялося до продакшену: спочатку фіксуємо факти про поточний кластер, потім проєктуємо цільову схему, і лише потім щось змінюємо на бойових вузлах. Такий порядок знімає головний ризик — «поправили параметр, а наслідки побачили в момент аварії».
- Аудит конфігурації. Знімаємо параметри Patroni, параметри реплікації, схему розміщення вузлів за зонами доступності, поведінку пулера з'єднань і застосунків під час обриву зв'язку з мастером. На виході — перелік точок відмови та оцінка, який час недоступності кластер дає зараз.
- Проєктування схеми перемикання. Визначаємо кількість вузлів і кворум, режим синхронної реплікації, порядок вибору нового лідера, роль арбітра та цільове вікно перемикання. Фіксуємо, що відбувається з транзакціями, які не встигли доїхати до реплік.
- Складання стенда. Розгортаємо копію цільової топології, проганяємо навантаження та сценарії відмов. Тут же перевіряємо сумісність із поточними версіями застосунків і коректність рядків підключення.
- Налаштування на бойових вузлах. Вводимо вузли поетапно, з реплік на мастер, щоб у будь-який момент залишалася точка повернення. Налаштовуємо перевірки живості, таймаути, автоматичне відновлення відсталої репліки.
- Перевірка відмов. Вбиваємо мастер, рвемо мережу між зонами, сповільнюємо диск, вимикаємо вузол сховища станів — і дивимося, як кластер поводиться без втручання. Кожен сценарій повторюємо, доки результат не стане передбачуваним.
- Передача в експлуатацію. Віддаємо регламент планового перемикання, дашборди й оповіщення, порядок дій при втраті кворуму, інструкцію з повернення конфігурації до попереднього стану. Проводимо розбір з командою замовника на живому стенді.
Після передачі у команди є не лише працюючий кластер, а й розуміння, чому він влаштований саме так, — будь-яку зміну параметрів можна оцінити до того, як вона потрапить у бій.
Конфігурації, схеми перемикання та регламенти експлуатації
Після здачі у вашої команди залишається не набір усних домовленостей, а робочий комплект артефактів: конфігурації, схеми, політики та регламенти.
Кожен документ прив'язаний до конкретної дії чергового — за ним можна підняти кластер з нуля, провести планове перемикання або розібрати інцидент без автора налаштування на зв'язку.
- Конфігурації всіх вузлів — файли Patroni, параметри PostgreSQL, налаштування DCS: у репозиторії з історією змін, а не розкладені по серверах. Будь-яка правка проходить рев'ю та відкочується однією ревізією.
- Схема топології — які вузли, де синхронна репліка, які точки відмови є і що відбувається при втраті вузла або сховища стану.
- Політики доступу — ролі та права, розділення застосунку й адміністрування, порядок видачі доступів черговим та ротація облікових даних.
- Резервне копіювання — розклад повних та інкрементальних копій, глибина зберігання, безперервне архівування журналів і відмітка, до якої гарантовано відновлюємося.
- Регламент експлуатації — планове перемикання, вікна обслуговування, оновлення на репліках, дії при втраті вузла та критерії ескалації.
- Інструкції для чергових — покрокові сценарії з командами та перевірками: що черговий робить сам, а на якому кроці викликає інженера.
- Документація кластера — схема відновлення після збою, результати навчальних прогонів і журнал змін із відповідальним за кожну.
Комплект передаємо разом із навчаннями чергової зміни: два-три розбори на тестовому контурі, де перемикання роблять ваші інженери, а ми лише спостерігаємо.
Кейс: як ручне перемикання замінили автоматичним
Кластер із трьох вузлів жив на потоковій реплікації, але перемикання ролей залишалося ручним: черговий за інструкцією на дві сторінки піднімав репліку й переводив трафік.
Застосунок при цьому лежав — від сигналу моніторингу до повернення запису минало близько сорока хвилин, а за квартал набиралося п'ять-шість таких аварій, половина — вночі та у вихідні.
Ми перевели кластер на Patroni: він тримає стан у розподіленому сховищі, стежить за здоров'ям вузлів і сам призначає нового лідера, якщо поточний перестав відповідати. Застосунок ходить на віртуальну адресу, тому після перемикання рядок підключення змінювати не потрібно.
Метрики до та після
- Аварійні перемикання: 5-6 за квартал → 2-3, жодного нічного розбору.
- Час відновлення запису: близько сорока хвилин → менше хвилини.
- Хибні виклики чергового: скоротилися приблизно вдвічі.
Що змінилося в черговій зміні
Робота змістилася з «полагодити зараз» на «перевірити, що полагодилося»: черговий отримує повідомлення вже після переїзду ролі та розбирає причину в робочий час.
Регламент на дві сторінки замінили короткою перевіркою статусу та списком дій на випадок, коли автоматика не впоралася.
Одне зауваження: для вибору лідера потрібен кворум, тому вузли сховища стану рознесли за зонами доступності — інакше відмова одного сегмента вимикає всю логіку.
Чим автоматичний вибір лідера відрізняється від ручного перемикання?
Різниця в тому, хто приймає рішення про зміну ролі. При автоматичному виборі лідера це робить кворум вузлів: вони постійно підтверджують присутність одне одного, і як тільки основний вузол перестає відповідати, репліка підвищується сама. При ручному перемиканні рішення приймає інженер — за оповіщенням, за регламентом, за дзвінком.
Звідси головна різниця в ціні простою. Автоматика вкладається в секунди: вузол втрачає зв'язок, кворум фіксує це й передає роль.
Ручний сценарій включає час на спрацювання оповіщення, чергову зміну, доступи й саму команду — це десятки хвилин, увесь цей час запис у базу стоїть, а черга з'єднань зростає.
| Параметр | Автоматичний вибір лідера | Ручне перемикання |
|---|---|---|
| Хто приймає рішення | Кворум вузлів за більшістю | Інженер за оповіщенням |
| Час до відновлення запису | Секунди, без участі людини | Від хвилин, залежить від зміни та доступів |
| Розділення мережі | Без кворуму роль не підвищується, другий лідер не з'являється | Репліку можуть підняти у відрізаному сегменті — виходять два лідери й розходження даних |
| Повернення попереднього вузла | Добудовується за журналом і стає реплікою сам | Потрібен розбір і ручне звіряння |
| Поведінка застосунку | Перепідключення за часом очікування, повтор на нового лідера | Помилки запису на все вікно простою |
Розділення мережі — параметр, який найчастіше упускають у ручних схемах. Автоматика проєктується так, щоб вузол без кворуму не ставав лідером: коротка відмова запису краща, ніж два незалежні лідери й розбіжні дані, які потім доводиться зводити вручну.
Поведінка застосунку напряму залежить від того, як швидко база знову приймає запис. При автоматичному перемиканні клієнти перепідключаються за часом очікування та повторюють операцію на новому лідері.
При ручному застосунок зобов'язаний пережити довге вікно відмови, інакше з'являються втрачені замовлення та дублі.
Технічні сумніви: реплікація, перемикання, обслуговування
Сумніви на цьому етапі зводяться до чотирьох запитань: чи втрачаються останні транзакції під час аварії, на скільки зупиняється застосунок, як перевіряється відновлення і що робити з уже працюючим кластером.
Чи втратимо ми останні транзакції при перемиканні?
Залежить від режиму запису журналу. При синхронній реплікації підтвердження йде клієнту лише після приймання журналу реплікою — при падінні лідера втрати нульові. При асинхронній відкочується частина останніх підтверджених транзакцій. Режим підбираємо під профіль навантаження: платіжний контур — синхронно, звітність — асинхронно.
Чи зупиниться застосунок на час перемикання?
Перемикання лідера займає одиниці секунд. Довше триває перепідключення застосунку: без повторних спроб у пулі з'єднань простій розтягується до ручного втручання. Тому поряд із кластером налаштовуємо єдину точку підключення та параметри повторів.
Як ви перевіряєте резервні копії?
Копія, яку жодного разу не відновлювали, копією не вважається. Налаштовуємо безперервне архівування журналів транзакцій, відновлення на довільний момент і регулярну перевірку: розгортаємо кластер з копії повністю та заміряємо фактичний час відновлення. Окремо стежимо, щоб архівування не відставало мовчки.
У нас уже розгорнутий кластер — перебудовувати все заново?
Ні. Починаємо з аудиту: вузли й кворум, лаг реплік, режим синхронізації, стан копій. Далі правимо параметри, за потреби додаємо вузол-свідок і перевіряємо поведінку керованою відмовою. Кластер, зібраний скриптами вручну, переводимо під управління без зупинки сервісу.
Обговоримо задачу: повернемося з оцінкою та планом робіт
Щоб оцінка робіт спиралася на факти, а не на припущення, для старту достатньо кількох вихідних даних: схема розміщення вузлів, обсяги баз і профіль навантаження, вимоги до часу відновлення та допустимої втрати даних.
Якщо частина відомостей відсутня, інженери знімуть їх самі на вступному розборі — це один дзвінок, він не гальмує старт.
У відповідь надсилаємо комплект, за яким можна приймати рішення:
- Розбір поточної схеми: точки відмови, поведінка при перемиканні, вузькі місця за диском і реплікацією.
- План впровадження за етапами — з порядком робіт, залежностями та точками погодження етапів.
- Склад матеріалів, що передаються: конфігурації, схема кластера, регламенти перемикання та відновлення.
- Вимоги до середовища: вузли, дискова підсистема, мережа, доступи та сервісні облікові записи.
- План перевірок: сценарії відмов, які проганяємо до здачі, і критерії приймання за кожним.
- Оцінка робіт із розбивкою за етапами, щоб можна було запускати їх частинами.
Опишіть задачу й додайте те, що є з інфраструктури, — повернемося з оцінкою та планом робіт, а спірні місця розберемо на дзвінку.
