pg_restore занимает намного больше времени, чем pg_dump

9

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

Я заметил, что дамп (использование pg_dump -Fc database) занимает всего несколько секунд, но восстановление ( pg_restore -d database) занимает около минуты. Это кажется странным. Я ожидал бы, что оба будут занимать примерно одинаковое время (при условии, что обе задачи связаны с вводом / выводом).

Есть ли проблема с восстановлением? Могу ли я сделать это быстрее? Или это нормально, что восстановление занимает намного больше времени, чем дамп? (И если да, то почему?)

Файл дампа обычно имеет около 3-4 МиБ; СУБД - это PostgreSQL V8.4, работающая на Pentium4 3 ГГц с оперативной памятью 1 ГБ под Ubuntu Linux.

sleske
источник

Ответы:

9

Содержимое индекса не является частью резервной копии, а только определением индекса. И это займет всего несколько байтов. Когда индекс создается во время восстановления и все данные индексируются, он будет намного больше. Это займет время, но это зависит от вашей ситуации, сколько времени.

У pg_restore есть возможность одновременного восстановления ( начиная с версии 8.4), используйте--jobs=number-of-jobs

Фрэнк Хейкенс
источник
Интересно, спасибо. Есть ли способ также сбросить индекс, чтобы ускорить восстановление (за счет большего файла дампа)?
Слеське
Нет, содержимое индекса не может быть частью резервной копии. Для очень маленькой базы данных, такой как ваша (3-4 МиБ), это не должно быть проблемой в любом случае.
Фрэнк Хейкенс
Дополнительная информация: pg_dump не имеет доступа к содержимому индекса. pg_dump использует операторы SELECT для получения всего содержимого таблиц и содержимого системных таблиц для создания резервной копии. Это просто оболочка для некоторых операторов SELECT и некоторых функций для записи результатов на диск.
Фрэнк Хейкенс
@Frank: Спасибо. Не знал о реализации pg_dump. В нашем случае было бы полезно ускорить восстановление, потому что оно должно запускаться многократно как часть автоматизированных тестов, поэтому снижение его с 1 минуты до 10 секунд поможет. Но, видимо, это невозможно. Я должен найти другое решение ...
sleske
2
@Sleske, вы можете попробовать с подходом резервного копирования файловой системы . Это должно сохранить индексы и, кроме того, вероятно, работать немного быстрее для резервного копирования и восстановления
Stefano
4

Для восстановления база данных должна сделать много дополнительной работы:

Некоторые вещи приходят на ум сразу:

  • Письмо медленнее, чем чтение
  • Разбор ввода занимает время
  • Обновление индексов и других внутренних структур
  • Поддержание ссылочной целостности

Не уверен, если это составляет эту разницу во времени, хотя.

Свен
источник