PostgreSQL: улучшаясь pg_dump, pg_restore производительность
Когда я начал, я использовал 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
Поскольку существуют прогнозы, эта база данных будет несколькими терабайтами, я должен посмотреть на улучшение производительности теперь.
Просветите меня.
5 ответов
Сначала убедитесь, что вы получаете разумную производительность IO из настроек диска. Затем убедитесь, что установка PostgreSQL соответственно настроена. В частности Shared_Buffers должен быть установлен правильно, Tenance_work_mem должен быть увеличен во время восстановления, full_page_writes должен быть выключен во время восстановления, Wal_Buffers должен Быть увеличенным до 16 МБ во время восстановления, CheckPoint_Segments должно быть увеличено до чего-то вроде 16 во время восстановления, у вас не должно быть никаких необоснованных входов (например, регистрации каждого выполнения оператора), AUTO_VACUUM следует отключить во время восстановления.
Если вы находитесь на 8.4, также экспериментируйте с параллельным восстановлением, вариант --jobs для PG_RESTORE.
Они пригодны для поиска потерянных данных, но я редко использую их в производственном коде. Я бы не был «всегда обескуражен от использования одного» , но я думаю, что в реальном мире они менее часто являются лучшим решением по сравнению с внутренними и левыми/правыми внешними.
-121--1190605-Вы можете сделать это следующим образом:
$firstday = date_create()->modify('first day January 2010');
Как вы догадались просто по тому факту, что сжатие резервного копирования приводит к более высокой производительности, резервное копирование привязано к операции ввода-вывода. Это не должно вызывать удивления, поскольку резервное копирование практически всегда будет связано с операциями ввода-вывода. Сжатие данных приводит к нагрузке ввода-вывода для загрузки ЦП, и поскольку большинство ЦП простаивают во время передачи монстровых данных, сжатие становится чистой победой.
Таким образом, для ускорения резервного копирования/восстановления требуется более быстрый ввод-вывод. Помимо реорганизации базы данных, чтобы не быть одним огромным экземпляром, это почти все, что вы можете сделать.
Два выпуска / идеи:
, указав -Fc, выход PG_Dump уже сжат. Сжатие не максимально, поэтому вы можете найти некоторую экономию пространства с использованием «GZIP -9», но я бы ставила, что не достаточно, чтобы гарантировать дополнительное время (и в / вывод), используемой сжатой и неустойчивой версией резервного копирования. Отказ
Если вы используете PostgreSQL 8.4.x, вы можете ускорить восстановление из резервного копирования -FC с новой опцией командной строки PG_RESTORE «-J N», где n = количество параллельных соединений, используемых для восстановления. Это позволит PG_RESTORE загрузить более одной таблицы данных или генерировать более одного индекса одновременно.
Я предполагаю, что вам нужно резервное копирование, а не основное обновление базы данных.
Для резервного копирования больших баз данных вам следует настроить непрерывное архивирование вместо pg_dump .
Сделайте ваши базовые резервные копии на примере каждый день с помощью
PSQL Template1 -C «Выбрать PG_START_BACKUP ('` Дата +% F-% T``') "
Восстановление было бы так же просто, как восстановление базы данных и журналы WAL не старше, чем pg_start_backup Время от местоположения резервного копирования и стартовых postgres. И это будет намного быстрее.
zcat dumpfile.gz | pg_restore -d db_name
Удаляет полную запись несжатых данных на диск, который в настоящее время находится в вашем узком месте.