13.05.2026 13:41
Никогда специально не интересовался, как ускорить обычные дампы в PostgreSQL.
Никогда специально не интересовался, как ускорить обычные дампы в PostgreSQL. Если позволяет размер баз, то я предпочитаю делать именно логические бэкапы, а не бинарные. С ними проще работать, если их функциональности достаточно - снимок базы в конкретный момент времени. Рассказывал отдельно, как делаю эти дампы и как их проверяю.
Встал вопрос, как относительно просто и быстро ускорить процесс снятия дампа. Не буду подробно всё описывать, так это любая ИИ может сделать. Скажу только суть, чтобы вы понимали, что так можно.
Утилита pg_dump может делать дампы в трёх форматах - plain, custom, directory. Plain - обычный текст. Самый медленный формат, но самый удобный в плане дальнейшей работы с ним. Из него можно вытащить отдельную таблицу, проверить какое-то содержимое, обрезать и т.д. По умолчанию он вообще не сжимается. Сжатие можно добавить настройкой pg_dump или через пайп пропустить.
Формат custom - это уже бинарный дамп. Он жмётся по умолчанию. При сопоставимых настройках сжатия по скорости он +- такой же, как palin. Это наиболее популярный формат для дампов, так как из него можно восстанавливаться в несколько потоков, что значительно быстрее формата plain. Тот в восстановлении очень медленный.
Формат directory я вообще никогда не использовал. На первый взгляд он выглядит не очень удобным для обработки и длительного хранения. Но у него есть важное отличие - процесс создания дампа может быть многопоточным. И это серьёзно ускоряет его, если у вас все данные не лежат в одной большой таблице, так как создание параллелится на уровне таблиц. Я у себя потестировал на сервере с 16 ядрами дампить в 10 потоков. Прирост скорости примерно в 2 раза при одинаковых настройках сжатия по сравнению с plain и custom. То есть на ровном месте ускорил снятие дампов в 2 раза.
# sudo -u postgres /opt/pgpro/1c-15/bin/pg_dump -U postgres -Fd -Z6 -j10 -f /tmp/zup-baza01 zup-baza01
Почитал документацию и увидел параметр --compress=method[:detail]. По умолчанию используется сжатие gzip с уровнем компрессии 6, этот параметр его может изменить. Мне не особо критично сильно сжимать. Хотел ещё ускорить процесс и заменить медленный gzip на lz4 или zstd. И так, и сяк указывал параметры - ничего не помогает. Пишет, что неверное значение параметра. Сразу у ИИ спрашивать не стал, думал, уж с такой простой задачей справлюсь сам. Но увы, не справился.
Оказалось, что этот параметр не поддерживается в версии 15, которая используется у меня. А по умолчанию на сайте открывается документация для версии current, которая сейчас 18-я. Я не обратил на это внимание. Переключился на 15-ю версию и действительно увидел, что такого параметра там нет. Так что если у вас версия утилиты поддерживает изменение алгоритмов сжатия, то можно попробовать другие. Они должны быть быстрее gzip. Надо будет обновить этот сервер по возможности.
#postgresql #backup
Встал вопрос, как относительно просто и быстро ускорить процесс снятия дампа. Не буду подробно всё описывать, так это любая ИИ может сделать. Скажу только суть, чтобы вы понимали, что так можно.
Утилита pg_dump может делать дампы в трёх форматах - plain, custom, directory. Plain - обычный текст. Самый медленный формат, но самый удобный в плане дальнейшей работы с ним. Из него можно вытащить отдельную таблицу, проверить какое-то содержимое, обрезать и т.д. По умолчанию он вообще не сжимается. Сжатие можно добавить настройкой pg_dump или через пайп пропустить.
Формат custom - это уже бинарный дамп. Он жмётся по умолчанию. При сопоставимых настройках сжатия по скорости он +- такой же, как palin. Это наиболее популярный формат для дампов, так как из него можно восстанавливаться в несколько потоков, что значительно быстрее формата plain. Тот в восстановлении очень медленный.
Формат directory я вообще никогда не использовал. На первый взгляд он выглядит не очень удобным для обработки и длительного хранения. Но у него есть важное отличие - процесс создания дампа может быть многопоточным. И это серьёзно ускоряет его, если у вас все данные не лежат в одной большой таблице, так как создание параллелится на уровне таблиц. Я у себя потестировал на сервере с 16 ядрами дампить в 10 потоков. Прирост скорости примерно в 2 раза при одинаковых настройках сжатия по сравнению с plain и custom. То есть на ровном месте ускорил снятие дампов в 2 раза.
# sudo -u postgres /opt/pgpro/1c-15/bin/pg_dump -U postgres -Fd -Z6 -j10 -f /tmp/zup-baza01 zup-baza01
Почитал документацию и увидел параметр --compress=method[:detail]. По умолчанию используется сжатие gzip с уровнем компрессии 6, этот параметр его может изменить. Мне не особо критично сильно сжимать. Хотел ещё ускорить процесс и заменить медленный gzip на lz4 или zstd. И так, и сяк указывал параметры - ничего не помогает. Пишет, что неверное значение параметра. Сразу у ИИ спрашивать не стал, думал, уж с такой простой задачей справлюсь сам. Но увы, не справился.
Оказалось, что этот параметр не поддерживается в версии 15, которая используется у меня. А по умолчанию на сайте открывается документация для версии current, которая сейчас 18-я. Я не обратил на это внимание. Переключился на 15-ю версию и действительно увидел, что такого параметра там нет. Так что если у вас версия утилиты поддерживает изменение алгоритмов сжатия, то можно попробовать другие. Они должны быть быстрее gzip. Надо будет обновить этот сервер по возможности.
#postgresql #backup