Как ускорить создание реплики PostgreSQL: переход от pg_basebackup к pgBackRest

Проблема масштабных реплик

Создание реплики PostgreSQL, содержащей данные объёмом в терабайты, часто оказывается узким местом в процессах восстановления и масштабирования. Современные серверы со скоростными NVMe‑накопителями и сетевыми каналами 75 Гбит/с способны передавать данные в десятки гигабайт в секунду, однако реальная скорость копирования часто падает до нескольких гигабайт в час. Главный «бутылочный горлышко» в такой схеме – используемый инструмент резервного копирования, который работает в однопоточном режиме и не использует всю пропускную способность оборудования.

Ограничения pg_basebackup

Стандартный утилит pg_basebackup, входящий в поставку PostgreSQL, предназначен для простого и надёжного создания базовой копии кластера. Его плюсы – простота и отсутствие дополнительных зависимостей. Однако при работе с большими базами он имеет ряд ограничений:

• Однопоточная передача – весь поток данных идёт через один процесс, что не позволяет задействовать несколько ядер процессора и параллельные каналы сети.
• Отсутствие гибкой компрессии – компрессия включается только как глобальная настройка и не может быть распределена по нескольким потокам.
• Неоптимальное использование буферов – внутренние буферы фиксированы и часто не соответствуют размеру доступной оперативной памяти.
• Отсутствие управления spool‑директориями – временные файлы пишутся в каталог, указанный в PGDATA, что может привести к переполнению диска с медленными SSD.

Эти особенности делают pg_basebackup непрактичным для задач, где требуется максимально быстро скопировать десятки или сотни терабайт данных.

Параллельный бэкап с pgBackRest

pgBackRest – это современный инструмент резервного копирования, разработанный специально для масштабных PostgreSQL‑кластеров. Его ключевое преимущество – возможность выполнять параллельные операции ввода‑вывода как при создании бэкапа, так и при его восстановлении. При запуске копирования реплики pgBackRest разбивает набор файлов на независимые части и распределяет их между несколькими процессами (по умолчанию – 8 потоков, но количество можно задать вручную).

Параллелизм достигается за счёт:

• Разделения файлового дерева – каждый поток обрабатывает отдельный набор файлов, что позволяет одновременно читать с диска и записывать в сеть.
• Параллельной компрессии – gzip/bzip2/ZSTD могут работать в нескольких потоках, что ускоряет сжатие без потери качества.
• Асинхронного потока передачи – данные сразу отправляются по сети, не дожидаясь полной записи на диск.

Результатом является практически линейный рост скорости с увеличением числа потоков до тех пор, пока не будет исчерпана пропускная способность сети или ввода‑вывода диска.

Ключевые параметры настройки

Для получения максимального ускорения необходимо правильно подобрать несколько параметров в конфигурационном файле pgbackrest.conf:

Эти настройки позволяют гибко адаптировать процесс к конкретному железу: при наличии быстрых NVMe‑дисков и высокоскоростного канала 75 Гбит/с следует увеличить process-max и buffer-size, а при ограниченной памяти – уменьшить их, чтобы избежать падения производительности из‑за частой своппинга.

Оптимизация spool‑хранилища

spool-path – временное хранилище, куда pgBackRest записывает промежуточные части файлов перед их передачей. При неправильной конфигурации этот каталог может стать узким местом:

• Размещение на том же диске, что и основной кластер, приводит к конкуренции за I/O, особенно при одновременной репликации и работе приложений.
• Недостаток свободного места вызывает падения и необходимость перезапуска процесса.

Оптимальная стратегия – разместить spool-path на отдельном SSD с высокой пропускной способностью, настроив RAID 0 или NVMe‑массива. При этом следует обеспечить достаточный объём свободного места (не менее 20 % от общего размера бэкапа) и включить мониторинг заполнения каталога, чтобы вовремя реагировать на рост использования.

Что изменилось в PostgreSQL 18

В версии PostgreSQL 18 были внесены несколько улучшений, влияющих на процесс создания реплики:

• Оптимизированный механизм COPY – теперь он использует более эффективные буферы, что ускоряет чтение больших таблиц.
• Улучшенная работа с WAL‑логами – уменьшена задержка при передаче WAL‑файлов, что ускоряет синхронную репликацию.
• Поддержка более гибкой конфигурации pg_basebackup – теперь можно задать количество потоков для чтения (параметр --jobs), однако эта возможность всё ещё ограничена в сравнении с pgBackRest.

Несмотря на эти улучшения, в сценариях с терабайтными базами pg_basebackup остаётся менее производительным, так как его параллелизм ограничен и он не предоставляет возможностей тонкой настройки буферов и временных каталогов.

Практические рекомендации

1. Переходить на pgBackRest при планировании создания реплик объёмом от 500 ГБ и выше. Его параллельный подход обеспечивает прирост скорости до 5‑10× по сравнению с pg_basebackup.
2. Тщательно подобрать process-max в зависимости от количества ядер и доступной сети. При 8‑ядерном процессоре и 75 Гбит/с сети рекомендуется стартовать с 16 потоков и постепенно увеличивать, наблюдая за загрузкой CPU и сети.
3. Выделять отдельный SSD для spool-path, чтобы избежать конкуренции за I/O. При ограничениях по дисковому пространству – использовать компрессию без потери качества (ZSTD).
4. Мониторить использование ОЗУ и корректировать buffer-size. Если система начинает активно использовать swap, уменьшите размер буфера.
5. Тестировать конфигурацию на небольших подмножествах данных перед запуском полного бэкапа, чтобы убедиться в отсутствии узких мест.
6. Обновить PostgreSQL до версии 18 и включить новые параметры, но не полагаться только на них – pgBackRest остаётся главным драйвером ускорения.

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