Восстановление базы данных

Существует два способа восстановления базы данных из архива. Если архив пред ставляет собой простой текстовый файл, его можно передать psql в качестве вход ного файла. Если же был выбран другой формат архива (.tar или .tar.gz), следует использовать приложение pg_restore.

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

Использование psql при восстановлении
простых текстовых архивов

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

Если архив создавался с ключом -С, команда SQ.L для создания базы данных фисутствует в файле архива. Это означает, что база данных скорее всего либо была удалена, либо еще не создана в той системе, в которой она восстанавливается. Если база данных уже существует, возможно, ее придется удалить — но только в том случае, если вы твердо убеждены в актуальности данных архива.

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

В листинге 9.23 продемонстрировано восстановление базы данных booktown is файла booktown.sql, созданного в листинге 9.20 (см. подраздел «Приложение ig_dump»). Поскольку в этом примере использовался флаг -С, заранее создавать -азу данных не нужно; достаточно подключиться к базе данных tempi atel.

Листинг 9.23. Восстановление базы данных

booktown jworsley@booktown -]$ psql -U manager -f booktown.sql templatel

REATE DATABASE

эи are now connected to database booktown as user postgres.

3MMENT

REATE

REATE

HANGE

[...]

По мере выполнения команд файла booktown.sql в stderr выводятся сообщения ервера (CREATE, CHANGE и т. д.).

ПРИМЕЧАНИЕ

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

Использование pg_restore при восстановлении
архивов в форматах .tar и .tar.gz

Если файл был создан программой pg_dump в формате, отличном от простого текста, его можно восстановить из архива .tar или .tar.gz при помощи утилиты pg__restore. Синтаксис команды pg_restore:

pg_restore [ параметры ] [ файл ]

Если файл не задан, pg_restore ожидает поступления данных из потока stdin. ледовательно, при вызове pg_restore могут использоваться средства перенаправ-эния ввода (<). Среди параметров особого внимания заслуживает ключ -d. Если ч не задан, pg_restore вместо восстановления базы данных просто выводит ко-аиды в поток stdout (то есть на экран).

При использовании ключа создания базы данных -С все равно необходимо за-1ть ключ -d с именем существующей базы данных для подключения — например, яр! atel. Неважно, к какой базе данных вы при этом подключаетесь, это всего лишь эеменное подключение до момента создания новой базы данных.

Многие ключи pg_restore совпадают с аналогичными ключами команды pg_dump. Иногда для достижения желаемой цели один ключ должен передаваться при вызове как pg_dump, так и pg_restore. Например, это относится к ключу -С. Если ключ передается только при вызове pg_dump, то команда CREATE DATABASE будет проигнорирована при восстановлении, несмотря не ее присутствие в архиве.

Ниже приведены более подробные описания всех ключей.

