PostgreSQL 17 GA: incremental backup на Tantor и Postgres Pro, план миграции с PG 15

PostgreSQL 17 вышел в GA 16 сентября - день в день по графику, что для крупного опенсорс-проекта уже само по себе приятный факт. Мы следили за этим релизом с бета-стадии, гоняли incremental backup сначала на тестовой копии 1С, потом на 2-терабайтной аналитической базе клиента в RC1. Сейчас GA - и это момент переходить от тестирования к реальному плану.

Что приехало в GA

Три вещи, которые для нас важны в работе с DWH и аналитикой:

Incremental backup API - нативный инкрементальный бэкап через pg_basebackup --incremental и pg_combinebackup. Мы подробно тестировали его ещё в бете и RC1: на 2 ТБ базе ежедневное backup-окно сократилось примерно в 4 раза по сравнению с полным pg_basebackup. В GA API стабилен, поведение соответствует RC1 - неожиданностей не было.

Async commit improvements - улучшения в работе асинхронного коммита, в первую очередь снижение латентности при высоком параллелизме. На OLTP-нагрузках с большим числом коротких транзакций это проявляется в снижении среднего времени отклика. На аналитических базах эффект менее очевиден, но для смешанных OLAP/OLTP инсталляций - интересно.

MERGE с RETURNING - наконец-то. MERGE появился в PG 15, но без поддержки RETURNING, что делало его неудобным в ряде ETL-сценариев. В PG 17 RETURNING в MERGE поддерживается, и это закрывает один из наиболее раздражавших пробелов. ETL-джобы, которые делали INSERT ... ON CONFLICT ... RETURNING через хитрые конструкции, теперь можно переписать аккуратнее.

Отдельная история: Tantor и Postgres Pro

Большинство наших клиентских инсталляций PostgreSQL - не ванильный upstream, а коммерческие дистрибутивы: Tantor SE или Postgres Pro. Это важный нюанс при планировании миграции: GA upstream не означает автоматически, что сегодня можно обновляться.

Tantor SE 2024 анонсировал поддержку PG 17 - ждём официального билда и документации. Для КИИ-инсталляций это особенно важно: нам нужен не просто работающий бинарник, а версия с актуальным сертификатом ФСТЭК или хотя бы чёткой датой его получения. Обновляться на несертифицированную версию в регулируемом контуре - не вариант.

Postgres Pro аналогично: upstream GA - это сигнал к тому, что коммерческий дистрибутив начинает финальную подготовку своей версии. Обычно отставание составляет несколько недель.

План миграции с PG 15

Наши клиентские инсталляции в большинстве своём сидят на PG 15. PG 17 - это прыжок через два мажорных релиза, что требует внимания.

Мы идём по следующей схеме:

• Dev и staging окружения - обновляем немедленно, как только появляется билд Tantor SE или Postgres Pro на основе PG 17. Там нет ограничений по сертификации, и это лучший способ поймать несовместимости заранее.
• Production, некритичные сервисы - плановое окно обновления через 4-6 недель после выхода коммерческого билда. Нужно время на обкатку расширений: pg_partman, pg_cron, timescaledb - всё должно пересобраться и пройти smoke-тесты.
• Production, КИИ-контуры - только после получения актуального сертификата Tantor SE. Там торопиться незачем: PG 15 получает security-патчи, угрозы нет.

Для самого апгрейда используем pg_upgrade с флагом --link там, где позволяет инфраструктура - это сокращает downtime за счёт hard links вместо полного копирования датафайлов. Перед апгрейдом обязательно полный pg_basebackup - именно сейчас переходим на incremental-цепочку уже на PG 17 после апгрейда.

Про MERGE RETURNING на практике

Небольшое замечание по MERGE ... RETURNING, потому что мы сразу начали смотреть на свои ETL-пайплайны. Синтаксис выглядит ожидаемо:

MERGE INTO target AS t
USING source AS s ON t.id = s.id
WHEN MATCHED THEN
  UPDATE SET val = s.val
WHEN NOT MATCHED THEN
  INSERT (id, val) VALUES (s.id, s.val)
RETURNING t.id, xmax = 0 AS inserted;

xmax = 0 как способ отличить вставленные строки от обновлённых - это старый трюк из PostgreSQL, теперь применимый прямо в MERGE. Для ETL-джобов, которым нужно знать что именно произошло с каждой строкой - удобно. Заменяем несколько паттернов с CTE и ON CONFLICT.

Что дальше

Инкрементальный бэкап тестировали на vanilla PostgreSQL. Нужно проверить поведение pg_combinebackup в Tantor SE - коммерческие дистрибутивы иногда патчат механизмы резервирования, и стоит убедиться что инкрементальная цепочка собирается корректно и в их версии.

Следим за датой выхода коммерческих билдов. Как только Tantor SE опубликует версию на PG 17 с внятным статусом сертификации - начинаем миграцию dev-контуров.