Postgresql восстановление базы из дампа: Backup restore postgresql базы данных с pg_dump

Postgres Pro Standard : Документация: 10: 24.1. Выгрузка в SQL : Компания Postgres Professional

24.1. Выгрузка в SQL

Идея, стоящая за этим методом, заключается в генерации текстового файла с командами SQL, которые при выполнении на сервере пересоздадут базу данных в том же самом состоянии, в котором она была на момент выгрузки. Postgres Pro предоставляет для этой цели вспомогательную программу pg_dump. Простейшее применение этой программы выглядит так:

pg_dump имя_базы > файл_дампа

Как видите, pg_dump записывает результаты своей работы в устройство стандартного вывода. Далее будет рассмотрено, чем это может быть полезно. В то время как вышеупомянутая команда создаёт текстовый файл, pg_dump может создать файлы и в других форматах, которые допускают параллельную обработку и более гибкое управление восстановлением объектов.

Программа pg_dump является для Postgres Pro обычным клиентским приложением (хотя и весьма умным). Это означает, что вы можете выполнять процедуру резервного копирования с любого удалённого компьютера, если имеете доступ к нужной базе данных. Но помните, что pg_dump не использует для своей работы какие-то специальные привилегии. В частности, ей обычно требуется доступ на чтение всех таблиц, которые вы хотите выгрузить, так что для копирования всей базы данных практически всегда её нужно запускать с правами суперпользователя СУБД. (Если у вас нет достаточных прав для резервного копирования всей базы данных, вы, тем не менее, можете сделать резервную копию той части базы, доступ к которой у вас есть, используя такие параметры, как -n схема или -t таблица.)

Указать, к какому серверу должна подключаться программа pg_dump, можно с помощью аргументов командной строки -h сервер и -p порт. По умолчанию в качестве сервера выбирается localhost или значение, указанное в переменной окружения PGHOST. Подобным образом, по умолчанию используется порт, заданный в переменной окружения PGPORT, а если она не задана, то порт, указанный по умолчанию при компиляции. (Для удобства при компиляции сервера обычно устанавливается то же значение по умолчанию.)

Как и любое другое клиентское приложение Postgres Pro, pg_dump по умолчанию будет подключаться к базе данных с именем пользователя, совпадающим с именем текущего пользователя операционной системы. Чтобы переопределить имя, либо добавьте параметр -U, либо установите переменную окружения PGUSER. Помните, что pg_dump подключается к серверу через обычные механизмы проверки подлинности клиента (которые описываются в Главе 19).

Важное преимущество pg_dump в сравнении с другими методами резервного копирования, описанными далее, состоит в том, что вывод pg_dump обычно можно загрузить в более новые версии Postgres Pro, в то время как резервная копия на уровне файловой системы и непрерывное архивирование жёстко зависят от версии сервера. Также, только метод с применением pg_dump будет работать при переносе базы данных на другую машинную архитектуру, например, при переносе с 32-битной на 64-битную версию сервера.

Дампы, создаваемые pg_dump, являются внутренне согласованными, то есть, дамп представляет собой снимок базы данных на момент начала запуска pg_dump. pg_dump не блокирует другие операции с базой данных во время своей работы. (Исключение составляют операции, которым нужна исключительная блокировка, как например, большинство форм команды ALTER TABLE.)

24.1.1. Восстановление дампа

Текстовые файлы, созданные pg_dump, предназначаются для последующего чтения программой psql. Общий вид команды для восстановления дампа:

psql имя_базы < файл_дампа

где файл_дампа — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_базы, не будет создана данной командой, так что вы должны создать её сами из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 имя_базы). Программа psql принимает параметры, указывающие сервер, к которому осуществляется подключение, и имя пользователя, подобно pg_dump. За дополнительными сведениями обратитесь к справке по psql. Дампы, выгруженные не в текстовом формате, восстанавливаются утилитой pg_restore.

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

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

psql --set ON_ERROR_STOP=on имя_базы < файл_дампа

В любом случае вы получите только частично восстановленную базу данных. В качестве альтернативы можно указать, что весь дамп должен быть восстановлен в одной транзакции, так что восстановление либо полностью выполнится, либо полностью отменится. Включить данный режим можно, передав psql аргумент -1 или --single-transaction. Выбирая этот режим, учтите, что даже незначительная ошибка может привести к откату восстановления, которое могло продолжаться несколько часов. Однако, это всё же может быть предпочтительней, чем вручную вычищать сложную базу данных после частично восстановленного дампа.

Благодаря способности pg_dump и psql писать и читать каналы ввода/вывода, можно скопировать базу данных непосредственно с одного сервера на другой, например:

pg_dump -h host1 имя_базы | psql -h host2 имя_базы

Важно

Дампы, которые выдаёт pg_dump, содержат определения относительно template0. Это означает, что любые языки, процедуры и т. п., добавленные в базу через template1, pg_dump также выгрузит в дамп. Как следствие, если при восстановлении вы используете модифицированный template1, вы должны создать пустую базу данных из template0, как показано в примере выше.

После восстановления резервной копии имеет смысл запустить ANALYZE для каждой базы данных, чтобы оптимизатор запросов получил полезную статистику; за подробностями обратитесь к Подразделу 23.1.3 и Подразделу 23.1.6. Другие советы по эффективной загрузке больших объёмов данных в Postgres Pro вы можете найти в Разделе 14.4.

24.1.2. Использование pg_dumpall

Программа pg_dump выгружает только одну базу данных в один момент времени и не включает в дамп информацию о ролях и табличных пространствах (так как это информация уровня кластера, а не самой базы данных). Для удобства создания дампа всего содержимого кластера баз данных предоставляется программа pg_dumpall, которая делает резервную копию всех баз данных кластера, а также сохраняет данные уровня кластера, такие как роли и определения табличных пространств. Простое использование этой команды:

pg_dumpall > файл_дампа

Полученную копию можно восстановить с помощью psql:

psql -f файл_дампа postgres

(В принципе, здесь в качестве начальной базы данных можно указать имя любой существующей базы, но если вы загружаете дамп в пустой кластер, обычно нужно использовать postgres). Восстанавливать дамп, который выдала pg_dumpall, всегда необходимо с правами суперпользователя, так как они требуются для восстановления информации о ролях и табличных пространствах. Если вы используете табличные пространства, убедитесь, что пути к табличным пространствам в дампе соответствуют новой среде.

pg_dumpall выдаёт команды, которые заново создают роли, табличные пространства и пустые базы данных, а затем вызывает для каждой базы pg_dump. Таким образом, хотя каждая база данных будет внутренне согласованной, состояние разных баз не будет синхронным.

Только глобальные данные кластера можно выгрузить, передав pg_dumpall ключ --globals-only. Это необходимо, чтобы полностью скопировать кластер, когда pg_dump выполняется для отдельных баз данных.

24.1.3. Управление большими базами данных

Некоторые операционные системы накладывают ограничение на максимальный размер файла, что приводит к проблемам при создании больших файлов с помощью pg_dump. К счастью, pg_dump может писать в стандартный вывод, так что вы можете использовать стандартные инструменты Unix для того, чтобы избежать потенциальных проблем. Вот несколько возможных методов:

Используйте сжатые дампы. Вы можете использовать предпочитаемую программу сжатия, например gzip:

pg_dump имя_базы | gzip > имя_файла.gz

Затем загрузить сжатый дамп можно командой:

gunzip -c имя_файла.gz | psql имя_базы

или:

cat имя_файла.gz | gunzip | psql имя_базы

Используйте split. Команда split может разбивать выводимые данные на небольшие файлы, размер которых удовлетворяет ограничению нижележащей файловой системы. Например, чтобы получить части по 1 мегабайту:

pg_dump имя_базы | split -b 1m - имя_файла

Восстановить их можно так:

cat имя_файла* | psql имя_базы

Используйте специальный формат дампа pg_dump. Если при сборке Postgres Pro была подключена библиотека zlib, дамп в специальном формате будет записываться в файл в сжатом виде. В таком формате размер файла дампа будет близок к размеру, полученному с применением gzip, но он лучше тем, что позволяет восстанавливать таблицы выборочно. Следующая команда выгружает базу данных в специальном формате:

pg_dump -Fc имя_базы > имя_файла

Дамп в специальном формате не является скриптом для psql и должен восстанавливаться с помощью команды pg_restore, например:

pg_restore -d имя_базы имя_файла

За подробностями обратитесь к справке по командам pg_dump и pg_restore.

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

Используйте возможность параллельной выгрузки в pg_dump. Чтобы ускорить выгрузку большой БД, вы можете использовать режим параллельной выгрузки в pg_dump. При этом одновременно будут выгружаться несколько таблиц. Управлять числом параллельных заданий позволяет параметр -j. Параллельная выгрузка поддерживается только для формата архива в каталоге.

pg_dump -j число -F d -f выходной_каталог имя_базы

Вы также можете восстановить копию в параллельном режиме с помощью pg_restore -j. Это поддерживается для любого архива в формате каталога или специальном формате, даже если архив создавался не командой pg_dump -j.

PostgreSQL : Документация: 9.6: 25.1. Выгрузка в SQL : Компания Postgres Professional

25.1. Выгрузка в SQL

Идея, стоящая за этим методом, заключается в генерации текстового файла с командами SQL, которые при выполнении на сервере пересоздадут базу данных в том же самом состоянии, в котором она была на момент выгрузки. PostgreSQL предоставляет для этой цели вспомогательную программу pg_dump. Простейшее применение этой программы выглядит так:

pg_dump имя_базы > файл_дампа