• -а, - -data_only. Все ссылки на структурные объекты базы данных игнорируются, и восстанавливаются только записи данных (команды COPY и INSERT).
• -с, - -clean. Командам SQL, создающим объекты базы данных, должны предшествовать команды удаления этих объектов. Без ключа -с эти команды игнорируются, даже если они присутствуют в файле архива.
• -С, --create. В процессе восстановления выполняется команда создания базы данных (CREATE DATABASE), если она присутствует в архиве. Без ключа -С команда игнорируется.
• -d база_данных, —<ЛЬпате=база_данныл:. Имя базы данных, к которой следует подключиться перед восстановлением. Если в процессе архивации использовался ключ создания новой базы данных -С, то ключ -d должен ссылаться на базу tempi atel. Если параметр не указан, команды восстановления базы данных не передаются PostgreSQL, а выводятся в поток stderr.
• -f файл, - -Т'\~\е=файл. Команды SQL, обеспечивающие восстановление базы данных, направляются в заданный файл, вместо передачи postmaster (ключ -d) или вывода в stdout (используется по умолчанию).
• -F { с | t },--format { с | t }. Формат входного файла. Значение с означает файл tar, сжатый утилитой gzip (то есть .tar.gz), а значение t соответствует простому файлу .tar. Обычно этот ключ не нужен, поскольку pg_restore автоматически определяет тип файла по данным заголовка.
• -h хост, --host=.roc?n. Хост, с которым устанавливается связь вместо хоста
• localhost.
• -1, - - i ndex. Восстанавливаются только индексы. Вследствие ошибки PostgreSQL ключ -i может не работать, но ключ --Index в версии PostgreSQL 7.1.x работает всегда.
• -1, -1 i st. Приложение pg_restore выводит перечень объектов базы данных, разделенных запятыми. Вывод можно направить в файл при помощи ключа - f или средств командного интерпретатора (>) и позднее использовать с ключом -L для выбора восстанавливаемых объектов базы данных.
• -L файл, - -use-11 $1=файл. Перечень объектов, восстанавливаемых приложением pg_restore, берется из заданного файла. Файл создается с ключом -1. После создания файла удалите строки объектов, которые не нужно восстанавливать, или закомментируйте их, поставив в начало этих строк точку с запятой (;).
• -N, --orig-order. Восстановление производится в порядке первоначальной архивации объектов приложением pg_dump (дополнительная информация берется из файла в формате tar или gzip). Этот порядок не совпадает с порядком следования команд в файле архива, который определяет последовательность восстановления по умолчанию. Ключ не может использоваться вместе с ключом -о или - г. Если в процессе восстановления объекты базы данных будут воссозданы в неправильном порядке (например, объект, который зависит от другого существующего объекта, будет создан раньше него), можно заново инициализировать базу данных и попробовать восстановить ее с ключом -N.
• -о, -old-order. Объекты восстанавливаются строго в порядке возрастания OID. Ключ не может использоваться вместе с ключом -N или -г.
• -0, --no-owner. Приложение pg_restore игнорирует команды \connect, обеспечивающие сохранение принадлежности объектов.
• -р порт, --port=nopm. Порт, по которому должно производиться подключение к серверу, вместо порта по умолчанию (обычно 5432, хотя при компиляции PostgreSQL можно задать другой порт при помощи флага - -with-pgport).
• -Р, --function. Восстанавливаются только функции. По аналогии с ключом -i, из-за ошибки PostgreSQL ключ -Р может не работать, но ключ - -function в версии PostgreSQL 7.1.x работает всегда.
• - г, - - rearrange. Восстановление происходит в порядке, выбранном приложением pg_dump в процессе создания архива. При установке ключа большинство объектов создается в соответствии с порядком OID, хотя команды создания правил и индексов перемещаются в конец файла. Ключ используется по умолчанию.
• -R, - -no- reconnect. Приложение pg_restore игнорирует все команды \connect (а не только те, которые обеспечивают сохранение принадлежности объектов). Не может использоваться с ключом -С, требующим повторного подключения после создания новой базы.
• -s, --schema-only. Восстанавливаются только структурные объекты базы данных — таблицы, последовательности, индексы и представления. Записи данных не копируются и не вставляются в таблицы, а последовательности инициализируются значениями по умолчанию. Этот ключ может использоваться, например, для создания пустой базы данных, предназначенной для реальной эксплуатации и повторяющей структуру базы данных, применявшейся в процессе разработки.
• -S имя, --superuser=UMM. Задает имя суперпользователя, которому предоставляется право отключения триггеров и изменения принадлежности объектов базы данных.
• -t таблица, --[=таблица~\. Восстанавливается только таблица с заданным именем (вместо всех объектов базы данных). Если ключ - -table указан без значения, восстанавливаются все таблицы.
• -Т триггер, --trigger[триггер]. Восстанавливается только триггер с заданным именем (вместо всех объектов базы данных). Если ключ --trigger указан без значения, восстанавливаются все триггеры.
• -и, - - password. Приложение pg_restore запрашивает имя пользователя и пароль.
• -v, - - verbose. Все выполняемые действия сопровождаются выводом сообщений, которые направляются в поток stderr, а не как обычно в поток stdout!
• -х, - -no-acl. Подавление команд GRANT и REVOKE в восстанавливаемом архиве.

В листинге 9.24 база данных booktown восстанавливается из архива, созданного на другом компьютере. Для восстановления используется файл booktown. sql. tar, созданный в листинге 9.21 (см. подраздел «Приложение pg_dump»).

Листинг 9.24. Восстановление архива приложением pg_restore

[jworsleytaid -]$ pg_restore -v -С -0 -d template! booktown. sql .tar

Connecting to database for restore

Creating DATABASE booktown

Connecting to new DB 'booktown' as postgres

Connecting to booktown as postgres

Creating COMMENT DATABASE "booktown"

Creating TABLE inventory

В приведенной команде pg_restore ключ -v обеспечивает вывод информации о выполняемых операциях, ключ -С создает базу данных (поскольку ранее база данных на этом компьютере не существовала), а ключ -0 игнорирует права принадлежности объектов исходной базы. Также обратите внимание на ключ -d, который используется для подключения к базе данных tempi atel перед созданием новой базы booktown.

Учтите, что ключ -0 представляет потенциальную угрозу, если права принадлежности объектов важны при восстановлении базы данных. С одной стороны, он может пригодиться при переходе от среды разработки к среде эксплуатации (например, если различные объекты базы данных ранее принадлежали разработчикам или специалистам по тестированию). Но если база данных восстанавливается, например, из предыдущего архива, использовать ключ -0 не рекомендуется.

ВНИМАНИЕ

Помните, что приложение pg_restore создавалось только для файлов, сгенерированных в формате tar (t) или .tar.gz (с). Простые текстовые архивы обрабатываются клиентом psql, о чем упоминалось в пункте «Использование psql при восстановлении простых текстовых архивов» данного подраздела.

Когда следует архивировать и восстанавливать данные

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

Когда проводить архивацию

Начиная с версии 6.5, в PostgreSQL поддерживается режим оперативной архивации, не мешающий нормальной работе других пользователей. Таким образом, основным фактором остается быстродействие системы. На архивацию очень большой базы данных может потребоваться много времени. Также приходится учитывать наличие больших двоичных объектов, если вы собираетесь выполнять команду pg_dump с ключом -Ь (что приводит к дальнейшему увеличению объема архивируемых данных).

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

Когда проводить восстановление

При восстановлении приходится учитывать больше факторов, чем при простой архивации. Эти факторы в основном связаны с «глубиной» восстановления, которое принципиально отличается от простого воссоздания базы данных «на пустом месте», и действующих при этом ограничений.

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

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

Больше всего трудностей возникает при восстановлении, требующем удаления всей базы данных. Такие операции выполняются только в то время, когда к базе данных не подключены пользователи. Если в момент выполнения команды DROP DATABASE имеются активные подключения, попытка удаления базы завершается неудачей.

Возможно, при удалении и воссоздании особо интенсивно используемой базы данных следует завершить систему PostgreSQL и перезапустить ее с запретом подключений TCP/IP; тем самым предотвращаются внешние подключения к серверу до завершения работы.

Архивация файловой системы

Хотя PostgreSQL обеспечивает абстрактное представление пользовательской информации, все данные в базах PostgreSQL хранятся в обычных системных файлах. В процессе работы СУБД эти файлы находятся в постоянном движении, поскольку не все изменения в PostgreSQL немедленно записываются на диск. Файлы хранятся в каталоге PostgreSQL (например, /usr/local/pgsql/data или в любом другом каталоге, определяемом переменной среды PGDATA).

Вместо того чтобы генерировать набор команд SQL для повторного создания эазы данных, можно поступить иначе: остановить сервер PostgreSQL (с целью синхронизации всех изменений с файлами на жестком диске) и создать архив соответствующего каталога файловой системы. Обычно это делается утилитой tar; полученный архив можно дополнительно обработать утилитой сжатия (например,

В листинге 9.25 приведен пример архивации каталога данных PostgreSQL Операция выполняется пользователем, которому принадлежат файлы данных (это пользователь, запустивший серверный процесс PostgreSQL). В приведенном примере каталог /usr/local/pgsql/data архивируется пользователем postgres.

Листинг 9.25. Архивация файловой системы PostgreSQL

[postgres@booktown -]$ cd /usr/local /pgsql

[postgres@booktown pgsql]$ pg_ctl stop

Smart Shutdown request at Fri Sep 14 14:54:15 2001

DEBUG: shutting down

waiting for postmaster to shut down ...... DEBUG: database system is shut down

done

postmaster successfully shut down

[postgres@booktown pgsql]$ tar czf pgsql .bak.tar.gz data/

[postgres@booktown pgsql ]$ Is -1 *.tar.gz

-rw-rw-r-&thinsp:- 1 postgres postgres 66124795 Sep 14 14:36 pgsql .bak.tar.gz

Обратите внимание: приложение pg_ctl перед вызовом tar останавливает сервер PostgreSQL (с таким же успехом можно вызвать сценарий SysV с командой service, если он установлен в системе). Как упоминалось выше, остановка сервера обеспечивает синхронизацию изменений в базах данных с жестким диском, а также предотвращает возможную модификацию файлов данных в процессе архивации.

Главное преимущество подобного способа архивации заключается в том, что вы получаете фактическую копию файлов данных PostgreSQL. Чтобы восстановить базу данных по такому архиву, необходимо распаковать его в соответствующий каталог и перезапустить сервер. Вам не придется беспокоиться о ключах командной строки, правах принадлежности объектов или потенциальных конфликтах между результатами, полученными программой pg_dump, и существующей базой данных на сервере PostgreSQL.

Тем не менее, несмотря на несомненную простоту реализации, этот способ обладает рядом недостатков. Во-первых, для архивации или восстановления данных приходится останавливать сервер, при этом теряется основное преимущество оперативной архивации — максимальная работоспособность сервера. Во-вторых, вам не удастся архивировать только определенные базы данных или таблицы — для полного восстановления приходится архивировать весь каталог, поскольку с каждой базой данных связано несколько файлов и не всегда понятно, к какой базе данных относится тот или иной файл.

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