Налаштування Yandex Managed PostgreSQL: типові відмови кластера
Кластер на керованому сервісі рідко падає через нестачу ресурсів — частіше його валить конфігурація за замовчуванням, знята з тестового стенда.
Налаштування Yandex Managed PostgreSQL під продакшн починається з того, що ліміти з'єднань, таймаути, політика автоочищення та поведінка реплік задаються під конкретний профіль навантаження, а не «як у всіх».
Переповнення з'єднань — перша за частотою відмова. Застосунок відкриває з'єднання на кожен робочий потік, на піку їхня кількість перевищує max_connections, і сервер починає відхиляти нових клієнтів.
Застосунок отримує помилку підключення, вбудовані повтори добивають кластер ще сильніше — замість розвантаження виходить лавина.
Другий сценарій — черга запитів під навантаженням. Без ліміту на тривалість запиту й транзакції один важкий звіт тримає блокування, решта запитів вишиковуються в чергу й чекають звільнення.
Ззовні це виглядає як «сайт гальмує», усередині — зростаючий час очікування й деградація кластера на кожному сплеску.
Третій — відставання репліки та переповнення тому. Поки репліка не встигає застосовувати журнал змін, зростає обсяг незавершених даних: під час відмови основного вузла частина підтверджених операцій втрачається.
Паралельно журнал і мертві рядки з'їдають диск, автоочищення не встигає за оновленнями, і на заповненому томі кластер переходить у режим лише читання — запис зупиняється.
Усі збої видно заздалегідь за метриками, але зазвичай не там, де їх шукають. Розбираємо, як це закривається налаштуванням.
Що дає правильно зібраний кластер: ефект у вимірюваних цифрах
Кластер під продакшн відрізняється від навчального не довжиною списку параметрів, а передбачуваністю: під навантаженням він поводиться так само, як на стенді.
Керований сервіс Yandex Managed PostgreSQL бере на себе залізо й платформу, але топологію, ліміти з'єднань, термін зберігання резервних копій і правила перемикання під час збою обирає інженер — від цих рішень і залежать цифри нижче.
За схеми із синхронною реплікою в іншій зоні перемикання на резервний вузол укладається в десятки секунд і не втрачає підтверджені транзакції. Без неї відмова вузла означає відновлення з копії: години простою та втрата останніх записів.
Різниця між цими сценаріями і є вимірюваний ефект налаштування — час відновлення після збою скорочується на порядок.
Зникає й цілий клас відмов, пов'язаних з вичерпанням з'єднань. Пул перед базою разом з обмеженням паралельних запитів на боці застосунку тримає пік: у момент напливу трафіку запити чекають у черзі, а не отримують відмову.
Частка відхилених з'єднань падає з відсотків до часток відсотка, і застосунок перестає віддавати помилки саме тоді, коли навантаження максимальне.
Пікове навантаження перестає бути лотереєю: ліміти ресурсів, репліки для читання й автомасштабування диска задають межі, за які кластер не виходить.
У звіті це видно як чотири перевірювані величини — час відновлення, частка відхилених з'єднань, тривалість простою за період і кількість інцидентів класу, що зник.
Варіанти розгортання та відмовостійкості PostgreSQL
Схема розгортання — це вибір класу відмов, який ви згодні прийняти, а не лише питання продуктивності. Керований кластер Yandex бере на себе резервне копіювання та перемикання ролі, але доступність зони й розвантаження читання він за вас не вирішує — це питання конфігурації.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Один вузол керованого кластера | Внутрішні сервіси, стенди, навантаження без вимог до безперервності | Зупинка вузла — простій на час відновлення; немає розвантаження читання, звіти конкурують із бойовими запитами |
| Основний вузол + репліка читання | Читання переважає над записом, потрібне швидке повернення до останньої стабільної точки | Реплікація асинхронна: під час перемикання втрачається останній відрізок транзакцій; помилка в коді поширюється на репліку теж |
| Міжзональне розміщення | Сервіс критичний, потрібно пережити відмову зони без ручного втручання | Затримка запису вища — помітно на частих дрібних транзакціях; резервування ресурсів дорожче |
| Окремий контур під аналітику | Важкі вибірки та вивантаження заважають продакшну | Дані відстають, потрібна власна схема передачі та контроль розсинхронізації |
Окремо перевіряємо обмеження схеми: доступні розширення, розбиття великих таблиць на партиції, права на рівні рядків і те, хто володіє об'єктами під час перемикання.
Резервне копіювання налаштовуємо з відновленням на довільну точку в часі й раз на квартал розгортаємо копію в окремий контур — копія, яку жодного разу не відновлювали, робочою не вважається.
Порядок робіт: від аудиту навантаження до передачі регламентів
Managed-кластер не стає продуктивним від факту розгортання: хмара закриває доступність заліза та обслуговування рушія, але не захищає від блокувань, переповнення пулу з'єднань і окремих запитів, які кладуть базу під реальним трафіком.
Роботи йдемо від вимірювань до змін — для PostgreSQL, MySQL і MongoDB послідовність одна, різняться метрики та набір параметрів.
- Аудит навантаження — знімаємо статистику за характерний період: пікові години, кількість з'єднань, швидкість зростання таблиць, очікування за блокуваннями.
- Профіль запитів — витягуємо топ за сумарним часом і частотою, знаходимо звернення без індексів і запити до великих таблиць.
- Схема та індекси — перебудовуємо гарячі таблиці, прибираємо дублювальні індекси; кожну зміну проганяємо на копії даних і порівнюємо план виконання до і після.
- Налаштування параметрів — приводимо ліміти пам'яті, журналу, таймаути та розмір пулу з'єднань до виміряного профілю, а не до типових значень за замовчуванням.
- Перевірка перемикання — примусово переводимо роль на репліку й заміряємо час недоступності та обсяг втрачених транзакцій.
- Резервне копіювання та відновлення — перевіряємо не факт наявності копій, а відновлення на окремому контурі до потрібної точки.
- Передача регламентів — опис конфігурації, схема відмовостійкості, пороги оповіщень і порядок типових операцій: підвищення ролі, розширення диска, міграція схеми.
Після здачі зміни вносяться за описаною процедурою, а не «руками» в панелі: конфігурація залишається відтворюваною, а інцидент розбирається за метриками.
Що залишається у вас: конфігурації, схеми, доступи, регламенти
Ми не залишаємо результат у листуванні та в голові одного інженера.
Усе, що зроблено під час налаштування Yandex Managed PostgreSQL, зафіксовано в артефактах: їх можна передати новій команді, покласти в систему контролю версій і застосувати повторно під час наступної розкатки або перенесення середовища.
- Файли конфігурації. Кластер, репліки, групи параметрів, розклад резервних копій і правила автомасштабування описані декларативно — повторна розкатка не збирається заново з пам'яті.
- Схема розміщення. Зони доступності, підмережі, точки підключення застосунків і шлях трафіку до бази: видно, де проходить межа відмовостійкості та що станеться під час втрати зони.
- Політики доступу. Ролі бази, розмежування прав за сервісами, мережеві правила, порядок видачі та ротації облікових даних, окремий контур для читання й аналітики.
- Регламент експлуатації. Оновлення мінорних версій, перевірка відновлення з копії, обслуговування індексів і статистики, дії чергового під час деградації.
- Документація. Паспорт кластера, карта підключень, інструкції щодо типових інцидентів і порядок відкату на попередню версію схеми.
- Моніторинг та оповіщення. Метрики за навантаженням, з'єднаннями та відставанням реплік, пороги спрацювання й адресати повідомлень.
Для MySQL і MongoDB набір той самий — змінюються лише групи параметрів і спосіб реплікації.
Кейс: кластер під пікове навантаження після переїзду
Кластер Yandex Managed PostgreSQL замовник підняв під переїзд контуру: дані перенесли, але параметри залишилися від тестового стенда, а всі з'єднання застосунку йшли в один вузол.
На вечірньому піку відгук на запис сягав понад секунду, репліка відставала, фонові завдання падали за таймаутом і піднімалися руками.
Точка відліку
Перед перебудовою ми зафіксували цифри: п'ять-сім ручних втручань на тиждень, відставання репліки до 40 секунд, 1,8 секунди на 95-му процентилі запитів і відмова сервісу, коли кількість з'єднань перевищувала тисячу.
Причина була не в навантаженні, а в схемі: один читальний вузол, налаштування автоочищення за замовчуванням і відсутність лімітів на з'єднання.
Що змінили
Розвели потоки: запис — на основний вузол, звіти та вивантаження — на окремі репліки, з'єднання застосунку обмежили за кількістю та часом життя. Автоочищення налаштували за фактом зміни рядків, додали індекси під важкі вибірки, пороги оповіщень прив'язали до відставання репліки. Перемикання під час відмови вузла перестало бути ручною операцією.
Що вийшло
Відставання репліки тримається в межах секунди, відгук на 95-му процентилі — 0,2 секунди, ручних втручань за три місяці — нуль.
Піковий профіль зріс утричі, і кластер не впирається в стелю: запас за з'єднаннями та запитами видно на графіках заздалегідь, до того як користувачі помітять уповільнення.
Чим керований кластер відрізняється від самостійного складання?
Керований сервіс забирає на себе шар експлуатації: розгортання та первинне налаштування, реплікацію, резервне копіювання, оновлення мінорних версій, заміну вузла, що вийшов з ладу, збір базових метрик.
Межа відповідальності проходить за платформою та обладнанням — провайдер відповідає за доступність кластера та цілісність реплік. Такий варіант (Yandex Managed PostgreSQL) знімає з команди роботу, яка не створює продукту цінності.
Зона відповідальності команди починається вище: схема даних, індекси, параметри СУБД, пул з'єднань, права ролей, регламент міграцій. Окремо — перевірка відновлення з резервної копії на ізольованому контурі: без неї сама наявність копій нічого не гарантує.
Самостійне встановлення залишає на нас усе перелічене плюс експлуатацію, зате дає повний контроль над версією та налаштуваннями.
Обслуговування без простою влаштовано схоже, але коштує по-різному. Платформа оновлює вузли по черзі та переводить трафік на репліку автоматично; під час самостійного складання ту саму операцію виконує черговий за заздалегідь написаним регламентом. Різниця проявляється не в спокійний день, а в момент відмови вузла вночі або в розпал навантаження.
Самостійне складання виграє там, де потрібні нештатні розширення, специфічні збірки або жорсткі вимоги до ізоляції та розміщення поруч із застосунком. Керований сервіс — там, де важливіше передбачуване обслуговування та виведення продукту без власної чергової зміни.
Вибір іде за межею відповідальності: що команда готова тримати на собі, а що вигідніше віддати платформі.
Часті технічні сумніви інженерних команд
Команди приходять з одним і тим самим набором сумнівів: чи можна чіпати вже працюючий кластер, як розмежувати права доступу до даних і де та точка, після якої контроль відновлення перестає бути формальністю.
Ми налаштовуємо Yandex Managed PostgreSQL і відповідаємо про поведінку під навантаженням, а не про теорію.
У нас уже запущений кластер — його доведеться перезбирати?
Ні. Спочатку інвентаризація: які бази та ролі задіяні, як налаштовані копії, які запити дають пік. Правки вносимо по одній і перевіряємо на репліці — бойовий трафік не переривається.
Як ви розмежовуєте права доступу до даних?
Ролі описуємо під задачі: застосунок пише лише у свою схему, аналітика читає, міграції йдуть окремим обліковим записом. Права мінімальні для кожної ролі — компрометація ключа застосунку не відкриває весь кластер.
Як зрозуміти, що відновлення спрацює?
Контроль відновлення — це навчання, а не позначка в панелі. Розгортаємо копію в окремому контурі, звіряємо цілісність і заміряємо час підйому. Якщо копія не піднімається, дізнаємося про це на навчаннях, а не в момент аварії.
Чи впливають параметри на поведінку в пік?
Так, і сильніше, ніж здається. Налаштування пам'яті, кількості з'єднань і запису журналу визначають, як база тримає пік. Підбираємо їх під профіль навантаження і змінюємо по одному — ефект видно в метриках.
Що отримує наша команда?
Передачу знань: показуємо, де змінювати ролі, як читати метрики і що робити під час деградації. Далі команда обслуговує кластер сама і розуміє, коли кличе нас.
Обговоримо задачу і повернемося з оцінкою та планом
Оцінка за інфраструктурою не буває точною «на око»: різниця між тестовим контуром і бойовим PostgreSQL у керованому сервісі — це реплікація, резервне копіювання за розкладом, відмовостійка конфігурація та розділення ролей доступу.
Тому ми спочатку збираємо вихідні дані, а вже потім повертаємося з планом і строками, а не з вилкою «від і до».
Що потрібно від вас, щоб обговорити задачу предметно:
- Перелік баз та їхнє призначення: які контури обслуговуються, які запити переважають — транзакційні чи аналітичні.
- Профіль навантаження: пікові значення за підключеннями та операціями, на які години вони припадають.
- Поточна схема розміщення: де живуть бази зараз, як застосунки встановлюють з'єднання, чи є проміжні шари на кшталт пулера.
- Вимоги до доступності та відновлення: допустиме вікно простою, глибина зберігання копій, цільовий час підйому після збою.
- Правила доступу: як видаються права застосункам і адміністраторам, чи потрібна ізоляція мереж і журналювання дій.
- Обсяг даних і динаміка зростання — за ними рахуємо розмір інстансів і політику зберігання.
- Відповідальний з вашого боку, хто підтверджує зміни в бойовому контурі.
Повертаємося з оцінкою та планом: схемою розміщення з обґрунтуванням обраної конфігурації, переліком робіт з налаштування та перенесення, розбивкою строків робіт за етапами та точками, де потрібні ваші погодження. Після цього старт робіт займає один погоджений інтервал.
