Налаштування PostgreSQL HA: де саме ламається відмовостійкість
Відмовостійкість бази даних не з'являється від того, що поруч з основним сервером поставили другий. Формально репліка є, потік змін іде, але команду на перемикання віддає черговий інженер — і все впирається в те, хто першим помітив проблему о четвертій ранку.
Налаштування PostgreSQL HA починається не зі встановлення пакетів, а з чесного переліку точок відмови кластера: що саме перестане працювати, якщо вузол вийде з ладу.
Падіння основного вузла рідко буває єдиною проблемою.
Порядок перемикання, кворум і керуючий вузол — такі самі точки відмови: за ручного перемикання вузла простій розтягується на час реакції чергового, а автоматика без узгодження ризикує тим, що два вузли одночасно оголосять себе головними. Розбіжні дані відновлювати довше, ніж перечекати саму відмову.
Третя точка — репліка, про яку ніхто не знає. Вона відстає за затримкою реплікації, на ній давно не вистачає місця під журнали, а готовність до підвищення ніхто не перевіряв. Поки основний тримається, цього не видно.
У годину пік падіння основного розкриває, що на резервному вузлі немає частини останніх змін, а привести його в робочий стан швидко не вдасться.
Розбираємо, як це закривається: узгодження замість ручного перемикання, регулярна перевірка придатності реплік до підвищення, контроль затримки та запасу місця під журнали — плюс інструмент на кшталт repmgr, який бере на себе перемикання ролей і веде історію змін топології кластера.
Що дає відмовостійкий PostgreSQL на практиці
Відмовостійкий кластер PostgreSQL змінює не стільки архітектуру, скільки характер експлуатації: перемикання на резервний вузол перестає бути аварійною нічною операцією.
repmgr стежить за станом вузлів і в разі втрати лідера піднімає репліку автоматично — застосунок повертається до роботи за десятки секунд, а не за десятки хвилин ручного розбору.
Клас усунених відмов — те, що раніше гарантовано зупиняло сервіс: падіння вузла, відмова диска, обрив зв'язку між майданчиками, завислий процес бази.
Кожен такий випадок вимагав ручного втручання; тепер типові сценарії закриває автоматика, а черговий отримує повідомлення вже за фактом відновлення.
Під навантаженням важливо не просто підняти резерв, а не втратити підтверджені транзакції.
Режим синхронної реплікації з кворумом зберігає їх мінімум на двох вузлах ціною невеликого зростання затримки запису; параметр підбирається під профіль навантаження, а читальні запити йдуть на репліки й розвантажують лідера.
Доступність бази даних стає вимірюваною часткою часу, а не обіцянкою. Арбітражний вузол захищає від розщеплення кластера під час розділення мережі, колишній лідер повертається в стрій без перезбирання, моніторинг показує відставання реплік та історію перемикань. Перевіряємо це тренуваннями: гасимо вузол під навантаженням і фіксуємо фактичний час відновлення.
Варіанти відмовостійкого кластера: порівняння режимів
Вибір схеми визначається не «бажанням надійності», а допустимим часом простою і тим, чи готовий бізнес втратити останні транзакції. Нижче — чотири схеми, між якими реально обирають, та їхня ціна в термінах перемикання й збереження даних.
Відмінності зводяться до трьох питань: де лежить копія, хто підтверджує запис і хто ухвалює рішення про перемикання.
Синхронна реплікація дає нульову втрату підтверджених транзакцій, але зростає час відповіді; асинхронна тримає швидкість, зате в разі відмови ведучого частина останніх записів може не дійти до резерву.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Один вузол + резервні копії | Невелике навантаження, простій у межах години допустимий | Відновлення — від хвилин до годин, точка втрати — момент останньої копії |
| Два вузли + вузол-арбітр | Потрібен автоматичний режим перемикання без ручного втручання | Арбітр дані не зберігає, він лише голосує: у разі розділення мережі можливий неправильний вибір |
| Синхронна реплікація | Втрата транзакцій неприпустима: платежі, склад, фінанси | Зростає затримка відповіді, у разі відмови резерву запис блокується або деградує |
| Асинхронна реплікація | Пріоритет — швидкість відгуку, втрата секунд даних прийнятна | Останні підтверджені записи можуть не дійти до резерву в разі відмови ведучого |
Схеми комбінують: синхронний резерв у сусідній зоні доступності плюс асинхронний — у віддалений центр. Вузол-арбітр дані не зберігає, він лише бере участь у голосуванні під час перемикання, тому під нього достатньо мінімальної машини — у repmgr це окрема роль вузла-свідка.
Порядок упровадження: аудит, схема, реплікація, перевірка
Кластер високої доступності — це не пакети, встановлені на кількох серверах, а послідовність перевірок, де кожен крок підтверджується фактом: роллю вузла, станом потоку реплікації, результатом перемикання. Нижче — порядок робіт, за яким ми йдемо.
- Аудит конфігурації бази. Дивимося версію та збірку, режим журналу попереднього запису, наявні репліки, стан резервних копій і профіль навантаження. На виході — перелік вузьких місць і рішень щодо топології.
- Проєктування топології. Визначаємо кількість вузлів, потребу в кворумному свідку, де допустима асинхронна реплікація, а де обов'язкова синхронна, і які відмови кластер має переживати без ручного втручання.
- Налаштування реплікації. Піднімаємо резервні вузли, вмикаємо потокову передачу журналу, задаємо політики підтвердження запису й ліміт відставання — втрата сервера не повинна означати втрату вже підтверджених даних.
- Автоматичне перемикання. Налаштовуємо repmgr: стеження за ролями, підвищення резервного вузла, захист від розщеплення в разі втрати зв'язку між майданчиками, метрики й оповіщення про лаг і зміну ролі.
- Перевірка перемикання. Виконуємо планове перемикання та імітацію аварії основного вузла, заміряємо час відновлення сервісу, звіряємо дані після підвищення репліки. Без цієї перевірки кластер не можна вважати готовим.
- Передача в експлуатацію. Віддаємо схему топології, регламент перемикань і оновлень, інструкцію для чергової зміни та порядок дій у нештатній ситуації — щоб черговий відрізняв штатний лаг від деградації без дзвінка інженеру.
Що передаємо на руки: конфігурації, схеми, регламенти
Артефакти передаємо в репозиторії, а не «на словах»: кожен файл версіонується, зміни проходять рев'ю, а розгортання відтворюється на чистому середовищі. Нижче — комплект, який закриває і повсякденну роботу, і нічний інцидент, коли черговий інженер уперше бачить кластер.
- Конфігурації вузлів: параметри PostgreSQL, керування перемиканням і таймаутів — окремо для основного та резервного вузла, з поясненням до кожного нестандартного значення.
- Схема кластера: топологія, ролі вузлів, порядок просування резерву, точки відмови та їхній зв'язок із мережевою сегментацією.
- Правила доступу: ролі та привілеї в базі, доступ до моніторингу й логів реплікації, порядок надання та відкликання прав.
- Регламент відновлення: покрокові сценарії перемикання в разі відмови основного вузла, повернення вузла в стрій і відновлення з резервної копії — з контрольними точками та очікуваним часом.
- Інструкція для чергової зміни: що перевіряти на початку зміни, яке відставання реплікації вважати тривожним, кому й як ескалювати.
- Карта моніторингу: які перевірки налаштовані, на що спрацьовує оповіщення, як відрізнити хибне спрацювання від реальної деградації.
- Протокол тренувань: план перевірки перемикання, журнал прогонів і результати — відмова не повинна перевірятися вперше в бою.
Документація живе разом із конфігурацією: якщо правило змінили в кластері, але не у файлі — це дефект, який закривається на рев'ю.
Як скоротили простій: заміри до та після на живому кластері
До: кожен збій будив чергового
Кластер із трьох вузлів жив на ручному перемиканні: майстер падав уночі, черговий інженер підключався, дивився журнали реплікації, піднімав репліку в режимі майстра, правив точки підключення в застосунку й лише потім перевіряв, що дані не розійшлися.
Відновлення займало від 40 до 70 хвилин, а в разі розсинхронізації копій розтягувалося до кількох годин — паралельно доводилося вручну звіряти відсталі записи.
Окрема ціна такої схеми — людський фактор. Порядок дій тримався в голові чергового та в інструкції на вікі; одна пропущена команда призводила до того, що застосунок ішов писати в старий майстер після його повернення.
Після: перемикання за десятки секунд
Ми поставили repmgr поверх потокової реплікації: менеджер стежить за станом вузлів, сам підвищує репліку до майстра й розсилає іншим нову топологію.
Застосунок підключається за рядком із переліком хостів і перепідключається на живий вузол без правки конфігурації та без перезапуску.
| Метрика | До | Після |
|---|---|---|
| Тривалість простою | 40–70 хвилин | 20–40 секунд |
| Збої, закриті без чергового | поодинокі | 9 із 10 |
| Втрата підтверджених записів | можлива | виключена |
Синхронна реплікація закрила залишковий ризик: транзакція вважається завершеною лише після підтвердження від копії, тому перемикання не відкочує вже прийняті замовлення.
Раз на квартал проводимо тренування — примусово гасимо майстер і звіряємо фактичний час перемикання з цільовим.
Що робити, якщо кластер уже розгорнуто на одній машині?
Наявний кластер на одній машині — це контур без репліки: відмова диска закривається відновленням із копії, тобто годинами недоступності.
Міграція без простою такого контуру можлива, але починати її з перемикання ролі не можна — спочатку будується другий вузол, і лише потім роль основного передається. Порядок робіт якраз і визначає, скільки сервіс стоїть на паузі.
Першим кроком — винесення репліки: на другому сервері розгортається копія вузла, вмикається потокова реплікація, вузол реєструється в repmgr як резервний. Основний продовжує приймати запис, ми стежимо за відставанням до нуля.
На третьому, найдешевшому вузлі піднімається арбітр: дані він не зберігає, але бере участь у голосуванні й не дає двом вузлам одночасно вважати себе головними в разі втрати зв'язку між ними.
Переведення на нову схему йде керованим перемиканням, а не аварійним. Резервний вузол тимчасово переводять у синхронний режим запису, дочікуються повної відсутності відставання й лише потім віддають йому роль основного.
Застосунок підключається через пул з'єднань або віртуальну адресу, тому розрив в обслуговуванні вимірюється секундами, а не хвилинами.
Далі колишній основний стає резервним, а в регламент додаються контроль відставання, резервне копіювання та планові тренування з перемикання — щоб наступна відмова відпрацьовувалася автоматично, без ручних рішень у момент аварії.
Технічні сумніви: реплікація, перемикання, відновлення
Сумніви на цьому етапі передбачувані: як поводитиметься репліка в разі розходження з майстром, хто ухвалює рішення в разі втрати зв'язку між вузлами, чим підтверджується працездатність перемикання.
Нижче — механізми, а не обіцянки: усе описане перевіряється на стенді до виведення кластера в робочий контур.
Репліка розійшлася з майстром — що тоді?
Вузол, що розійшовся, не підвищується до майстра: він позначається зламаним і виводиться з ротації. Повертаємо його через pg_rewind, а в разі глибокого розходження — перестворюємо з базової копії. Кластер увесь цей час працює на поточному майстрі.
Навіщо в кластері арбітр?
Третій вузол без даних бере участь у голосуванні й не дає двом вузлам одночасно вважати себе майстром у разі обриву зв'язку між ними. Без арбітра автоматичне підвищення за невизначеності вимикається, і рішення ухвалює інженер — це усвідомлений вибір, а не відмова.
Як переконатися, що перемикання спрацює?
Планове перемикання проганяємо на стенді: заміряємо час недоступності запису, дивимося, як застосунок відновлює з'єднання з новим майстром, розбираємо журнал реплікації. Потім перевіряємо повернення колишнього майстра в стрій і повторюємо прогін уже на реальному трафіку.
Репліка замінює резервну копію?
Ні: репліка повторює помилки майстра й не рятує від помилкового видалення даних. Тому тримаємо базові копії та архів журналів, а відновлення на окремому стенді відпрацьовуємо регулярно, а не в момент аварії.
Скільки простою займають планові роботи?
Перемикання на справну репліку — одиниці секунд недоступності запису, застосунок перепідключається сам. Оновлення та зміна налаштувань реплік ідуть по черзі, по одному вузлу, без зупинки сервісу.
Обговоримо задачу: схема, терміни, план упровадження
Щоб повернутися з оцінкою робіт і планом упровадження, нам потрібен зріз вашої конфігурації — не загальний опис, а конкретика щодо вузлів, навантаження та регламентів. Нижче список того, що дає максимальну точність розрахунку: якщо частини даних під рукою немає, відновимо разом.
- Поточна топологія: одиночний вузол, потокова реплікація, каскад або кластер під керуванням repmgr; кількість вузлів та їхнє розміщення.
- Обсяг бази, добовий приріст і профіль навантаження — частка запису, довгі транзакції, пікові вікна.
- Вимоги до збереження та часу відновлення: допустима втрата даних і цільовий час перемикання на репліку.
- Спосіб установлення й обслуговування: пакети з репозиторію, контейнери, ручне збирання; як оновлюєте мажорні версії.
- Мережеві сегменти, правила доступу, наявність пулу з'єднань і балансувальника перед базою.
- Моніторинг: що вже збирається, куди йдуть метрики, хто отримує сигнал про деградацію.
- Регламент обслуговування: вікна, хто має право ініціювати перемикання, чи є план відкатів.
Після обговорення задачі повернемося зі схемою кластера, покроковим планом упровадження, термінами робіт та оцінкою обсягу. Опишіть задачу — звіримо її з вашою інфраструктурою.