Как видите, pg_dump записывает результаты своей работы в устройство стандартного вывода. Далее будет рассмотрено, чем это может быть полезно. В то время как вышеупомянутая команда создаёт текстовый файл, pg_dump может создать файлы и в других форматах, которые допускают параллельную обработку и более гибкое управление восстановлением объектов.

Программа pg_dump является для PostgreSQL обычным клиентским приложением (хотя и весьма умным). Это означает, что вы можете выполнять процедуру резервного копирования с любого удалённого компьютера, если имеете доступ к нужной базе данных. Но помните, что pg_dump не использует для своей работы какие-то специальные привилегии. В частности, ей обычно требуется доступ на чтение всех таблиц, которые вы хотите выгрузить, так что для копирования всей базы данных практически всегда её нужно запускать с правами суперпользователя СУБД. (Если у вас нет достаточных прав для резервного копирования всей базы данных, вы, тем не менее, можете сделать резервную копию той части базы, доступ к которой у вас есть, используя такие параметры, как -n схема или -t таблица.)

Указать, к какому серверу должна подключаться программа pg_dump, можно с помощью аргументов командной строки -h сервер и -p порт. По умолчанию в качестве сервера выбирается localhost или значение, указанное в переменной окружения PGHOST. Подобным образом, по умолчанию используется порт, заданный в переменной окружения PGPORT, а если она не задана, то порт, указанный по умолчанию при компиляции. (Для удобства при компиляции сервера обычно устанавливается то же значение по умолчанию.)

Как и любое другое клиентское приложение PostgreSQL, pg_dump по умолчанию будет подключаться к базе данных с именем пользователя, совпадающим с именем текущего пользователя операционной системы. Чтобы переопределить имя, либо добавьте параметр -U, либо установите переменную окружения PGUSER. Помните, что pg_dump подключается к серверу через обычные механизмы проверки подлинности клиента (которые описываются в Главе 20).

Важное преимущество pg_dump в сравнении с другими методами резервного копирования, описанными далее, состоит в том, что вывод pg_dump обычно можно загрузить в более новые версии PostgreSQL, в то время как резервная копия на уровне файловой системы и непрерывное архивирование жёстко зависят от версии сервера. Также, только метод с применением pg_dump будет работать при переносе базы данных на другую машинную архитектуру, например, при переносе с 32-битной на 64-битную версию сервера.

Дампы, создаваемые pg_dump, являются внутренне согласованными, то есть, дамп представляет собой снимок базы данных на момент начала запуска pg_dump. pg_dump не блокирует другие операции с базой данных во время своей работы. (Исключение составляют операции, которым нужна исключительная блокировка, как например, большинство форм команды ALTER TABLE.)

25.1.1. Восстановление дампа

Текстовые файлы, созданные pg_dump, предназначаются для последующего чтения программой psql. Общий вид команды для восстановления дампа:

psql имя_базы < файл_дампа

где файл_дампа — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_базы, не будет создана данной командой, так что вы должны создать её сами из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 имя_базы). Программа psql принимает параметры, указывающие сервер, к которому осуществляется подключение, и имя пользователя, подобно pg_dump. За дополнительными сведениями обратитесь к справке по psql. Дампы, выгруженные не в текстовом формате, восстанавливаются утилитой pg_restore.

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

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

psql --set ON_ERROR_STOP=on имя_базы < файл_дампа

В любом случае вы получите только частично восстановленную базу данных. В качестве альтернативы можно указать, что весь дамп должен быть восстановлен в одной транзакции, так что восстановление либо полностью выполнится, либо полностью отменится. Включить данный режим можно, передав psql аргумент -1 или --single-transaction. Выбирая этот режим, учтите, что даже незначительная ошибка может привести к откату восстановления, которое могло продолжаться несколько часов. Однако, это всё же может быть предпочтительней, чем вручную вычищать сложную базу данных после частично восстановленного дампа.

Благодаря способности pg_dump и psql писать и читать каналы ввода/вывода, можно скопировать базу данных непосредственно с одного сервера на другой, например:

pg_dump -h host1 имя_базы | psql -h host2 имя_базы

Важно

Дампы, которые выдаёт pg_dump, содержат определения относительно template0. Это означает, что любые языки, процедуры и т. п., добавленные в базу через template1, pg_dump также выгрузит в дамп. Как следствие, если при восстановлении вы используете модифицированный template1, вы должны создать пустую базу данных из template0, как показано в примере выше.

После восстановления резервной копии имеет смысл запустить ANALYZE для каждой базы данных, чтобы оптимизатор запросов получил полезную статистику; за подробностями обратитесь к Подразделу 24.1.3 и Подразделу 24.1.6. Другие советы по эффективной загрузке больших объёмов данных в PostgreSQL вы можете найти в Разделе 14.4.

25.1.2. Использование pg_dumpall

Программа pg_dump выгружает только одну базу данных в один момент времени и не включает в дамп информацию о ролях и табличных пространствах (так как это информация уровня кластера, а не самой базы данных). Для удобства создания дампа всего содержимого кластера баз данных предоставляется программа pg_dumpall, которая делает резервную копию всех баз данных кластера, а также сохраняет данные уровня кластера, такие как роли и определения табличных пространств. Простое использование этой команды:

pg_dumpall > файл_дампа

Полученную копию можно восстановить с помощью psql:

psql -f файл_дампа postgres

(В принципе, здесь в качестве начальной базы данных можно указать имя любой существующей базы, но если вы загружаете дамп в пустой кластер, обычно нужно использовать postgres). Восстанавливать дамп, который выдала pg_dumpall, всегда необходимо с правами суперпользователя, так как они требуются для восстановления информации о ролях и табличных пространствах. Если вы используете табличные пространства, убедитесь, что пути к табличным пространствам в дампе соответствуют новой среде.

pg_dumpall выдаёт команды, которые заново создают роли, табличные пространства и пустые базы данных, а затем вызывает для каждой базы pg_dump. Таким образом, хотя каждая база данных будет внутренне согласованной, состояние разных баз не будет синхронным.

Только глобальные данные кластера можно выгрузить, передав pg_dumpall ключ --globals-only. Это необходимо, чтобы полностью скопировать кластер, когда pg_dump выполняется для отдельных баз данных.

25.1.3. Управление большими базами данных

Некоторые операционные системы накладывают ограничение на максимальный размер файла, что приводит к проблемам при создании больших файлов с помощью pg_dump. К счастью, pg_dump может писать в стандартный вывод, так что вы можете использовать стандартные инструменты Unix для того, чтобы избежать потенциальных проблем. Вот несколько возможных методов:

Используйте сжатые дампы. Вы можете использовать предпочитаемую программу сжатия, например gzip:

pg_dump имя_базы | gzip > имя_файла.gz

Затем загрузить сжатый дамп можно командой:

gunzip -c имя_файла.gz | psql имя_базы

или:

cat имя_файла.gz | gunzip | psql имя_базы

Используйте split. Команда split может разбивать выводимые данные на небольшие файлы, размер которых удовлетворяет ограничению нижележащей файловой системы. Например, чтобы получить части по 1 мегабайту:

pg_dump имя_базы | split -b 1m - имя_файла

Восстановить их можно так:

cat имя_файла* | psql имя_базы

Используйте специальный формат дампа pg_dump. Если при сборке PostgreSQL была подключена библиотека zlib, дамп в специальном формате будет записываться в файл в сжатом виде. В таком формате размер файла дампа будет близок к размеру, полученному с применением gzip, но он лучше тем, что позволяет восстанавливать таблицы выборочно. Следующая команда выгружает базу данных в специальном формате:

pg_dump -Fc имя_базы > имя_файла

Дамп в специальном формате не является скриптом для psql и должен восстанавливаться с помощью команды pg_restore, например:

pg_restore -d имя_базы имя_файла

За подробностями обратитесь к справке по командам pg_dump и pg_restore.

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

Используйте возможность параллельной выгрузки в pg_dump. Чтобы ускорить выгрузку большой БД, вы можете использовать режим параллельной выгрузки в pg_dump. При этом одновременно будут выгружаться несколько таблиц. Управлять числом параллельных заданий позволяет параметр -j. Параллельная выгрузка поддерживается только для формата архива в каталоге.

pg_dump -j число -F d -f выходной_каталог имя_базы

Вы также можете восстановить копию в параллельном режиме с помощью pg_restore -j. Это поддерживается для любого архива в формате каталога или специальном формате, даже если архив создавался не командой pg_dump -j.

PostgreSQL : Документация: 11: 25.1. Выгрузка в SQL : Компания Postgres Professional

25.1. Выгрузка в SQL

Идея, стоящая за этим методом, заключается в генерации текстового файла с командами SQL, которые при выполнении на сервере пересоздадут базу данных в том же самом состоянии, в котором она была на момент выгрузки. PostgreSQL предоставляет для этой цели вспомогательную программу pg_dump. Простейшее применение этой программы выглядит так:

pg_dump имя_базы > файл_дампа

Как видите, pg_dump записывает результаты своей работы в устройство стандартного вывода. Далее будет рассмотрено, чем это может быть полезно. В то время как вышеупомянутая команда создаёт текстовый файл, pg_dump может создать файлы и в других форматах, которые допускают параллельную обработку и более гибкое управление восстановлением объектов.

Программа pg_dump является для PostgreSQL обычным клиентским приложением (хотя и весьма умным). Это означает, что вы можете выполнять процедуру резервного копирования с любого удалённого компьютера, если имеете доступ к нужной базе данных. Но помните, что pg_dump не использует для своей работы какие-то специальные привилегии. В частности, ей обычно требуется доступ на чтение всех таблиц, которые вы хотите выгрузить, так что для копирования всей базы данных практически всегда её нужно запускать с правами суперпользователя СУБД. (Если у вас нет достаточных прав для резервного копирования всей базы данных, вы, тем не менее, можете сделать резервную копию той части базы, доступ к которой у вас есть, используя такие параметры, как -n схема или -t таблица.)

