PostgreSQL 17 RC1: гоним нагрузочный тест на 2 ТБ и смотрим на incremental backup

PostgreSQL 17 перешёл в RC1, что означает feature freeze: больше новых штук не добавляют, только баги правят. Для нас это сигнал: пора перестать смотреть на changelog и начать нормально тестировать. Мы уже гоняли incremental backup API на бете - на тестовой копии 1С около 400 ГБ. Теперь подняли планку: взяли аналитическую базу клиента из практики DWH и аналитики - чуть больше 2 ТБ, смешанная OLAP/OLTP нагрузка, плюс несколько крупных таблиц фактов с ежесуточным партиционированием.

Почему RC1 - это уже серьёзно

Beta - это «посмотри что будет». RC - это «убедись что нет сюрпризов». Разница принципиальная: в RC API зафиксирован, поведение стабилизировано, и если что-то не работает - это баг, который должен быть исправлен до GA. Тестировать на RC имеет смысл именно с прицелом на production: можно уже принимать решения о плане миграции, а не просто фиксировать наблюдения.

На бете мы несколько раз натыкались на мелкие шероховатости в поведении pg_combinebackup при длинных цепочках инкрементов. В RC1 эти моменты поправили, и это чувствуется.

Нагрузочный стенд: что и как гоняли

База - аналитическое хранилище: факты продаж, складские остатки, регуляторная отчётность. Объём - 2 ТБ после vacuum и analyze, без учёта WAL. Железо: два NVMe-диска под данными, один под WAL, 256 ГБ RAM, 32 ядра. Нагрузка - реплей реального трафика с production за последние 30 дней плюс имитация ночных ETL-джобов.

Тестировали три сценария:

• Полный pg_basebackup - baseline, то, что работало до 17-й версии.
• Incremental backup, цепочка 7 дней - полный бэкап раз в неделю, ежедневные инкременты.
• Incremental backup, цепочка 3 дня - полный бэкап раз в три дня, более короткая цепочка для ускорения pg_combinebackup при восстановлении.

Что получилось с backup-окном

Полный pg_basebackup на 2 ТБ с gzip и умеренной параллельностью занял в наших условиях около 3 часов. Это backup-окно, которое нужно либо принять, либо как-то ужимать - обычно за счёт pgBackRest или Barman с дельта-режимом.

Ежедневный инкрементальный снимок после активного рабочего дня - примерно 100-200 ГБ изменённых блоков в зависимости от интенсивности ETL. Время - 40-45 минут. Итого backup-окно сократилось грубо в 4 раза для ежедневных операций.

Нагрузка на хост во время инкрементального снимка заметно ниже: WAL summarizer ведёт учёт изменённых блоков непрерывно, поэтому нет big scan всего датафайла - копируются только затронутые страницы. На наших NVMe это выражается в другом профиле I/O: меньше sustained read, больше случайных операций. Для production это скорее лучше, чем хуже - меньше конкуренции с аналитическими запросами.

Цепочка из 7 инкрементов даёт pg_combinebackup примерно 25-30 минут работы при восстановлении - нужно собрать образ из 8 кусков. Для нас это приемлемо, но для сценариев с жёстким RTO стоит держать цепочку короче. Вариант с цепочкой из 3 инкрементов даёт pg_combinebackup около 10-12 минут при восстановлении - разница существенная.

Что ещё смотрели

Параллельный vacuum в PG 17 переработан в части работы с B-tree индексами - вакуум теперь умеет обрабатывать несколько индексов параллельно при достаточном max_parallel_maintenance_workers. На наших таблицах фактов с 10-15 индексами на каждой это дало ощутимое сокращение времени maintenance-окна. Конкретные цифры зависят от конфигурации, но направление правильное.

pg_stat_io - новое представление, которое приехало в PG 16 и в 17-й версии обросло деталями. На RC1 его уже удобно использовать для диагностики I/O-паттернов под нагрузкой. Мы добавили его в дашборд мониторинга и сразу увидели несколько неочевидных узких мест в конфигурации shared_buffers у клиента.

Что с миграцией клиентских инсталляций

RC1 - не GA, на production не едем. Но план миграции уже можно писать вполне конкретно.

Наши клиентские инсталляции PostgreSQL делятся грубо на три группы:

• Небольшие базы до 200 ГБ - переход на 17-й даст incremental backup нативно, без pgBackRest. Это упрощение операционной модели.
• Средние базы 200 ГБ - 2 ТБ - основной выигрыш от incremental backup плюс параллельный vacuum. Здесь и будет наибольший эффект.
• Крупные базы больше 2 ТБ - тут уже pgBackRest или Barman скорее всего и так есть, нативный инкрементальный бэкап ничего не меняет кардинально, но pg_stat_io и улучшенный vacuum всё равно интересны.

Ждём GA - по текущим срокам это должно быть в ближайшие недели. После выхода GA начнём плановые миграции, начиная с dev/staging инсталляций.