PostgreSQL: улучшение производительности pg_dump, pg_restore - PullRequest
Новая
       9

PostgreSQL: улучшение производительности pg_dump, pg_restore

67 голосов
/ 19 января 2010

Когда я начал, я использовал pg_dump с обычным форматом по умолчанию. Я был непросветленным.

Исследование показало мне улучшение времени и размера файла с pg_dump -Fc | gzip -9 -c > dumpfile.gz. Я был просветленным.

Когда пришло время заново создать базу данных, 

# create tablespace dbname location '/SAN/dbname';
# create database dbname tablespace dbname;
# alter database dbname set temp_tablespaces = dbname;

% gunzip dumpfile.gz              # to evaluate restore time without a piped uncompression
% pg_restore -d dbname dumpfile   # into a new, empty database defined above

Я чувствовал себя неосведомленным: восстановление заняло 12 часов, чтобы создать базу данных, это только часть того, чем она станет: 

# select pg_size_pretty(pg_database_size('dbname'));
47 GB

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

Пожалуйста, просветите меня.

Ответы [ 6 ]

48 голосов
/ 19 января 2010

Сначала убедитесь, что вы получаете разумную производительность ввода-вывода в настройках диска.Затем проверьте, правильно ли настроена установка PostgreSQL.В частности, shared_buffers должен быть установлен правильно, maintenance_work_mem должно быть увеличено во время восстановления, full_page_writes должно быть отключено во время восстановления, wal_buffers должно быть увеличено до 16 МБ во время восстановления, checkpoint_segments должно быть увеличено до чего-токак 16 во время восстановления, у вас не должно быть необоснованного входа в систему (например, регистрация каждого выполненного оператора), auto_vacuum следует отключить во время восстановления.

Если вы используете 8.4, также поэкспериментируйте с параллельным восстановлениемопция --jobs для pg_restore.

14 голосов
/ 19 января 2010

Два вопроса / идеи:

  1. При указании -Fc вывод pg_dump уже сжат. Сжатие не является максимальным, поэтому вы можете найти некоторую экономию пространства, используя «gzip -9», но я бы поспорил, что этого недостаточно, чтобы гарантировать дополнительное время (и ввод / вывод), используемое для сжатия и распаковки версии -Fc резервной копии .

  2. Если вы используете PostgreSQL 8.4.x, вы можете ускорить восстановление из резервной копии -Fc с помощью новой опции командной строки pg_restore "-jn", где n = количество параллельных подключений, используемых для восстановления. , Это позволит pg_restore загружать более одной таблицы или создавать более одного индекса одновременно.

10 голосов
/ 31 декабря 2016

Улучшение pg dump & restore

PG_DUMP | всегда используйте форматную директорию с -j, опция 

time pg_dump -j 8 -Fd -f /tmp/newout.dir fsdcm_external

PG_RESTORE | всегда используйте настройку для postgres.conf с директорией формата С -j опция 

work_mem = 32MB
shared_buffers = 4GB
maintenance_work_mem = 2GB
full_page_writes = off
autovacuum = off
wal_buffers = -1

time pg_restore -j 8 --format=d -C -d postgres /tmp/newout.dir/`

Для получения дополнительной информации

https://github.com/YanarAssaf/PostgreSQL/wiki/Improve-pg-dump%7Crestore

9 голосов
/ 19 января 2010

Полагаю, вам нужно резервное копирование, а не серьезное обновление базы данных.

Для резервного копирования больших баз данных вы должны установить непрерывное архивирование вместо pg_dump.

  1. Настройка архивации WAL .

  2. Например, ежедневно создавайте базовые резервные копии, используя
    psql template1 -c "select pg_start_backup(' `date +% F-% T`` ')" rsync -a - удалить / var / lib / pgsql / data / / var / backups / pgsql / base / psql template1 -c "select pg_stop_backup ()" `

Восстановление будет таким же простым, как восстановление базы данных и журналов WAL не старше pg_start_backup времени из места резервного копирования и запуска Postgres. И это будет намного быстрее.

7 голосов
/ 22 января 2010 
zcat dumpfile.gz | pg_restore -d db_name

Удаляет полную запись несжатых данных на диск, который в настоящее время является вашим узким местом.

3 голосов
/ 19 января 2010

Как вы уже догадались, просто потому, что сжатие резервной копии приводит к более высокой производительности, ваша резервная копия связана с вводом / выводом. Это не должно вызывать удивления, поскольку резервное копирование всегда будет связано с вводом / выводом. Сжатие данных обменивает нагрузку ввода-вывода на нагрузку на ЦП, и поскольку большинство ЦП не работают во время передачи данных монстра, сжатие получается как чистый выигрыш.

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

...