Указать, к какому серверу должна подключаться программа pg_dump, можно с помощью аргументов командной строки -h сервер и -p порт. По умолчанию в качестве сервера выбирается localhost или значение, указанное в переменной окружения PGHOST. Подобным образом, по умолчанию используется порт, заданный в переменной окружения PGPORT, а если она не задана, то порт, указанный по умолчанию при компиляции. (Для удобства при компиляции сервера обычно устанавливается то же значение по умолчанию.)

Как и любое другое клиентское приложение PostgreSQL, pg_dump по умолчанию будет подключаться к базе данных с именем пользователя, совпадающим с именем текущего пользователя операционной системы. Чтобы переопределить имя, либо добавьте параметр -U, либо установите переменную окружения PGUSER. Помните, что pg_dump подключается к серверу через обычные механизмы проверки подлинности клиента (которые описываются в Главе 20).

Важное преимущество pg_dump в сравнении с другими методами резервного копирования, описанными далее, состоит в том, что вывод pg_dump обычно можно загрузить в более новые версии PostgreSQL, в то время как резервная копия на уровне файловой системы и непрерывное архивирование жёстко зависят от версии сервера. Также, только метод с применением pg_dump будет работать при переносе базы данных на другую машинную архитектуру, например, при переносе с 32-битной на 64-битную версию сервера.

Дампы, создаваемые pg_dump, являются внутренне согласованными, то есть, дамп представляет собой снимок базы данных на момент начала запуска pg_dump. pg_dump не блокирует другие операции с базой данных во время своей работы. (Исключение составляют операции, которым нужна исключительная блокировка, как например, большинство форм команды ALTER TABLE.)

25.1.1. Восстановление дампа

Текстовые файлы, созданные pg_dump, предназначаются для последующего чтения программой psql. Общий вид команды для восстановления дампа:

psql имя_базы < файл_дампа

где файл_дампа — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_базы, не будет создана данной командой, так что вы должны создать её сами из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 имя_базы). Программа psql принимает параметры, указывающие сервер, к которому осуществляется подключение, и имя пользователя, подобно pg_dump. За дополнительными сведениями обратитесь к справке по psql. Дампы, выгруженные не в текстовом формате, восстанавливаются утилитой pg_restore.

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

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

psql --set ON_ERROR_STOP=on имя_базы < файл_дампа

В любом случае вы получите только частично восстановленную базу данных. В качестве альтернативы можно указать, что весь дамп должен быть восстановлен в одной транзакции, так что восстановление либо полностью выполнится, либо полностью отменится. Включить данный режим можно, передав psql аргумент -1 или --single-transaction. Выбирая этот режим, учтите, что даже незначительная ошибка может привести к откату восстановления, которое могло продолжаться несколько часов. Однако, это всё же может быть предпочтительней, чем вручную вычищать сложную базу данных после частично восстановленного дампа.

Благодаря способности pg_dump и psql писать и читать каналы ввода/вывода, можно скопировать базу данных непосредственно с одного сервера на другой, например:

pg_dump -h host1 имя_базы | psql -h host2 имя_базы

Важно

Дампы, которые выдаёт pg_dump, содержат определения относительно template0. Это означает, что любые языки, процедуры и т. п., добавленные в базу через template1, pg_dump также выгрузит в дамп. Как следствие, если при восстановлении вы используете модифицированный template1, вы должны создать пустую базу данных из template0, как показано в примере выше.

После восстановления резервной копии имеет смысл запустить ANALYZE для каждой базы данных, чтобы оптимизатор запросов получил полезную статистику; за подробностями обратитесь к Подразделу 24.1.3 и Подразделу 24.1.6. Другие советы по эффективной загрузке больших объёмов данных в PostgreSQL вы можете найти в Разделе 14.4.

25.1.2. Использование pg_dumpall

Программа pg_dump выгружает только одну базу данных в один момент времени и не включает в дамп информацию о ролях и табличных пространствах (так как это информация уровня кластера, а не самой базы данных). Для удобства создания дампа всего содержимого кластера баз данных предоставляется программа pg_dumpall, которая делает резервную копию всех баз данных кластера, а также сохраняет данные уровня кластера, такие как роли и определения табличных пространств. Простое использование этой команды:

pg_dumpall > файл_дампа

Полученную копию можно восстановить с помощью psql:

psql -f файл_дампа postgres

(В принципе, здесь в качестве начальной базы данных можно указать имя любой существующей базы, но если вы загружаете дамп в пустой кластер, обычно нужно использовать postgres). Восстанавливать дамп, который выдала pg_dumpall, всегда необходимо с правами суперпользователя, так как они требуются для восстановления информации о ролях и табличных пространствах. Если вы используете табличные пространства, убедитесь, что пути к табличным пространствам в дампе соответствуют новой среде.

pg_dumpall выдаёт команды, которые заново создают роли, табличные пространства и пустые базы данных, а затем вызывает для каждой базы pg_dump. Таким образом, хотя каждая база данных будет внутренне согласованной, состояние разных баз не будет синхронным.

Только глобальные данные кластера можно выгрузить, передав pg_dumpall ключ --globals-only. Это необходимо, чтобы полностью скопировать кластер, когда pg_dump выполняется для отдельных баз данных.

25.1.3. Управление большими базами данных

Некоторые операционные системы накладывают ограничение на максимальный размер файла, что приводит к проблемам при создании больших файлов с помощью pg_dump. К счастью, pg_dump может писать в стандартный вывод, так что вы можете использовать стандартные инструменты Unix для того, чтобы избежать потенциальных проблем. Вот несколько возможных методов:

Используйте сжатые дампы. Вы можете использовать предпочитаемую программу сжатия, например gzip:

pg_dump имя_базы | gzip > имя_файла.gz

Затем загрузить сжатый дамп можно командой:

gunzip -c имя_файла.gz | psql имя_базы

или:

cat имя_файла.gz | gunzip | psql имя_базы

Используйте split. Команда split может разбивать выводимые данные на небольшие файлы, размер которых удовлетворяет ограничению нижележащей файловой системы. Например, чтобы получить части по 1 мегабайту:

pg_dump имя_базы | split -b 1m - имя_файла

Восстановить их можно так:

cat имя_файла* | psql имя_базы

Используйте специальный формат дампа pg_dump. Если при сборке PostgreSQL была подключена библиотека zlib, дамп в специальном формате будет записываться в файл в сжатом виде. В таком формате размер файла дампа будет близок к размеру, полученному с применением gzip, но он лучше тем, что позволяет восстанавливать таблицы выборочно. Следующая команда выгружает базу данных в специальном формате:

pg_dump -Fc имя_базы > имя_файла

Дамп в специальном формате не является скриптом для psql и должен восстанавливаться с помощью команды pg_restore, например:

pg_restore -d имя_базы имя_файла

За подробностями обратитесь к справке по командам pg_dump и pg_restore.

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

Используйте возможность параллельной выгрузки в pg_dump. Чтобы ускорить выгрузку большой БД, вы можете использовать режим параллельной выгрузки в pg_dump. При этом одновременно будут выгружаться несколько таблиц. Управлять числом параллельных заданий позволяет параметр -j. Параллельная выгрузка поддерживается только для формата архива в каталоге.

pg_dump -j число -F d -f выходной_каталог имя_базы

Вы также можете восстановить копию в параллельном режиме с помощью pg_restore -j. Это поддерживается для любого архива в формате каталога или специальном формате, даже если архив создавался не командой pg_dump -j.

Как сделать резервную копию баз данных PostgreSQL на Ubuntu?

Все админы делятся на 2 категории

— те которые уже делают бэкап

и те которые ещё не делают.

• Что такое PostgreSQL?

PostgreSQL является современной системой управления базами данных, часто используемая для хранения и обработки информации, связанной с веб-сайтами или сторонними приложениями. У любой базы данных, важно вовремя реализовать резервное копирование, чтобы избежать возможную потерю данных.

В этом посте я постараюсь рассказать о некоторых способах, которыми вы можете сделать резервную копию PostgreSQL. Для тестов будем использовать Ubuntu 12,04 VPS с PostgreSQL 9.1. Для большинства современных дистрибутивов и последних версии PostgreSQL мои советы будут актуальны.

• Создание резервной копии PostgreSQL при помощи pg_dump

PostgreSQL включает в себя утилиту под названием «pg_dump», которая позволяет сделать дамп базы данных в файл. Утилита консольная, синтаксис достаточно простой:

pg_dump name_of_database > name_of_backup_file

Команда должна быть запущена под пользователем с привилегиями на чтение базы данных.

Как вариант мы можем войти через sudo под пользователем «рostgres» и выполнить команду:

sudo su - postgres
pg_dump postgres > postgres_db.bak

«pg_dump» — это «полноценный» клиент PostgreSQL, т.е. при необходимости её можно запустить с удаленной машины, если имеются соответствующие разрешения к базе данных.

Расширенный синтаксис выглядит следующим образом:

pg_dump -h remote_host -p remote_port name_of_database > name_of_backup_file
pg_dump -U user_name -h remote_host -p remote_port name_of_database > name_of_backup_file

• Как восстановить дампы  pg_dump в PostgreSQL

Чтобы восстановить резервную копию, созданную pg_dump, необходимо перенаправить файл с дампом в стандартный ввод psql:

psql empty_database < backup_file

