Відмова головного вузла бази валить сервіс: Stolon у Kubernetes
Класична схема з одним головним вузлом PostgreSQL тримається на одному припущенні — що цей вузол живий. Поки він відповідає, запис іде, репліки наздоганяють потік.
Відмова головного вузла бази даних зупиняє не лише запис: частина читання теж зависає, застосунок чекає відповіді, таймаути складаються, з'єднання накопичуються і впираються в ліміт пулу.
Простій через базу даних вимірюється в цьому випадку не часом падіння вузла, а часом, за який хтось устигне відреагувати.
Далі вмикається ручне відновлення кластера СУБД. Черговий піднімає вузол, з'ясовує, яка з реплік найсвіжіша, змінює ролі, править точку входу та рядок підключення, повертає відсталу репліку в стрій.
Кожен крок — рішення людини під тиском, і на цьому вікні недоступності помилка коштує дорожче за саму аварію. Якщо застосунок устиг записати дані, а новий головний стартував з іншої репліки, розходження знімають вручну, звіряючи журнали.
Саме тут і міститься точка відмови PostgreSQL в одноузловій конфігурації: питання не в тому, чи впаде вузол, а в тому, скільки ми будемо підніматися і що втратимо дорогою.
Поки перемикання робить людина, вікно недоступності передбачувано розтягується, а обсяг втрачених записів залежить від того, як швидко відреагував черговий і наскільки свіжою виявилася вибрана репліка.
Stolon у Kubernetes знімає цю роботу з людей: він тримає кілька вузлів бази, стежить за станом головного, обирає нового за свіжістю даних і переводить трафік через окрему точку доступу.
Застосунок перепідключається за тією самою адресою, не чекаючи, поки інженер вручну поверне кластер у стрій. Нижче розбираємо, як це закривається і що залишається за межами автоматизації.
Що дає відмовостійкий кластер: вимірюваний ефект
Відмовостійкість починається з чесного заміру того, що відбувається зараз. Один екземпляр бази з ручним підйомом репліки дає вікно недоступності в десятки хвилин: інженер помічає збій, підтверджує, що справа не в мережі, піднімає вузол з резервної копії, перемикає трафік.
Кожне таке перемикання — операція під тиском, і саме на ній найчастіше ламається цілісність: два вузли вважають себе головними, частина запису йде в застарілу копію.
Stolon прибирає ручний крок із цього сценарію. Кластер тримає кворум керуючих компонентів, стан ролей зберігається в розподіленому сховищі конфігурації, а шар маршрутизації спрямовує підключення лише на підтверджений головний вузол.
Втрата провідного вузла запускає автоматичне перемикання ролей: репліка підвищується, маршрутизація перебудовується, застосунок перепідключається за тією самою адресою.
У вимірюваних величинах ефект виглядає так: вікно недоступності бази даних скорочується з десятків хвилин до одиниць секунд, частка автоматичних перемикань прямує до ста відсотків — і для планового обслуговування, і для раптової відмови, а кількість ручних втручань інженера падає до нуля на типових сценаріях.
Заодно йде цілий клас відмов: розходження реплік і запис у відсталий вузол більше не залежать від того, чи встиг хтось натиснути потрібну кнопку вночі.
Доступність сервісу перестає бути обіцянкою і стає перевірюваною величиною. Ми закладаємо в регламент контрольні навчання — кероване відключення вузла в робочий час, — щоб вимірювати час відновлення на живій системі, а не вірити в розрахункову оцінку.
Режими розгортання кластера: порівняння підходів
Відмовостійкість бази — не бінарний вибір «кластер чи не кластер», а спектр схем з різною ціною впровадження і різною поведінкою при збої. Нижче — варіанти, між якими реально обирають на старті проєкту, та їхні обмеження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Холодний резерв: регулярні дампи та відновлення на окремому вузлі | Невелике навантаження, простій у кілька годин допустимий | Відновлення рахується годинами, останні транзакції втрачаються безповоротно |
| Потокова реплікація з ручним перемиканням | Передбачуване навантаження, є черговий інженер | Перемикання залежить від людини, вікно простою розтягується на реакцію чергового |
| Кластер під управлінням Stolon у Kubernetes | Потрібна автоматична відмова та самовідновлення ролей | Потребує коректного кворуму й дисципліни в оновленнях, налагодження складніше, ніж в одиночного вузла |
| Керований кластер СУБД у провайдера | Своєї команди експлуатації немає | Менше контролю над версіями, розширеннями та параметрами ядра, прив'язка до майданчика |
Головна відмінність — хто ухвалює рішення про перемикання. У перших двох схемах це людина, в кластері під управлінням автоматики — сам сервіс: він стежить за станом вузлів і змінює ролі без участі оператора.
Обмеження реплікації при цьому спільні для всіх варіантів: потокова передача за замовчуванням асинхронна, тому частина останніх підтверджених записів може не дійти до резерву, а затримка резерву безпосередньо впливає на час відновлення.
Вибір зводиться до двох питань: скільки простою ви готові витримати і скільки останніх записів допустимо втратити. Відповіді на них і визначають, чи потрібна взагалі автоматична відмова або достатньо холодного резерву з зрозумілим регламентом відновлення.
Впровадження Stolon у Kubernetes: етапи інженерної роботи
Відмовостійкість кластера СУБД у Kubernetes не можна дописати після запуску — її проєктують разом із топологією, сховищем і схемою підключення застосунків.
Нижче — послідовність робіт із впровадження Stolon у Kubernetes: від аудиту поточної схеми до передачі кластера в експлуатацію з протоколом перевірок.
- Аудит схеми та навантаження. Розбираємо, як застосунок підключається до бази — через проксі, пул з'єднань чи напряму, який профіль запитів та обсяги, де зараз єдина точка відмови.
- Проєктування відмовостійкої схеми. Визначаємо кількість реплік, розкладку за зонами доступності, кворум для вибору лідера, режим синхронної реплікації та цільовий час перемикання.
- Складання конфігурації. Розгортаємо keeper-вузли як набір із постійними томами, sentinel для контролю стану та перевиборів лідера, роздільні адреси для запису й читання.
- Сховище та резервні копії. Підбираємо класи дисків, налаштовуємо регулярні копії в об'єктне сховище та перевіряємо відновлення на окремому стенді.
- Перевірка відмовами. Вбиваємо лідера, відключаємо зону доступності, рвемо зв'язок зі сховищем стану кластера — фіксуємо час перемикання і переконуємося, що застосунки перепідключаються без ручних дій.
- Передача в експлуатацію. Регламент чергування, оповіщення про відсутність лідера та відставання реплік, сценарії планового обслуговування, навчання команди замовника.
На виході — передбачуваний час відновлення після відмови вузла або зони, відсутність ручних перемикань і зрозумілий набір дій для чергової зміни.
Що передаємо на руки: конфігурації, схеми, регламенти
Кластер, який працює, але зрозумілий лише тим, хто його збирав, — це відкладений простій. Тому передача на руки — не архів файлів, а комплект, за яким ваш інженер сам підніме репліку, проведе планове перемикання і повернеться до попереднього стану без нашої допомоги.
- Схема відмовостійкості — топологія та ролі вузлів, точки відмови, поведінка кластера при втраті майстра або зони, порядок вибору нового лідера.
- Конфігурації кластера — маніфести та параметри середовищ у репозиторії, ресурси й ліміти, правила розміщення подів, окремі профілі для бойового та тестового контурів.
- Політики доступу до бази — ролі застосунків, адміністраторів і службових сервісів, володіння схемами, порядок видачі та відкликання прав, ротація облікових даних, зберігання секретів.
- Регламент резервного копіювання — розклад повних та інкрементальних копій, глибина зберігання, вивантаження за межі кластера, перевірка відновлення за розкладом.
- Документація на кластер СУБД — покрокові сценарії на планові операції та аварійні ситуації, порядок ручного втручання, межі відповідальності.
- Моніторинг та оповіщення — які метрики дивимося, за яких порогів піднімається тривога і що робити в перші хвилини за кожним сигналом.
Віддаємо не посиланням на репозиторій, а розбором на тестовому контурі: показуємо відмову вузла, перемикання та відновлення з копії, потім ваші інженери повторюють це самі.
Після цього в команди залишається одне джерело правди щодо кластера, і звертатися до нас потрібно лише на зміну архітектури або розширення.
Кейс: як кластер пережив відмову вузла без ручних дій
До впровадження кластер тримався на одному вузлі-майстрі: при його відмові застосунок ловив помилки підключення, а репліку піднімали вручну — інженер підключався, перевіряв відставання і переводив трафік.
Це займало від двадцяти хвилин до півгодини, і щоразу залишався ризик вивести в майстер репліку з незакритим відставанням і втратити останні транзакції.
Ми розгорнули Stolon поверх Kubernetes: на кожному вузлі працює хранитель стану, окремі спостерігачі стежать за здоров'ям майстра, а точка входу для застосунків перенаправляє трафік за рішенням кворуму.
Підвищення запускається саме, щойно майстер перестає відповідати, — людина у схемі більше не бере участі.
Що підтверджують метрики
Перемикання вкладається в десятки секунд, ручних втручань за квартал — нуль, відставання реплік утримується в межах, за яких підтверджені транзакції не втрачаються. Простій при відмові вузла скоротився з півгодини до часу, який застосунок спокійно переживає на повторах запитів.
Перед виводом у бойовий контур ми прогнали сценарії в навантажувальному контурі: гасили вузол з майстром, вузол зі спостерігачами, розривали зв'язок зі сховищем стану і заміряли, скільки тримається простій.
Кожен прогін давав зрозумілу межу відмовостійкості — скільки вузлів кластер переживає без втрати даних і на якому сценарії все-таки потрібне втручання.
Що робити, якщо база вже розгорнута на одному вузлі?
Розгорнутий одиночний вузол не потрібно зносити й піднімати кластер з нуля — перехід робиться на живому сервісі. Спочатку поруч піднімається репліка, яка наздоганяє основний вузол за потоком змін, і лише після цього змінюються ролі.
Зупинка потрібна лише на момент зміни точки входу, а не на всю міграцію: вікно вимірюється хвилинами, а не годинами простою.
Порядок переходу такий: зняти узгоджений знімок стану та зафіксувати поточні параметри, розгорнути репліку й дочекатися нульового відставання, перевести її в режим основного вузла, переконатися, що колишній вузол залишається читабельним і синхронним.
Останній крок — переведення застосунку на ім'я сервісу замість прямої адреси конкретного пода. Такий план переходу фіксується до початку робіт, щоб кожен крок був перевірюваним і перериваним.
Ключова умова безшовності — застосунок уже звертається до бази за іменем сервісу, а не за прямим посиланням на вузол. Тоді зміна ролі в Stolon у Kubernetes — це перемикання на іншу копію за секунди, без правок конфігурації сервісу і без його перезапуску.
Якщо застосунок усе ще тримає пряму адресу, цей момент закривається першим — до того, як ми почнемо чіпати ролі.
Зворотний відкат проєктується заздалегідь: колишній вузол залишається в строю як резерв, знімок стану зберігається до кінця періоду спостереження, а правила повернення описані покроково для чергового.
Якщо після перемикання випливають розходження, сервіс повертається на колишній вузол тим самим способом — зміною ролі та адреси. Ми розбираємо конкретну конфігурацію і пропонуємо план переходу під ваш режим роботи.
Інженерні сумніви, які знімаємо до старту
Перед стартом лунає той самий набір питань: що буде із записом при розщепленні кластера, яка реплікація потрібна цій базі, як оновлювати її без простою, чи вбудується рішення в поточний контур і хто відповідає за інцидент. Відповідаємо прямо, до початку робіт.
Як Stolon захищає від розщеплення кластера?
Майстер обирається через консенсус-сховище, а не «хто відповів першим». Вузол, який втратив із ним зв'язок, перестає бути майстром і закриває прийом запису — двох конкуруючих майстрів не виникає.
Синхронна чи асинхронна реплікація?
Синхронна виключає втрату підтверджених транзакцій, але прив'язує запис до кількості живих реплік. Асинхронна спокійніше переносить втрату вузлів, зате на перемиканні губляться останні підтвердження. Вибір фіксуємо за профілем навантаження та допустимим вікном втрати.
Що із сумісністю з поточним контуром?
Звіряємо версію та розширення бази, клас сховища, мережеві доступи, моніторинг і резервне копіювання. Якщо щось у контурі не переживає зміну ролі майстра — говоримо одразу, а не на викаті.
Як обслуговувати кластер СУБД без зупинки?
Планове перемикання, оновлення мажорної версії та накат параметрів ідуть хвилею: спочатку репліки, потім майстер. База приймає запис усю процедуру.
Хто відповідає за підтримку після запуску?
На нашій стороні — конфігурація, автоматика перемикань і схема резервування; на стороні замовника — доступи, ресурси платформи та зміни застосунків. Межу фіксуємо письмово до старту.
Обговоримо задачу: що потрібно від вас і що робимо ми
Щоб повернутися з оцінкою та планом робіт, а не із загальними формулюваннями, нам потрібен зріз вашої інфраструктури. За ним ми рахуємо склад кластера, точки відмови та строки впровадження — і віддаємо це одним документом, який можна захищати перед командою.
- поточна схема: один вузол або реплікація вручну, де живе майстер, як застосунки перемикаються при збої;
- склад кластера: кількість екземплярів бази, обсяг даних, добовий приріст і співвідношення читання до запису;
- платформа: версія Kubernetes, наявність кількох зон доступності, як видаються постійні томи;
- мережа та доступи: як застосунки знаходять актуальний майстер, чи є проксі-шар, які політики мережі діють;
- вимоги до відмовостійкості: допустимий час недоступності запису й читання, чи потрібен автоматичний відкат;
- вікна робіт: коли можна перемикати промисловий контур, чи є тестовий контур і набір даних, близький до реального;
- спостережуваність: куди збираються метрики та логи, які оповіщення вже налаштовані.
Цього достатньо, щоб запропонувати конкретну схему: скільки екземплярів бази, де розміщувати майстер і репліки, як застосунки знаходять нового майстра після перемикання. Далі розгортаємо Stolon і описуємо порядок перенесення даних без тривалої зупинки запису.
План робіт розбитий на етапи: підготовка контурів, розгортання, перенесення, відпрацювання перемикання та виведення в промислову експлуатацію. Для кожного етапу фіксуємо, що робимо ми і що потрібно від вашої команди, — і лише після цього називаємо строки впровадження. Опишіть задачу — повернемося з оцінкою та планом.
