Я сделал pg_dump базы данных и теперь пытаюсь установить полученный файл .sql на другой сервер.
Я использую следующую команду.
psql -f databasedump.sql
Я начал установку базы данных ранее сегодня, и теперь через 7 часов база данных все еще заполняется. Я не знаю, так ли это, как долго он должен идти, но я продолжаю следить за ним, пока я видел более 12 миллионных вставок и подсчета. Я подозреваю, что есть более быстрый способ сделать это.
Создайте свои дампы с помощью
pg_dump -Fc -Z 9 --file=file.dump myDb
Fc: Выведите собственный архив, подходящий для ввода в pg_restore. Это самый гибкий формат, который позволяет переупорядочивать данные загрузки, а также определения объектов. Этот формат также сжимается по умолчанию.
Z 9: --compress = 0..9 Укажите уровень сжатия для использования. Zero означает отсутствие сжатия. Для формата пользовательского архива это определяет сжатие отдельных сегментов табличных данных, а по умолчанию - сжатие на умеренном уровне. Для обычного текстового вывода установка ненулевого уровня сжатия приводит к сжатию всего выходного файла, как если бы он был передан через gzip; но по умолчанию не нужно сжимать. Формат архива tar в настоящее время не поддерживает сжатие вообще.
и восстановить его с помощью
pg_restore -Fc -j 8 file.dump
-j: --jobs = количество заданий Запускайте наиболее трудоемкие части pg_restore - те, которые загружают данные, создают индексы или создают ограничения - используя несколько параллельных заданий. Этот параметр может значительно сократить время восстановления большой базы данных на сервере, работающем на многопроцессорной машине.
Каждое задание - это один процесс или один поток, в зависимости от операционной системы, и использует отдельное подключение к серверу.
Оптимальное значение для этой опции зависит от аппаратной настройки сервера, клиента и сети. Факторы включают количество ядер процессора и установку диска. Хорошим местом для запуска является количество ядер процессора на сервере, но значения, большие, чем это, также могут привести к более быстрому времени восстановления во многих случаях. Конечно, слишком высокие значения приведут к снижению производительности из-за измельчения.
Этот параметр поддерживает только формат настраиваемого архива. Входной файл должен быть обычным файлом (а не, например, трубой). Эта опция игнорируется при испускании script вместо прямого подключения к серверу базы данных. Кроме того, несколько заданий не могут использоваться вместе с опцией - single-transaction.
Ссылки:
Почему вы создаете необработанный дамп .sql? Описание открытия pg_dump рекомендует "настраиваемый" формат -Fc.
Затем вы можете использовать pg_restore, который восстановит ваши данные (или отдельные части). Существует опция "количество заданий" -j, которая может использовать несколько ядер (если ваши диски еще не являются ограничивающим фактором). В большинстве случаев на современной машине вы можете ожидать хотя бы некоторого выигрыша от этого.
Теперь вы говорите: "Я не знаю, как долго это должно быть". Ну, пока вы не сделали несколько восстановлений, вы не узнаете. Следите за тем, что делает ваша система, и ограничены ли вы процессором или дисковым вводом/выводом.
Наконец, параметры конфигурации, которые вы хотите восстановить для базы данных, не те, которые вы хотите запустить. Несколько полезных стартеров:
Помните reset их после восстановления, хотя.
PG_DUMP | всегда используйте каталог формата с опцией -j
time pg_dump -j 8 -Fd -f /tmp/newout.dir fsdcm_external
PG_RESTORE | всегда используйте настройку для postgres.conf с помощью каталога формата. -j option
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://gitlab.com/yanar/Tuning/wikis/improve-pg-dump&restore
Обычно рекомендуется использовать pg_dump в паре с pg_restore вместо psql. Этот метод можно разделить между ядрами, чтобы ускорить процесс загрузки, передав флаг --jobs как таковой:
$ pg_restore --jobs=8 dump.sql
У самих Postgres есть руководство по массовой загрузке данных.
Я также рекомендовал бы сильно настроить ваш конфигурационный файл postgresql.conf и установить соответствующие значения для значений maintenance_work_mem и checkpoint_segments; более высокие значения на них могут значительно увеличить производительность записи.
вы также можете сделать последовательную резервную копию базы данных с помощью pg_basebackup и pigz, а также распаковать ее параллельно, см.
https://brunomgalmeida.wordpress.com/2016/09/26/faster-pg_basebackup/