Эта операция не создает новую базу данных. Об этом необходимо позаботиться заранее.

Для примера, создадим новую базу данных под названием «restored_database», а затем развернем дамп под названием «database.bak»:

createdb -T template0 restored_database
psql restored_database < database.bak

Пустая база данных должна быть создана при помощи шаблона «template0«. Так же нам необходимо убедиться в наличии пользователя с необходимыми правами на создаваемую базу, в противном случае нам придется создать нового:

createuser test_user
psql restored_database < database.bak

• Возможные ошибки

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

psql --set ON_ERROR_STOP=on restored_database < backup_file

С данной опцией мы получим частично восстановленную базу данных.

Можно попробовать восстановить весь дамп в одну транзацию, т.е. бекап будет или полностью восстановлен или не восстановлен совсем. Данный режим может быть задан, с помощью опций -1 или —single-transaction для psql.

psql -1 restored_database < backup_file

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

• Резервное копирование и восстановление всех баз данных в PostgreSQL

Чтобы сэкономить время, можно сделать резервную копию всех баз данных в вашей системе, при помощи утилиты «pg_dumpall»:

pg_dumpall > backup_file

Похожим способом можно восстановить базы данных:

psql -f backup_file postgres

Резервные копии являются важным аспектом при любой работе с данными. К счастью, PostgreSQL включает утилиты, необходимые для эффективного резервного копирования важной информации. Как с любым видом резервного копирования, важно регулярно проверять свои резервные копии.

В качестве дополнения скрипт, который создает резервную копию с меткой времени и сохраняет последние 14 резервных копий:

ls -t *.sql | sed -e '1,13d' | xargs -d '\n' rm
echo Done at `date +\%Y-\%m-\%d_\%T`
pg_dump dbname --username=dbuser > `date +\%Y-\%m-\%d_\%T`.sql

Вы можете оставить комментарий ниже.

Как восстановить базу данных PostgreSQL из архива | Info-Comp.ru

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

Чуть ранее мы с Вами рассмотрели возможность создания резервной копии базы данных PostgreSQL в материале Как создать архив базы PostgreSQL, а теперь пора научиться восстанавливать базы из backup.

Если Вы знаете, как создается backup в PostgreSQL, то понимаете, что это делается достаточно просто, поэтому и восстановить базу также не составит труда.

Мы с Вами рассматривали два варианта создания архива, через графический интерфейс pgAdmin и через командную строку, поэтому и восстанавливать мы будем также двумя способами. Только в отличие от создания backup, через батник (для ежедневной автоматической архивации) который нам был нужен практически только для того, чтобы автоматизировать этот процесс и забыть про него, при восстановлении нам такая автоматизация не нужна, так как не каждый день приходится восстанавливать базу данных. Но мы все равно рассмотрим вариант через bat-файл, только для того чтобы Вы знали, как это делается и в случае необходимости оперативно восстановили базу, путем простого запуска батника, так как через графический интерфейс, согласитесь, займет немного больше времени.

Итак, приступим, если Вы помните, что при архивации использовалась утилита pg_dump.exe, то при восстановлении используется утилита pg_restore.exe

Примечание! Как и при создании архива, в качестве примера мы использовали локальный сервер PostgreSQL 8.4, на Windows 7, так и сегодня мы будем использовать именно данные версии СУБД и ОС.

Восстанавливаем базу через pgAdmin

Открываем pgAdmin, подключаемся к серверу, выбираем правой кнопкой мыши базу, и щелкаем «Восстановить»

Затем открывается окно восстановления базы, где Вы можете задать параметры восстановления, в частности выбрать архив, я здесь поставил галочку «Очистить перед восстановлением» так как если ее не ставить достаточно часто база восстанавливается с ошибкой (но все равно восстанавливается), и жмем «ОК»

После Вам останется, дождаться восстановления и нажать кнопку «Завершить»

Восстанавливаем базу с помощью батника

Для этого открываем блокнот (удобней Notepad++) и вставляем в него следующие команды (символ ^ это перенос строки):

 "C:/Program Files/PostgreSQL/8.4/bin\pg_restore.exe" ^
 --host localhost --port 5432 --username postgres ^
 --dbname test --clean --verbose "C:\temp\test_backup.backup"

Где, не трудно догадаться  первая строка это запуск утилиты, вторая это подключение к серверу, третья выбор базы для восстановления, параметры восстановления и соответственно из чего это все восстанавливать. Только одно замечание, при восстановлении проверьте путь к архиву, т.е. необходимо выбрать актуальный архив на момент восстановления, чтобы не получилось ситуации, когда Вы якобы восстановили базу, только скажем прошлогодней версии, а пользователи смотрят и удивляются:)

Нам останется только сохранить этот текстовый документ с расширением .bat и проверить его работу.

Как видите, восстанавливать базу не так страшно как кажется.

Заметка! Как перенести базу данных PostgreSQL на другой сервер с помощью pgAdmin 4.

На сегодня все, в следующих статьях мы будем рассматривать, как можно создавать и восстанавливать backup базы данных, но только уже на СУБД MSSql 2008.

Нравится3Не нравится

PostgreSQL : Документация: 9.4: Выгрузка в SQL : Компания Postgres Professional

Идея, стоящая за этим методом, заключается в генерации текстового файла с командами SQL, которые при выполнении на сервере пересоздадут базу данных в том же самом состоянии, в котором она была на момент выгрузки. PostgreSQL предоставляет для этой цели вспомогательную программу pg_dump. Простейшее применение этой программы выглядит так:

pg_dump имя_базы > выходной_файл

Как видите, pg_dump записывает результаты своей работы в устройство стандартного вывода. Далее будет рассмотрено, чем это может быть полезно. В то время как вышеупомянутая команда создаёт текстовый файл, pg_dump может создать файлы и в других форматах, которые допускают параллельную обработку и более гибкое управление восстановлением объектов.

Программа pg_dump является для PostgreSQL обычным клиентским приложением (хотя и весьма умным). Это означает, что вы можете выполнять процедуру резервного копирования с любого удалённого компьютера, если имеете доступ к нужной базе данных. Но помните, что pg_dump не использует для своей работы какие-то специальные привилегии. В частности, ей обычно требуется доступ на чтение всех таблиц, которые вы хотите выгрузить, так что для копирования всей базы данных практически всегда её нужно запускать с правами суперпользователя СУБД. (Если у вас нет достаточных прав для резервного копирования всей базы данных, вы, тем не менее, можете сделать резервную копию той части базы, доступ к которой у вас есть, используя такие параметры, как -n схема или -t таблица.)

Указать, к какому серверу должна подключаться программа pg_dump, можно с помощью аргументов командной строки -h сервер и -p порт. По умолчанию в качестве сервера выбирается localhost или значение, указанное в переменной окружения PGHOST. Подобным образом, по умолчанию используется порт, заданный в переменной окружения PGPORT, а если она не задана, то порт, указанный по умолчанию при компиляции. (Для удобства при компиляции сервера обычно устанавливается то же значение по умолчанию.)

Как и любое другое клиентское приложение PostgreSQL, pg_dump по умолчанию будет подключаться к базе данных с именем пользователя, совпадающим с именем текущего пользователя операционной системы. Чтобы переопределить имя, либо добавьте параметр -U, либо установите переменную окружения PGUSER. Помните, что pg_dump подключается к серверу через обычные механизмы проверки подлинности клиента (которые описываются в Главе 19).

Важное преимущество pg_dump в сравнении с другими методами резервного копирования, описанными далее, состоит в том, что вывод pg_dump обычно можно загрузить в более новые версии PostgreSQL, в то время как резервная копия на уровне файловой системы и непрерывное архивирование жёстко зависят от версии сервера. Также, только метод с применением pg_dump будет работать при переносе базы данных на другую машинную архитектуру, например, при переносе с 32-битной на 64-битную версию сервера.

Дампы, создаваемые pg_dump, являются внутренне согласованными, то есть, дамп представляет собой снимок базы данных на момент начала запуска pg_dump. pg_dump не блокирует другие операции с базой данных во время своей работы. (Исключение составляют операции, которым нужна исключительная блокировка, как например, большинство форм команды ALTER TABLE.)

Текстовые файлы, созданные pg_dump предназначаются для последующего чтения программой psql. Общий вид команды для восстановления дампа:

psql имя_базы < входной_файл

где входной_файл — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_базы, не будет создана данной командой, так что вы должны создать её сами из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 имя_базы). Программа psql принимает параметры, указывающие сервер, к которому осуществляется подключение, и имя пользователя, подобно pg_dump. За дополнительными сведениями обратитесь к справке по pg_restore. Копии не текстовые восстанавливаются утилитой pg_restore.

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

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

psql --set ON_ERROR_STOP=on имя_базы < входной_файл

В любом случае, вы получите только частично восстановленную базу данных. В качестве альтернативы можно указать, что весь дамп должен быть восстановлен в одной транзакции, так что восстановление либо полностью выполнится, либо полностью отменится. Включить данный режим можно, передав psql аргумент -1 или —single-transaction. Выбирая этот режим, учтите, что даже незначительная ошибка может привести к откату восстановления, которое могло продолжаться несколько часов. Однако, это всё же может быть предпочтительней, чем вручную вычищать сложную базу данных после частично восстановленного дампа.

Благодаря способности pg_dump и psql писать и читать каналы ввода/вывода, можно скопировать базу данных непосредственно с одного сервера на другой, например:

pg_dump -h host1 имя_базы | psql -h host2 имя_базы

