"Мозги" Nohau

Отредактируйте страницу и нажмите «Сохранить». Прочтите справочную страницу для ознакомления с синтаксисом вики. Пожалуйста, редактируйте только в том случае, если планируете улучшить содержимое. Если вы просто хотите потестировать что-либо, воспользуйтесь специальной страницей: PlayGround.

====== Дамп PostgreSQL ======

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

<code>
pg_dump имя_БД > файл_дампа
</code>

Как видите, pg_dump записывает результаты своей работы на стандартный вывод. Далее будет рассмотрено как из этого можно извлечь пользу.

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

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

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

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

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

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

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

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

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

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

<code>
psql --set ON_ERROR_STOP=on имя_БД < файл_дампа
</code>

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

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

<code>
pg_dump -h сервер1 имя_БД | psql -h сервер2 имя_БД
</code>

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

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

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

<code>
pg_dumpall > файл_дампа
</code>

Результирующий дамп может быть восстановлен с помощью psql:

<code>
psql -f файл_дампа postgres
</code>

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

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

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

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

<code>
pg_dump имя_БД | gzip > имя_файла.gz
</code>

Загружая впоследствии сжатый дамп командой:
<code>
gunzip -c имя_файла.gz | psql имя_БД
</code>
или:
<code>
cat имя_файла.gz | gunzip | psql имя_БД
</code>
Используйте split. Команда split позволяет вам разбивать вывод на файлы меньшего размера, которые не попадают под ограничения на максимальный размер файла в файловой системе. Например, чтобы нарезать дамп на кусочки по 1 мегабайту:
<code>
pg_dump имя_БД | split -b 1m - имя_файла
</code>
Загружая впоследствии полученные файлы командой:
<code>
cat имя_файла* | psql имя_БД
</code>
Используйте специальный формат дампа в pg_dump. Если PostgreSQL была скомпилирована в системе с установленной библиотекой zlib, то специальный формат дампа будет сжимать данные, которые выдаются в файл вывода. Это приведёт к созданию файла дампа, который по размеру будет похож на дамп, сжатый gzip, но такой формат будет иметь преимущество, потому что позволяет выборочное восстановление таблиц. Следующая команда делает дамп базы данных, используя специальный формат дампа:
<code>
pg_dump -Fc имя_БД > имя_файла
</code>
Специальный формат дампа не является скриптом для psql и должен восстанавливаться с помощью команды pg_restore, например:
<code>
pg_restore -d имя_БД имя_файла
</code>
См. подробности на страницах справочного руководства pg_dump и pg_restore.

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

[[http://postgresql.ru.net/manual/backup-dump.html|Источник]]

Пожалуйста, введите код подтверждения, чтобы доказать, что вы человек:

  __  __   __   _____   ___      __
 / / / /  / /  / ___/  / _ | __ / /
/ /_/ /  / /__/ (_ /  / __ |/ // / 
\____/  /____/\___/  /_/ |_|\___/

Пожалуйста, оставьте это поле пустым:

Сводка изменений

Примечание: редактируя эту страницу, вы соглашаетесь на использование своего вклада на условиях следующей лицензии: CC Attribution-Share Alike 4.0 International