PostgreSQL 17 beta: тестируем incremental backup API на продуктивной 1С

PostgreSQL 17 ушёл в beta 1 в конце мая, и мы добрались до него только сейчас - ждали, пока уляжется первый шум и появятся нормальные отчёты о реальных проблемах. Три вещи в релизе нас интересуют по-настоящему: incremental backup API, TID scan и переработанный механизм VACUUM. Но тестировать умозрительно неинтересно, поэтому взяли тестовую копию одной из продуктивных баз 1С - примерно 400 ГБ, активная OLTP-нагрузка в рабочие часы, регулярные массовые обновления остатков.

Почему именно 1С

Базы 1С - это специфический зверь с точки зрения PostgreSQL. Очень много мелких таблиц с частыми UPDATE, накапливается мёртвое пространство быстро, autovacuum под нагрузкой не всегда успевает. Плюс бэкапы на таких базах традиционно болезненная тема: pg_basebackup на 400 ГБ с нормальной WAL-активностью занимает приличное время и создаёт ощутимую нагрузку на диски. Это делает их хорошим полигоном для проверки именно тех фич, которые приехали в 17-й версии.

Incremental backup API: что это и как работает

Главная инновация PG 17 в области резервирования - нативный инкрементальный бэкап прямо в pg_basebackup. Раньше инкрементальный бэкап в PostgreSQL делался либо через WAL-архивирование с PITR, либо через сторонние инструменты вроде pgBackRest или Barman, которые умеют строить инкрементальные цепочки поверх WAL. Встроенного механизма не было.

В PG 17 добавлен WAL summarizer - фоновый процесс, который ведёт учёт изменённых блоков с момента последнего бэкапа. На этой основе pg_basebackup теперь умеет снимать инкрементальный снимок: копируются только блоки, которые были затронуты с момента предыдущего полного или инкрементального бэкапа.

Чтобы запустить это дело, нужно включить summarizer в конфиге:

summarize_wal = on

После чего первый pg_basebackup снимает полный бэкап с манифестом, а последующие можно запускать с флагом --incremental:

pg_basebackup -D /backup/full --checkpoint=fast --manifest-checksums=sha256
# ...через время...
pg_basebackup -D /backup/incr1 --incremental=/backup/full/backup_manifest --checkpoint=fast

Для восстановления из инкрементальной цепочки приехала отдельная утилита pg_combinebackup, которая склеивает полный бэкап и один или несколько инкрементов в один полноценный каталог данных.

Что мы увидели на тестовой базе

Брали снимки каждые 4 часа в течение рабочего дня. Полный pg_basebackup на нашей копии занимал в среднем около 40 минут и создавал архив чуть больше 350 ГБ (сжатие gzip включено). Инкрементальные снимки через 4 часа активной работы - это грубо 5-15% от полного объёма, время соответственно от 3 до 8 минут.

Важно понимать: это beta, и поведение ещё может меняться. Мы наблюдали несколько моментов, которые стоит держать в голове:

• WAL summarizer создаёт дополнительную нагрузку. Небольшую, но заметную на очень write-интенсивных нагрузках. На нашей тестовой копии это была погрешность в пределах шума, но на базах с более тяжёлой записью стоит мониторить.
• Цепочка инкрементов не бесконечная. Рекомендуется периодически делать новый полный бэкап и начинать цепочку заново - чем длиннее цепочка, тем дольше pg_combinebackup будет собирать финальный образ для восстановления.
• pg_combinebackup работает только в режиме записи в директорию. Стриминга нет. Для 400 ГБ это означает, что при восстановлении нужно место для финального образа. Это не блокер, но планировать дисковое пространство нужно с учётом этого.

Сам факт того, что инкрементальный бэкап теперь нативный и не требует отдельного тула - это значительно упрощает операционную картину для небольших инсталляций, где pgBackRest ставить было оверкиллом.

TID scan и VACUUM: что изменилось

TID scan - это возможность искать строки напрямую по физическому адресу (tuple ID). Звучит нишево, но на практике это ускоряет ряд внутренних операций, в том числе некоторые сценарии VACUUM и административные запросы. Прямого применения в прикладных запросах 1С мы не видим, но для дба-инструментов типа pg_timetable или мониторинговых запросов к системным таблицам - полезно.

VACUUM в 17-й версии переработан в части обработки страниц с мёртвыми версиями строк. Конкретно - улучшилась работа с так называемым eager freezing и сократилось число повторных проходов по таблицам. На базах 1С, где autovacuum грустит под нагрузкой, это потенциально интересно. Мы запустили несколько прогонов VACUUM VERBOSE на больших таблицах остатков и субъективно видим более быстрое завершение, но до строгих измерений руки не дошли - beta есть beta, смысла настраивать финальные параметры нет.

Статус и дальнейшие шаги

На продуктивную нагрузку PG 17 beta, разумеется, не идёт - это тестирование на копии, чтобы понять, что нас ждёт и на что обратить внимание при реальной миграции. Incremental backup API - это именно то, чего не хватало для простых инсталляций без отдельного инструмента управления бэкапами. Посмотрим что будет в RC и GA.

Если работаете с резервированием PostgreSQL в контексте задач DWH и аналитики, incremental backup API меняет расчёт RPO/RTO для баз среднего размера: более частые снимки становятся практически бесплатными с точки зрения нагрузки и хранения.