Важно: Дампы, которые выдаёт pg_dump, содержат определения относительно template0. Это означает, что любые языки, процедуры и т. п., добавленные в базу через template1, pg_dump также выгрузит в дамп. Как следствие, если при восстановлении вы используете модифицированный template1, вы должны создать пустую базу данных из template0, как показано в примере выше.

После восстановления резервной копии имеет смысл запустить ANALYZE для каждой базы данных, чтобы оптимизатор запросов получил полезную статистику; за подробностями обратитесь к Подразделу 23.1.3 и Подразделу 23.1.6. Другие советы по эффективной загрузке больших объёмов данных в PostgreSQL вы можете найти в Разделе 14.4.

Программа pg_dump выгружает только одну базу данных в один момент времени и не включает в дамп информацию о ролях и табличных пространствах (так как это информация уровня кластера, а не самой базы данных). Для удобства создания дампа всего содержимого кластера баз данных предоставляется программа pg_dumpall , которая делает резервную копию всех баз данных кластера, а также сохраняет данные уровня кластера, такие как роли и определения табличных пространств. Простое использование этой команды:

pg_dumpall > выходной_файл

Полученную копию можно восстановить с помощью psql:

psql -f входной_файл postgres

(В принципе, здесь в качестве начальной базы данных можно указать имя любой существующей базы, но если вы загружаете копию в пустой кластер, обычно нужно использовать postgres). Восстанавливать дамп, который выдала pg_dumpall, всегда необходимо с правами суперпользователя, так как они требуются для восстановления информации о ролях и табличных пространствах. Если вы используете табличные пространства, убедитесь, что пути к табличным пространствам в дампе соответствуют новой среде.

pg_dumpall выдаёт команды, которые заново создают роли, табличные пространства и пустые базы данных, а затем вызывает для каждой базы pg_dump. Таким образом, хотя каждая база данных будет внутренне согласованной, состояние разных баз не будет синхронным.

Только глобальные данные кластера можно выгрузить, передав pg_dumpall ключ —globals-only. Это необходимо, чтобы полностью скопировать кластер, когда pg_dump выполняется для отдельных баз данных.

Некоторые операционные системы накладывают ограничение на максимальный размер файла, что приводит к проблемам при создании больших файлов с помощью pg_dump. К счастью, pg_dump может писать в стандартный вывод, так что вы можете использовать стандартные инструменты Unix для того, чтобы избежать потенциальных проблем. Вот несколько возможных методов:

Используйте сжатые дампы. Вы можете использовать предпочитаемую программу сжатия, например gzip:

pg_dump имя_базы | gzip > имя_файла.gz

Затем загрузить сжатый дамп можно командой:

gunzip -c имя_файла.gz | psql имя_базы

или:

cat имя_файла.gz | gunzip | psql имя_базы

Используйте split. Команда split может разбивать выводимые данные на небольшие файлы, размер которых удовлетворяет ограничению нижележащей файловой системы. Например, чтобы получить части по 1 мегабайту:

pg_dump имя_базы | split -b 1m - имя_файла

Восстановить их можно так:

cat имя_файла* | psql имя_базы

Используйте специальный формат дампа pg_dump. Если при сборке PostgreSQL была подключена библиотека zlib, дамп в специальном формате будет записываться в файл в сжатом виде. В таком формате размер файла дампа будет близок к размеру, полученному с применением gzip, но он лучше тем, что позволяет восстанавливать таблицы выборочно. Следующая команда выгружает базу данных в специальном формате:

pg_dump -Fc имя_базы > имя_файла

Дамп в специальном формате не является скриптом для psql и должен восстанавливаться с помощью команды pg_restore, например:

pg_restore -d имя_базы имя_файла

За подробностями обратитесь к справке по командам pg_dump и pg_restore.

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

Используйте возможность параллельной выгрузки в pg_dump. Чтобы ускорить выгрузку большой БД, вы можете использовать режим параллельной выгрузки в pg_dump. При этом одновременно будут выгружаться несколько таблиц. Управлять числом параллельных заданий позволяет параметр -j. Параллельная выгрузка поддерживается только для формата архива в каталоге.

pg_dump -j число -F d -f выходной_каталог имя_базы

Вы также можете восстановить копию в параллельном режиме с помощью pg_restore -j. Это поддерживается для любого архива в формате каталога или специальном формате, даже если архив создавался не командой pg_dump -j.

Резервное копирование и восстановление в PostgreSQL

Посвящается Владимиру Габриелю

Ушел из жизни молодым Владимир Габриель. Этот замечательный человек сделал много для развития экосистемы свободного программного обеспечения в России. Работая в Microsoft, Владимир проводил тематические конференции по свободному программному обеспечению, на которые приглашались местные российские хакеры, в число которых попадал и я. С одной стороны, конечно, на этих конференциях решались корпоративные задачи компании Microsoft, шла реклама технологий, технологических платформ и мировоззрений. С другой стороны, организаторы не боялись привезти в Россию лидеров сообществ и компаний, занимавшихся свободным ПО, — Брайана Беклендорфа, Эрика Рэймонда, Эндрю Мортона, Мигеля де Иказу, Мэтта Эсея. Образования и общения с живыми иконами не хватало, поэтому подобные конференции были для нас, как глоток свежего воздуха.

Владимир работал на этих конференциях не с самой удобной, с протестной аудиторией. И добивался результата — пусть с ним не соглашались, но запоминали. Можно рассматривать и компанию Датавед, как попытку экспериментальной проверки острых, иногда жестких и неудобных, вопросов и тем, поднимавшихся Владимиром на этих конференциях. Причем же здесь PostgreSQL?

В октябре Владимир участвовал в подготовке небольшого технического текста для нашего сайта, посвященного организации резервного копирования в свободной СУБД PostgreSQL. Может быть в тексте обсуждаются и не самые оригинальные вопросы, но зато вечные.

PostgreSQL предлагает несколько режимов резервного копирования и восстановления баз данных (БД). Поскольку БД располагаются в файловой системе, вполне нормальным методом является резервное копирование на уровне файлов, то есть копирование самого каталога, где размещаются файлы БД. Единственное условие для использования такого режима — полный останов сервера PostgreSQL.

Для систем высокой готовности такой режим резервного копирования не подойдет. Поэтому PostgreSQL позволяет выполнять резервное копирование при запущенном сервере, не прерывая его обычной работы. Наиболее простой режим — это получение дампа БД в текстовом виде (в форме операторов SQL). Для экономии дискового пространства можно сразу же сжимать такой дамп утилитой сжатия (например, gzip). Также существует возможность создания дампа БД в двоичной форме, а также возможность задавать специальные параметры для большего удобства в получении резервной копии и её последующего восстановления.

PostgreSQL также предоставляет возможность резервного копирования в реальном времени посредством Write-Ahead Log (WAL). За счет этого возможно восстановление содержания БД на конкретный момент времени, а также инкрементальное резервное копирование.

Дамп SQL

Идея метода дампа заключается в генерации текстового файла с командами SQL, которые при выполнении на сервере, пересоздадут базу данных в том же самом состоянии, в котором она была на момент создания дампа. PostgreSQL предоставляет для этой цели програмнную утилиту pg_dump. Базовый сценарий вызова данной команды для записи дампа базы bd_name в файл dump.sql выглядит так:

pg_dump bd_name > dump.sql

Утилита pg_dump является для PostgreSQL обычным клиентским приложением. Это означает, что можно выполнять процедуру резервного копирования с любого удалённого компьютера, который имеет доступ к нужной базе данных. Так как утилите pg_dump необходим доступ на чтение всех таблиц, резервную копию которых необходимо сделать, её почти всегда нужно запускать с правами суперпользователя СУБД.

Чтобы указать, к какому серверу должен подключаться pg_dump, необходимо использовать опцию командной строки -h server_name -p port_num. По умолчанию в качестве сервера выбирается localhost или же тот сервер, который указан в переменной окружения PGHOST. Подобным образом, в качестве порта по умолчанию используется порт, указанный в переменной окружения PGPORT или, если переменная не задана, то порт, указанный по умолчанию при компиляции, как правило, 5432.

Как и любое другое клиентское приложение PostgreSQL, pg_dump по умолчанию будет подключаться к базе данных под пользователем, имя которого совпадает с именем текущего пользователя операционной системы. Чтобы изменить это, необходимо либо указать опцию -U, либо установить переменную окружения PGUSER. Подключения, которые выполняет pg_dump, работают с учётом обычных механизмов авторизации — для доступа может потребоваться пароль, или тикет Kerberos, или иная аутентификационная информация.

Важное преимущество pg_dump над другими методами резервного копирования состоит в том, что вывод pg_dump может быть обычно перезагружен в более новые версии PostgreSQL, в то время как резервная копия на уровне файловой системы и непрерывное архивирование жёстко зависят от версии сервера. Также, только pg_dump является методом, который будет работать при переносе базы данных на другую машинную архитектуру, например, при переносе с 32-битной на 64-битную версию сервера.

Дампы, создаваемые pg_dump, являются внутренне целостными, что означает, что дамп представляет собой снимок базы данных на момент начала запуска pg_dump. pg_dump не блокирует другие операции с базой данных во время своей работы. Исключениями являются случаи, когда есть необходимость работы с эксклюзивной блокировкой, как у большинства форм команды ALTER TABLE.

Важное замечание. Если Ваша схема базы данных полагается на идентификаторы OID (например, для связывания, как внешние ключи), необходимо указать pg_dump, чтобы в дамп были также включены OID посредством опцию командной строки -o.

Восстановление дампа

Текстовые файлы, созданные pg_dump, предназначаются для последующего чтения программой psql. Общий вид команды для восстановления базы bd_name из файла дампа dump.sql:

