Мажорне оновлення PostgreSQL: де ламається прод
Перехід на нову мажорну гілку — це не оновлення пакета, а зміна внутрішнього формату каталогу: новий сервер фізично не читає файли даних попередньої гілки, і підняти на ньому старий кластер неможливо.
Тому мажорне оновлення PostgreSQL завжди йде окремою процедурою — з підготовкою, прогоном на копії та розділенням «оновили збірку» і «перемкнули прод». Відкат через пакетний менеджер тут не працює: серверні файли повернуться, дані — ні.
Перше, що рветься, — розширення. Частина вимагає перезбирання під нову гілку, частина змінює набір типів, функцій та операторів, а індекси поверх користувацьких типів після перенесення можуть виявитися невалідними.
Помилки після перемикання проявляються не на старті, а на конкретних запитах: не знаходиться оператор, приведення типів переходить у виняток, агрегат повертає інше значення. Тому сумісність розширень перевіряють до вікна, а не всередині нього.
Друге джерело тихих відмов — параметри конфігурації під час переходу. Частину директив видалено, частину перейменовано, частина зберегла назву, але змінила сенс або значення за замовчуванням.
Сервер підніметься, а план запиту, оцінка вартості та поведінка збирача сміття будуть іншими — диск зростає без жодного рядка в лозі.
І головний обмежувач — вікно недоступності бази. Оновлення із зупинкою вкладається в хвилини, але вимагає повного простою і не залишає місця для другої спроби. Перехід через логічну реплікацію простою майже не дає, зате розтягує підготовку і вимагає явного звіряння розбіжностей. Далі розбираємо, як це закривається на практиці.
Що змінюється після переходу на нову мажорну гілку
Керований перехід на нову мажорну гілку дає ефект не в списку нововведень, а в знятих обмеженнях.
Планувальник і зберігання в новій гілці обслуговують запити, які на попередній упиралися в стелю: паралельні операції над великими таблицями, секціонування без ручних тригерів, індекси без періодичного перезбирання.
Час недоступності сервісу зводиться до моменту перемикання — перевірка сумісності та прогрів ідуть на репліці заздалегідь.
Усунений клас відмов відчувається найсильніше. Обхідні рішення живуть за розкладом: перезапуск за регламентом, ручне чищення роздуття, стеження за розміром каталогів. Такі задачі не падають гучно — їх тихо пропускають, і тоді база деградує до аварії. Після переходу ці операції виконує сама PostgreSQL, а вікна регламентних робіт скорочуються.
Передбачуваний відкат проєктують до перемикання. Попередній кластер залишається ведучим, зміни йдуть на нову гілку потоком, а зворотний хід — повернення маршруту застосунків на попередній вузол, а не відновлення з архіву.
План репетирують на копії: якщо після перемикання розходяться плани запитів або падає швидкість конкретної вибірки, повернення займає хвилини.
На виході — кластер на єдиній гілці: репліки, правила перемикання та оновлення безпеки одного рівня, без зоопарку версій. Ефект від оновлення вимірюють до і після: час відгуку ключових вибірок, кількість регламентних втручань, час відновлення при відмові вузла.
Способи оновлення: порівняння режимів і обмежень
Мажорне оновлення PostgreSQL змінює формат каталогу даних, тому спосіб переходу обирають за трьома вимірами: допустиме вікно простою, обсяг бази та наявність несумісних об'єктів — розширень, типів, процедурних мов.
Універсального варіанта немає, і на практиці їх комбінують: наприклад, спочатку переносять утилітою, а об'єкти, що не збіглися, доздають вручну.
Перенесення утилітою оновлює каталог даних на місці та переносить файли напряму, тому простій вимірюється хвилинами навіть на великій базі. Плата — запас диска під обидва каталоги та збіг кодування з розрядністю.
Логічна реплікація між версіями розгортає цільовий сервер нової гілки поряд і переливає зміни на ходу: простій скорочується до перемикання трафіку, але об'єкти поза публікацією, послідовності та права переносять окремо.
Дамп і відновлення залишається найпередбачуванішим шляхом, коли заодно перебудовують схему або змінюють платформу, — ціною повного простою на вивантаження та завантаження.
Паралельний кластер піднімають на окремому вузлі, переводять туди навантаження і залишають старий як точку відкату, сплачуючи другим набором ресурсів.
Обмеження способів переходу зводяться до однієї розвилки: або коротке вікно і жорсткі вимоги до сумісності, або керований перевід з ручним доопрацюванням.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Перенесення утилітою | Велика база, коротке вікно, сумісні розширення | Потрібен запас диска, збіг кодування та розрядності |
| Логічна реплікація між версіями | Сервіс не можна зупиняти, перевід поетапний | Ручне перенесення об'єктів поза публікацією та прав |
| Дамп і відновлення | Зміна платформи, перебудова схеми | Простій на все вивантаження і завантаження |
| Паралельний кластер | Потрібен безпечний відкат і ізоляція | Подвійні ресурси, синхронізація прав і послідовностей |
Порядок робіт: від аудиту сумісності до перемикання
Мажорне оновлення PostgreSQL — не одна команда pg_upgrade, а послідовність, де кожен крок знімає конкретний ризик.
Між гілками змінюються каталоги системних таблиць, поведінка за замовчуванням і вимоги до розширень, тому йдемо від інвентаризації до регламенту відкату, який залишається напоготові до кінця робіт.
-
Інвентаризація об'єктів. Збираємо перелік баз, схем, розширень, користувацьких типів, тригерів, правил і повнотекстових конфігурацій. Окремо фіксуємо кодування, локаль, власників і права — те, що найчастіше губиться під час перенесення.
-
Аудит сумісності. Звіряємо об'єкти з цільовою гілкою: що підтримується, що вимагає оновлення розширення, що видалено. На виході — список правок у схемі та запитах, які вносимо до перемикання, а не після.
-
Тестовий прогін на копії. Розгортаємо копію кластера з тим самим обсягом даних і схожим профілем навантаження та проганяємо оновлення повністю: отримуємо реальну оцінку вікна простою і заздалегідь бачимо проблеми розширень.
-
Налаштування та контроль цілісності. Переносимо параметри, перезбираємо статистику, перевіряємо фонове очищення, плани важких запитів і реплікацію. Звіряємо кількість рядків у ключових таблицях, послідовності та права доступу.
-
План перемикання. Розписуємо кроки: зупинка запису, режим лише читання, фінальна синхронізація, зміна точки підключення застосунків, зняття обмежень — з відповідальним і оцінкою часу на кожному.
-
Регламент відкату та передача. Старий каталог і репліку тримаємо недоторканими до підтвердження результату, критерії повернення фіксуємо заздалегідь і перевіряємо зворотний шлях на копії. Після — документація та спостереження за новою гілкою.
Що залишається на руках: конфігурації, схеми, регламенти
Після оновлення у замовника залишається не лише робоча база, а й комплект артефактів, за якими її можна вести далі — своїми силами або з нашою допомогою.
Передаємо їх у репозиторій з історією змін, а не в листування і не в нотатки одного інженера: наступний фахівець відновлює картину без усних пояснень.
- Конфігурації кластера — робочі файли налаштувань із помітками, чому вибрано такі розміри буферів, таймаути та режим журналу, і що змінювалося під навантаження.
- Схема реплікації — топологія вузлів, їхні ролі, порядок перемикання та допустиме відставання реплік.
- Політики доступу та ролі — матриця прав, власники об'єктів і розширень, підтвердження, що привілеї перенеслися без втрат.
- Скрипти звіряння та відкату — запити для порівняння кількості рядків і контрольних сум ключових таблиць до і після, плюс порядок повернення на попередню версію.
- Документація щодо бази — карта об'єктів, залежності застосунків від типів і розширень, вузькі місця, що випливли під час перенесення.
- Регламент оновлення — покроковий порядок: підготовка, прогін на копії бойового обсягу, зупинка запису, перенесення, перевірки, включення трафіку — з вікном робіт і критеріями зупинки.
Такий комплект перетворює разове оновлення на відтворювану процедуру: наступна мажорна версія проходить уже перевіреним маршрутом, а не починається з нуля.
Кейс: перехід без тривалого простою і з швидким відкатом
Кластер обслуговував вітрини та чергу фонових задач, тому блокування запису на кілька годин означало зупинку приймання даних.
На минулому переході між мажорними версіями PostgreSQL недоступність розтяглася майже на чотири години, а частину об'єктів довелося перестворювати вручну вже після запуску — помилки в них випливали в першу добу.
| Метрика | До | Після |
|---|---|---|
| Недоступність на запис | 3 год 40 хв | 40–50 с на перемикання |
| Інциденти в перші два тижні | 7, з них 2 з втратою частини записів | 0 |
| Повернення на попередню версію | близько 2 год, відновлення з копії | 3–5 хв, зворотною реплікою |
| Об'єкти, що потребували ручної правки | 34 % | 9 % |
Підготовку почали заздалегідь: перенесення двічі прогнали на повній копії кластера, зафіксували реєстр об'єктів, які не переїжджають автоматично — функції на нерідній мові, власні розширення, представлення з агрегатами, — і написали для кожного команду міграції з перевіркою на тестових даних. Це й зрізало частку ручного доопрацювання.
Перемикання робили у вікні низького навантаження: приймання зупинили, довели зміни, підняли нову версію і повернули трафік. Читальні копії весь цей час залишалися доступними, тому зовнішні звіти не переривалися.
Зворотну репліку на попередній версії тримали добу після перемикання — відкат перевіряли на репетиції і знали, що він займає хвилини, а не години. Якщо розбори розходяться, повертаємося на попередню версію і продовжуємо роботу, поки не знайдемо причину.
Такий план і є основною страховкою: він дозволяє перейти без тривалого простою і не залежати від однієї спроби.
Що робити, якщо база вже працює в кластері з репліками?
Кластер з репліками оновлюють не вузол за вузлом, а як нову топологію реплікації. Фізична реплікація між мажорними версіями несумісна: формат журналу змін у них різний, тому репліка попередньої версії не підключиться до оновленого основного вузла.
Звідси головний наслідок — перезбирання реплік неминуче: їх будують заново з копії вже оновленого основного.
Покроковий перехід кластера виглядає так. Спершу переконуємося, що репліки не відстають і не залишилося слотів реплікації, які утримують журнали. Потім переносимо дані на основному вузлі на нову мажорну версію — без переливки самої бази.
Після цього знімаємо копію основного і будуємо з неї репліки: вони стають у потік і доганяють його. Далі звіряємо кількість рядків у ключових таблицях і відставання кожної репліки, і лише потім перемикаємо застосунок.
Репліки читання, що обслуговують звіти та вивантаження, виводимо з балансування заздалегідь — поки йде перезбирання, застосунок не повинен слати туди запити.
Якщо звітність готова потерпіти, їх можна залишити на попередній версії до самого перемикання, але запис на них не йде в жоден момент.
Коли вікно недоступності критичне, топологію збирають інакше: новий кластер піднімають поряд і наповнюють логічною реплікацією зі старого. Перемикання тоді займає секунди, а відкат — повернення застосунку на попередній вузол.
Плата — сумісність схеми на обох версіях і ручне доналаштування того, що логічна реплікація не переносить.
Технічні сумніви перед переходом: запитання та відповіді
Перед переводом кластера на нову мажорну гілку сумніви зазвичай упираються в п'ять пунктів: тривалість простою, несумісні розширення, безпечний відкат, обсяг бази та правки в прикладному коді. Нижче — короткі відповіді, детальний розбір іде далі.
Наскільки тривалим буде простій?
Перевірку сумісності, прогін на копії та підготовку розширень робимо на працюючому кластері. Приймання транзакцій зупиняємо лише на перенесення каталогу — це хвилини, а не години; на великих базах час скорочує паралельне перенесення.
Що робити з несумісними розширеннями?
Звіряємо встановлені розширення з цільовою гілкою до старту робіт: частина вимагає оновлення пакета, рідкісні — заміни на аналог. Так несумісність не випливає в момент перемикання.
Чи можливий безпечний відкат?
Поки нову гілку не прийнято в експлуатацію, старий каталог і налаштування залишаються недоторканими: повернення — це перемикання сервісу на попередній каталог. До точки неповернення відкат займає стільки ж часу, скільки саме перемикання.
Чи витримає великий обсяг бази?
Перенесення йде на рівні файлів каталогу, а не порядковим вивантаженням, тому час зростає не лінійно обсягу. Для великих баз окремо перевіряємо вільне місце під новий каталог і журнали, а також час побудови індексів.
Чи доведеться правити прикладний код?
Правки стосуються переважно поведінки за замовчуванням і застарілих конструкцій у запитах. Проганяємо застосунок на копії нової гілки і знімаємо плани запитів — розбіжності фіксуємо до перемикання.
Обговоримо задачу і повернемося з планом робіт
Щоб обговорити задачу предметно, потрібен мінімум ввідних: поточна мажорна гілка і цільова, обсяг бази та її зростання, кількість баз на інстансі, наявність фізичних і логічних реплік, встановлені розширення та їхня сумісність із новою гілкою.
Окремо важливо зрозуміти характер навантаження і допустиме вікно недоступності, в яке має вкластися перемикання.
За цими даними ми збираємо план переходу і сценарій відкату, а не загальні рекомендації. Повертаємося з документом, за яким інженер може працювати без уточнень.
- План переходу за етапами: підготовка, перевірка на копії даних, перемикання, контроль після — з точками, де можна зупинитися.
- Сценарій відкату: до якої точки повертаємося, що відбувається з даними, накопиченими за час перемикання, скільки це займає.
- Оцінка термінів: тривалість вікна недоступності та трудовитрати вашої і нашої команди.
- Список несумісностей: розширення, застарілі параметри конфігурації, запити, що потребують правки.
- Порядок оновлення реплік і вимоги до дискового запасу під нову гілку.
- Передача регламенту: чек-лист та інструкція, щоб наступний мажорний перехід ваша команда проводила сама.
Опишіть задачу у вільній формі — конфігурацію, обмеження щодо вікна простою, що вже пробували і на чому зупинилися. Повернемося з оцінкою термінів, планом переходу і сценарієм відкату, які можна обговорювати предметно, а не на рівні загальних слів.
