Инструменты пользователя

Инструменты сайта


postgresql_-_дамп_базы_и_восстановление

Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

postgresql_-_дамп_базы_и_восстановление [2014/10/14 04:13] (текущий)
188.162.132.13 создано
Строка 1: Строка 1:
 +====== Дамп 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. Общий вид команды для восстановления дампа:
 +
 +<​code>​
 +psql имя_БД < файл_дампа
 +</​code>​
 +
 +где файл_дампа — это файл, содержащий вывод команды 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|Источник]]
postgresql_-_дамп_базы_и_восстановление.txt · Последние изменения: 2014/10/14 04:13 — 188.162.132.13