psql bd_name < dump.sql

База данных, заданная параметром bd_name не будет создана данной командой. Необходимо создать её из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 bd_name). Аналогично pg_dump, команда psql позволяет указать сервер, к которому осуществляется подключение и имя пользователя, от имени которого осуществляется подключение.

Перед восстановлением SQL дампа все пользователи, которые владеют объектами или имеют права на объекты в базе данных, выгруженной в дамп, должны уже существовать. Если их нет, при восстановлении будут ошибки пересоздания объектов с оригинальными владельцами и/или правами. (Иногда, это и есть то, что Вы хотите, но обычно нет).

По умолчанию, если произойдёт ошибка SQL, программа psql продолжит своё выполнение. Можно запустить psql с установленной переменной ON_ERROR_STOP, чтобы изменить такое поведение и заставить psql выйти с кодом выхода 3, в случае возникновения ошибки SQL:

psql --set ON_ERROR_STOP=on bd_name   

В любом случае, будет только частичное восстановление базы данных. В качестве альтернативы, можно указать, что весь дамп должен быть восстановлен в одну транзацию, так что восстановление или будет полностью выполнено или полностью не выполнено. Данный режим может быть задан, с помощью опций командной строки -1 или single-transaction для  psql. Когда используется этот режим, необходимо проявлять осторожность, т.к. даже маленькая ошибка может привести к откату процесса восстановления, который может продолжаться несколько часов. Однако это может быть предпочтительней, чем ручная чистка сложной базы данных после частично восстановленного дампа. 

Возможность  pg_dump  и  psql  писать и читать из конвееров делают возможным создание дампа базы данных напрямую с одного сервера на другой. 

Например: 
 pg_dump -h сервер1 bd_name | psql -h сервер2 bd_name
Important: Дампы, которые делает  pg_dump, являются относительными  template0. Это означает, что любые языки, процедуры и т.д. добавленные через  template1, также попадут в дамп при выполнении  pg_dump. В итоге, при восстановлении, если Вы использовали специально изменённый  template1, Вы должны создать пустую базу данных из  template0, как показано в примере выше.
После восстановления резервной копии, следует запустить команду ANALYZE на каждую базу данных, чтобы оптимизатор запросов получил нужную статистику.
Использование утилиты pg_dumpall
pg_dump делает дамп только одной базы данных в один момент времени и не включает в дамп информацию о ролях или табличных пространствах (потому что эти данные относятся к уровню кластера, а не к самой базе данных). Дамп всего кластера баз данных создается утилитой pg_dumpall. pg_dumpall делает резервную копию каждой базы данных кластера, а также сохраняет данные уровня кластера, включая роли и определения табличных пространств. Базовая форма использования этой команды:
pg_dumpall >  dump.sql
Результирующий дамп может быть восстановлен с помощью psql:
psql –f dump.sql  postgres
Можно указать любые имена существующих баз данных, чтобы начать восстановление. Если вы производите загрузку в пустой кластер, то нужно использовать postgres. При восстановлении дампа, сделанного pg_dumpall, всегда необходимо выполнять восстановление с правами суперпользователя баз данных, потому,  что они требуются для восстановления ролей и информации о табличных пространствах. Если Вы используете табличные пространства, убедитесь, что пути к табличным пространствам в дампе соответствуют новой установке.
pg_dumpall получает и выдаёт команды для пересоздания ролей, табличных пространств и пустых баз данных, затем вызывает для каждой базы данных pg_dump. Это означает, что в то время, как каждая база данных будет внутренне целостной, снимки других баз данных могут не быть точно синхронизированы.
Управление большими базами данных
Некоторые операционные системы имеют ограничение на максимальный размер файла, что приводит к проблемам при создании больших файлов с помощью  pg_dump. К счастью,  pg_dump может писать на стандартный вывод, и можно использовать стандартные инструменты Unix  для того, чтобы избежать потенциальных проблем. Вот несколько возможных методов:
Используйте сжатые дампы. Можно использовать любимую программу сжатия, например gzip:
pg_dump bd_name | gzip > dump.sql.gz
Загружая впоследствии сжатый дамп командой:
gunzip -c dump.sql.gz | psql bd_name
Или
cat  dump.sql.gz | gunzip | psql bd_name
Используйте split. Команда  split позволяет Вам разбивать вывод на файлы меньшего размера, которые не попадают под ограничения на максимальный размер файла в файловой системе. Например, чтобы нарезать дамп на кусочки по 1 мегабайту:
pg_dump bd_name | split -b 1m - dump.sql
Загружая впоследствии полученные файлы командой:
cat dump.sql* | psql bd_name
Используйте специальный формат дампа в pg_dump. Если PostgreSQL была скомпилирована в системе с установленной библиотекой zlib, то специальный формат дампа будет сжимать данные, которые выдаются в файл вывода. Это приведёт к созданию файла дампа, который по размеру будет похож на дамп, сжатый gzip, но такой формат будет иметь преимущество, потому что позволяет выборочное восстановление таблиц. Следующая команда делает дамп базы данных, используя специальный формат дампа:
pg_dump -Fc bd_name > dump.sql
Специальный формат дампа не является скриптом для psql и должен восстанавливаться с помощью команды pg_restore, например:
pg_restore –d bd_name dump.sql
Для очень больших баз данных, нужно сочетать split с одним из двух других методов. См. подробности на страницах справочного руководства  pg_dump и pg_restore.
 PostgreSQL Restore Database 
  Summary : в этом руководстве вы узнаете, как восстановить базу данных с помощью  инструментов восстановления PostgreSQL , включая  pg_restore  и  psql .
 Перед восстановлением базы данных необходимо разорвать все подключения к этой базе данных и подготовить файл резервной копии. В PostgreSQL вы можете восстановить базу данных двумя способами:
 Использование  psql  для восстановления простого файла сценария SQL, созданного инструментами  pg_dump  и  pg_dumpall .
 Использование  pg_restore  для восстановления tar-файла и формата каталога, созданного инструментом  pg_dump .
 Как восстановить базы данных с помощью psql 
 Инструмент  psql  позволяет восстановить файл сценария SQL, созданный  pg_dump ,  pg_dumpall  или любыми другими инструментами, которые генерируют совместимые файлы резервных копий. Используя инструмент  psql , вы можете выполнить весь сценарий в файле дампа.
 Чтобы восстановить полную резервную копию и проигнорировать любые ошибки, возникшие в процессе восстановления, используйте следующую команду:
 
  psql -U username -f backupfile.sql  
 
 Если вы хотите остановить восстановление базы данных в случае ошибок, вы добавляете  --set ON_ERROR_STOP = в опцию :
 
  psql -U username --set ON_ERROR_STOP = on -f backupfile  
 
 Если вы создаете резервную копию объектов в конкретной базе данных, вы можете восстановить их с помощью следующей команды:
 
  psql -U имя пользователя -d имя_базы_данных -f objects.sql  
 
 Как восстановить базы данных с помощью pg_restore 
 Кроме того  psql , вы можете использовать программу  pg_restore  для восстановления баз данных, зарезервированных с помощью инструментов  pg_dump  или  pg_dumpall .С программой  pg_restore  у вас есть различные варианты для восстановления баз данных, например:
  pg_restore  позволяет выполнять параллельное восстановление с помощью опции  -j , чтобы указать количество потоков для восстановления. Каждый поток одновременно восстанавливает отдельную таблицу, что значительно ускоряет процесс. В настоящее время  pg_restore  поддерживает эту опцию для единственного настраиваемого формата файла.
  pg_restore  также позволяет восстанавливать определенные объекты базы данных в файле резервной копии, который содержит полную базу данных.
  pg_restore  может выполнять резервное копирование базы данных в более старой версии и восстанавливать ее в более новой версии.
 Давайте создадим новую базу данных с именем  newdvdrental  для практики с инструментом  pg_restore .
 
  СОЗДАТЬ БАЗУ ДАННЫХ newdvdrental;  
 
 Вы можете восстановить базу данных  dvdrental  в формате файлов  tar , созданную инструментом  pg_dump  в руководстве по резервному копированию базы данных PostgreSQL, используя следующую команду:
 
  pg_restore --dbname = newdvdrental --verbose c : \ pgbackup \ dvdrental.tar  
 
 Если вы восстанавливаете базу данных, аналогичную той, в которой вы сделали резервную копию, вы можете использовать следующую команду:
 
  pg_restore --dbname = dvdrental --create --verbose c: \ pgbackup \ dvdrental.tar  
 
 Начиная с PostgreSQL 9.2, вы можете использовать параметр  --section  только для восстановления структуры таблицы. Это позволяет вам использовать новую базу данных в качестве шаблона для создания других баз данных.
 Сначала создайте новую базу данных с именем  dvdrental_tpl .
 
  СОЗДАТЬ БАЗУ ДАННЫХ dvdrental_tpl;  
 
 Во-вторых, восстановите структуру таблицы только из файла резервной копии  dvdrental.tar , используя следующую команду:
 
 > pg_restore --dbname = dvdrental_tpl --section = pre-data c: \ pgbackup \ dvdrental .tar  
 
 Дополнительная информация 
 Было ли это руководство полезным?
 Да Нет
.
 postgresql — Как восстановить базу данных postgres в другую базу данных с именем 
 Переполнение стека
 Около
 Продукты
 Для команд
 Переполнение стека
 Общественные вопросы и ответы
 Переполнение стека для команд
 Где разработчики и технологи делятся частными знаниями с коллегами
 Вакансии
 Программирование и связанные с ним технические возможности карьерного роста
 Талант
 Нанимайте технических специалистов и создавайте свой бренд работодателя
 Реклама
 Обратитесь к разработчикам и технологам со всего мира
 О компании
 .
 PostgreSQL: Документация: 9.4: Дамп SQL 
 Идея этого метода дампа состоит в том, чтобы сгенерировать файл с командами SQL, которые при отправке обратно на сервер воссоздают базу данных в том же состоянии, в каком она была во время дампа. PostgreSQL предоставляет для этого служебную программу pg_dump. Базовое использование этой команды:
 pg_dump имя_базы> файл дампа 
 Как видите, pg_dump записывает свой результат в стандартный вывод. Ниже мы увидим, чем это может быть полезно.В то время как указанная выше команда создает текстовый файл, pg_dump может создавать файлы в других форматах, которые обеспечивают параллелизм и более точный контроль восстановления объекта.
 pg_dump — обычное клиентское приложение PostgreSQL (хотя и очень умное). Это означает, что вы можете выполнить эту процедуру резервного копирования с любого удаленного хоста, имеющего доступ к базе данных. Но помните, что pg_dump не работает с особыми разрешениями. В частности, он должен иметь доступ для чтения ко всем таблицам, для которых вы хотите создать резервную копию, поэтому для резервного копирования всей базы данных вам почти всегда нужно запускать ее как суперпользователь базы данных.(Если у вас нет достаточных прав для резервного копирования всей базы данных, вы все равно можете создавать резервные копии тех частей базы данных, к которым у вас есть доступ, используя такие параметры, как -n schema или -t table.)
 Чтобы указать, с каким сервером базы данных должен связываться pg_dump, используйте параметры командной строки -h host и -p port. Хостом по умолчанию является локальный хост или то, что указано в переменной среды PGHOST. Точно так же порт по умолчанию указывается переменной среды PGPORT или, в противном случае, компилированным по умолчанию.(Удобно, что сервер обычно имеет такое же встроенное значение по умолчанию.)
 Как и любое другое клиентское приложение PostgreSQL, pg_dump по умолчанию будет подключаться к имени пользователя базы данных, которое совпадает с именем пользователя текущей операционной системы. Чтобы изменить это, укажите параметр -U или установите переменную среды PGUSER. Помните, что соединения pg_dump подчиняются обычным механизмам аутентификации клиентов (которые описаны в главе 19).
 Важным преимуществом pg_dump перед другими описанными ниже методами резервного копирования является то, что вывод pg_dump обычно можно повторно загрузить в более новые версии PostgreSQL, тогда как резервное копирование на уровне файлов и непрерывное архивирование сильно зависят от версии сервера.pg_dump также является единственным методом, который будет работать при переносе базы данных на другую архитектуру компьютера, например, при переходе с 32-битного на 64-битный сервер.
 Дампы, создаваемые pg_dump, внутренне согласованы, то есть дамп представляет собой моментальный снимок базы данных на момент начала работы pg_dump. pg_dump не блокирует другие операции с базой данных во время ее работы. (Исключениями являются те операции, которые должны работать с монопольной блокировкой, например, большинство форм ALTER TABLE.)
 Текстовые файлы, созданные pg_dump, предназначены для чтения программой psql. Общая форма команды для восстановления дампа —
.
 psql dbname <файл дампа 
, где dumpfile - это файл, выводимый командой pg_dump. База данных dbname не будет создана этой командой, поэтому вы должны создать ее самостоятельно из template0 перед выполнением psql (например, с createdb -T template0 dbname). psql поддерживает параметры, аналогичные pg_dump, для указания сервера базы данных для подключения и имени пользователя для использования.См. Справочную страницу psql для получения дополнительной информации. Дампы нетекстовых файлов восстанавливаются с помощью утилиты pg_restore.
 Перед восстановлением дампа SQL все пользователи, владеющие объектами или которым были предоставлены права доступа к объектам в базе данных дампа, должны уже существовать. В противном случае при восстановлении не удастся воссоздать объекты с исходным владельцем и / или разрешениями. (Иногда это то, что вам нужно, но обычно это не так.)
 По умолчанию скрипт psql продолжит выполнение после обнаружения ошибки SQL.Возможно, вы захотите запустить psql с переменной ON_ERROR_STOP, установленной для изменения этого поведения, и иметь выход psql со статусом выхода 3, если возникает ошибка SQL:
 psql --set ON_ERROR_STOP = на dbname 
 В любом случае у вас будет только частично восстановленная база данных. В качестве альтернативы вы можете указать, что весь дамп должен быть восстановлен как одна транзакция, поэтому восстановление будет либо полностью завершено, либо полностью откат. Этот режим можно указать, передав в psql параметры командной строки -1 или --single-transaction.При использовании этого режима помните, что даже незначительная ошибка может откатить восстановление, которое уже выполнялось в течение многих часов. Тем не менее, это может быть предпочтительнее ручной очистки сложной базы данных после частично восстановленного дампа.
 Способность pg_dump и psql записывать или читать из каналов дает возможность выгружать базу данных напрямую с одного сервера на другой, например:
 pg_dump -h host1 dbname | psql -h host2 имя_бд 
  Важно:  Дампы, создаваемые pg_dump, относятся к template0.Это означает, что любые языки, процедуры и т. Д., Добавленные через template1, также будут сброшены pg_dump. В результате при восстановлении, если вы используете настроенный template1, вы должны создать пустую базу данных из template0, как в примере выше.
 После восстановления резервной копии целесообразно запустить ANALYZE для каждой базы данных, чтобы оптимизатор запросов имел полезную статистику; см. Раздел 23.1.3 и Раздел 23.1.6 для получения дополнительной информации. Дополнительные советы по эффективной загрузке больших объемов данных в PostgreSQL см. В Разделе 14.4.
 pg_dump выгружает только одну базу данных за раз, и он не выгружает информацию о ролях или табличных пространствах (поскольку они являются общекластерными, а не для каждой базы данных). Для поддержки удобного сброса всего содержимого кластера базы данных предоставляется программа pg_dumpall. pg_dumpall выполняет резервное копирование каждой базы данных в данном кластере, а также сохраняет данные всего кластера, такие как определения ролей и табличных пространств. Базовое использование этой команды:
 pg_dumpall> файл дампа 
 Полученный дамп можно восстановить с помощью psql:
 psql -f файл дампа postgres 
 (Фактически, вы можете указать любое существующее имя базы данных для начала, но если вы загружаете в пустой кластер, то обычно следует использовать postgres.) При восстановлении дампа pg_dumpall всегда необходимо иметь доступ суперпользователя к базе данных, так как это требуется для восстановления информации о роли и табличном пространстве. Если вы используете табличные пространства, убедитесь, что пути к табличным пространствам в дампе подходят для новой установки.
 pg_dumpall запускает команды для воссоздания ролей, табличных пространств и пустых баз данных, а затем вызывает pg_dump для каждой базы данных. Это означает, что, хотя каждая база данных будет внутренне согласованной, моментальные снимки разных баз данных не синхронизируются.
 Данные всего кластера могут быть сброшены отдельно с помощью параметра pg_dumpall --globals-only. Это необходимо для полного резервного копирования кластера при запуске команды pg_dump для отдельных баз данных.
 Некоторые операционные системы имеют ограничения на максимальный размер файла, что вызывает проблемы при создании больших выходных файлов pg_dump. К счастью, pg_dump может писать в стандартный вывод, поэтому вы можете использовать стандартные инструменты Unix для решения этой потенциальной проблемы. Есть несколько возможных методов:
  Использовать сжатые дампы. Вы можете использовать вашу любимую программу сжатия, например gzip:
 pg_dump dbname | gzip> filename.gz 
 Перезарядка с:
 gunzip -c filename.gz | psql dbname 
 или:
 cat filename.gz | gunzip | psql dbname 
  Используйте разделение.  Команда split позволяет разделить вывод на файлы меньшего размера, приемлемые по размеру для базовой файловой системы. Например, чтобы сделать куски размером 1 мегабайт:
 pg_dump dbname | split -b 1m - имя файла 
 Перезарядка с:
 имя кошки * | psql dbname 
  Используйте собственный формат дампа pg_dump. Если PostgreSQL был собран в системе с установленной библиотекой сжатия zlib, пользовательский формат дампа будет сжимать данные по мере их записи в выходной файл. Это создаст размер файла дампа, аналогичный использованию gzip, но имеет дополнительное преимущество, заключающееся в том, что таблицы можно восстанавливать выборочно. Следующая команда выводит базу данных в настраиваемом формате дампа:
 pg_dump -Fc dbname> имя файла 
 Дамп нестандартного формата не является сценарием для psql, его необходимо восстановить с помощью pg_restore, например:
 pg_restore -d dbname имя_файла 
 Подробности см. На справочных страницах pg_dump и pg_restore.
 Для очень больших баз данных вам может потребоваться объединить разделение с одним из двух других подходов.
  Используйте функцию параллельного дампа pg_dump.  Чтобы ускорить создание дампа большой базы данных, вы можете использовать параллельный режим pg_dump. Это приведет к сбросу нескольких таблиц одновременно. Вы можете контролировать степень параллелизма с помощью параметра -j. Параллельные дампы поддерживаются только для формата архива «каталог».
 pg_dump -j число -F d -f out.dir имя базы данных 
 Вы можете использовать pg_restore -j для параллельного восстановления дампа.Это будет работать для любого архива в режиме архива "custom" или "directory", независимо от того, был ли он создан с помощью pg_dump -j.
 .
 PostgreSQL: Документация: 12: 25.1. Дамп SQL 
 Идея этого метода дампа состоит в том, чтобы сгенерировать файл с командами SQL, которые при отправке обратно на сервер воссоздают базу данных в том же состоянии, в каком она была во время дампа. PostgreSQL предоставляет для этого служебную программу pg_dump. Базовое использование этой команды:
pg_dump   dbname  >   файл дампа  
 
 Как видите, pg_dump записывает свой результат в стандартный вывод.Ниже мы увидим, чем это может быть полезно. В то время как приведенная выше команда создает текстовый файл, pg_dump может создавать файлы в других форматах, которые обеспечивают параллелизм и более детальный контроль восстановления объекта.
 pg_dump - обычное клиентское приложение PostgreSQL (хотя и очень умное). Это означает, что вы можете выполнить эту процедуру резервного копирования с любого удаленного хоста, имеющего доступ к базе данных. Но помните, что pg_dump не работает с особыми разрешениями. В частности, он должен иметь доступ для чтения ко всем таблицам, для которых вы хотите создать резервную копию, поэтому для резервного копирования всей базы данных вам почти всегда нужно запускать ее как суперпользователь базы данных.(Если у вас нет достаточных прав для резервного копирования всей базы данных, вы все равно можете создавать резервные копии частей базы данных, к которым у вас есть доступ, используя такие параметры, как  -n   schema    или  -t   table   .)
 Чтобы указать, с каким сервером базы данных должен связаться pg_dump, используйте параметры командной строки  -h   host    и  -p   port   . Хостом по умолчанию является локальный хост или то, что указано в переменной среды  PGHOST .Точно так же порт по умолчанию указывается переменной среды  PGPORT  или, в противном случае, компилированным по умолчанию. (Удобно, что сервер обычно имеет такое же встроенное значение по умолчанию.)
 Как и любое другое клиентское приложение PostgreSQL, pg_dump по умолчанию будет подключаться к имени пользователя базы данных, которое совпадает с именем пользователя текущей операционной системы. Чтобы изменить это, укажите параметр  -U  или установите переменную среды  PGUSER .Помните, что соединения pg_dump подчиняются обычным механизмам аутентификации клиентов (которые описаны в главе 20).
 Важным преимуществом pg_dump перед другими описанными ниже методами резервного копирования является то, что вывод pg_dump обычно можно повторно загрузить в более новые версии PostgreSQL, тогда как резервное копирование на уровне файлов и непрерывное архивирование сильно зависят от версии сервера. pg_dump также является единственным методом, который будет работать при переносе базы данных на другую архитектуру компьютера, например, при переходе с 32-битного на 64-битный сервер.
 Дампы, создаваемые pg_dump, внутренне согласованы, то есть дамп представляет собой моментальный снимок базы данных на момент начала работы pg_dump. pg_dump не блокирует другие операции с базой данных во время ее работы. (Исключениями являются те операции, которые должны работать с монопольной блокировкой, например большинство форм  ALTER TABLE .)
 25.1.1. Восстановление дампа 
 Текстовые файлы, созданные pg_dump, предназначены для чтения программой psql.Общая форма команды для восстановления дампа -
.
psql   dbname   <  файл дампа  
 
, где   файл дампа   - это файл, выводимый командой pg_dump. База данных   dbname   не будет создана этой командой, поэтому вы должны создать ее самостоятельно из  template0  перед выполнением psql (например, с  createdb -T template0   dbname   ).psql поддерживает параметры, аналогичные pg_dump, для указания сервера базы данных для подключения и имени пользователя для использования. См. Справочную страницу psql для получения дополнительной информации. Дампы нетекстовых файлов восстанавливаются с помощью утилиты pg_restore.
 Перед восстановлением дампа SQL все пользователи, владеющие объектами или которым были предоставлены права доступа к объектам в базе данных дампа, должны уже существовать. В противном случае при восстановлении не удастся воссоздать объекты с исходным владельцем и / или разрешениями. (Иногда это то, что вам нужно, но обычно это не так.)
 По умолчанию скрипт psql продолжит выполнение после обнаружения ошибки SQL. Возможно, вы захотите запустить psql с переменной  ON_ERROR_STOP , настроенной для изменения этого поведения, и иметь выход psql со статусом выхода 3, если возникает ошибка SQL:
psql --set ON_ERROR_STOP = on   dbname   <  dumpfile  
 
 В любом случае у вас будет только частично восстановленная база данных. В качестве альтернативы вы можете указать, что весь дамп должен быть восстановлен как одна транзакция, поэтому восстановление будет либо полностью завершено, либо полностью откат.Этот режим можно указать, передав в psql параметры командной строки -1  или  --single-transaction . При использовании этого режима помните, что даже незначительная ошибка может откатить восстановление, которое уже выполнялось в течение многих часов. Тем не менее, это может быть предпочтительнее ручной очистки сложной базы данных после частично восстановленного дампа.
 Способность pg_dump и psql записывать или читать из каналов дает возможность выгружать базу данных напрямую с одного сервера на другой, например:
pg_dump -h   host1     dbname   | psql -h   host2     имя_бд  
 
 Важно 
 Дампы, создаваемые pg_dump, относятся к  template0 .Это означает, что любые языки, процедуры и т. Д., Добавленные через  template1 , также будут сброшены pg_dump. В результате, при восстановлении, если вы используете настроенный  template1 , вы должны создать пустую базу данных из  template0 , как в примере выше.
 После восстановления резервной копии целесообразно запустить ANALYZE для каждой базы данных, чтобы оптимизатор запросов имел полезную статистику; см. Раздел 24.1.3 и Раздел 24.1.6 для получения дополнительной информации. Дополнительные советы по эффективной загрузке больших объемов данных в PostgreSQL см. В Разделе 14.4.
 25.1.2. Использование pg_dumpall 
 pg_dump выгружает только одну базу данных за раз, и он не выгружает информацию о ролях или табличных пространствах (поскольку они являются общекластерными, а не для каждой базы данных). Для поддержки удобного сброса всего содержимого кластера базы данных предоставляется программа pg_dumpall. pg_dumpall выполняет резервное копирование каждой базы данных в данном кластере, а также сохраняет данные всего кластера, такие как определения ролей и табличных пространств.Базовое использование этой команды:
pg_dumpall>   файл дампа  
 
 Полученный дамп можно восстановить с помощью psql:
psql -f   файл дампа   postgres
 
 (На самом деле, вы можете указать любое существующее имя базы данных для начала, но если вы загружаете в пустой кластер, то обычно следует использовать  postgres .) Всегда необходимо иметь доступ суперпользователя базы данных при восстановлении дампа pg_dumpall, так как это требуется для восстановления информации о роли и табличном пространстве.Если вы используете табличные пространства, убедитесь, что пути к табличным пространствам в дампе подходят для новой установки.
 pg_dumpall запускает команды для воссоздания ролей, табличных пространств и пустых баз данных, а затем вызывает pg_dump для каждой базы данных. Это означает, что, хотя каждая база данных будет внутренне согласованной, моментальные снимки разных баз данных не синхронизируются.
 Данные всего кластера можно сбросить отдельно, используя параметр pg_dumpall  --globals-only .Это необходимо для полного резервного копирования кластера при запуске команды pg_dump для отдельных баз данных.
 25.1.3. Работа с большими базами данных 
 Некоторые операционные системы имеют ограничения на максимальный размер файла, что вызывает проблемы при создании больших выходных файлов pg_dump. К счастью, pg_dump может писать в стандартный вывод, поэтому вы можете использовать стандартные инструменты Unix для решения этой потенциальной проблемы. Есть несколько возможных методов:
  Использовать сжатые дампы. Вы можете использовать свою любимую программу сжатия, например gzip:
pg_dump   dbname   | gzip>   имя_файла   .gz
 
 Перезарядка с:
gunzip -c   filename   .gz | psql   имя базы данных  
 
 или:
cat   filename   .gz | gunzip | psql   имя базы данных  
 
  Используйте  split . Команда  split  позволяет разделить вывод на файлы меньшего размера, приемлемые по размеру для базовой файловой системы. Например, чтобы сделать куски размером 1 мегабайт:
pg_dump   dbname   | split -b 1m -   имя_файла  
 
 Перезарядка с:
cat   filename   * | psql   имя базы данных  
 
  Используйте собственный формат дампа pg_dump. Если PostgreSQL был собран в системе с установленной библиотекой сжатия zlib, пользовательский формат дампа будет сжимать данные по мере их записи в выходной файл. Это создаст размер файла дампа, аналогичный использованию  gzip , но имеет дополнительное преимущество, заключающееся в том, что таблицы можно восстанавливать выборочно. Следующая команда выводит базу данных в настраиваемом формате дампа:
pg_dump -Fc   имя_бд  >   имя_файла  
 
 Дамп нестандартного формата не является сценарием для psql, его необходимо восстановить с помощью pg_restore, например:
pg_restore -d   имя_бд     имя_файла  
 
 Подробности см. На справочных страницах pg_dump и pg_restore.
 Для очень больших баз данных вам может потребоваться объединить  split  с одним из двух других подходов.
  Используйте функцию параллельного дампа pg_dump.  Чтобы ускорить создание дампа большой базы данных, вы можете использовать параллельный режим pg_dump. Это приведет к сбросу нескольких таблиц одновременно. Вы можете контролировать степень параллелизма с помощью параметра  -j . Параллельные дампы поддерживаются только для формата архива «каталог».
pg_dump -j   число   -F d -f   выход.директория     dbname  
 
 Вы можете использовать  pg_restore -j  для параллельного восстановления дампа. Это будет работать для любого архива в режиме «пользовательский» или «каталог», независимо от того, был ли он создан с помощью  pg_dump -j .
 .
No related posts.