Восстановление базы данных
В листинге 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, который используется для подключения к базе данных templatel перед созданием новой базы booktown.
Учтите, что ключ – 0 представляет потенциальную угрозу, если права принадлежности объектов важны при восстановлении базы данных. С одной стороны, он может пригодиться при переходе от среды разработки к среде эксплуатации (например, если различные объекты базы данных ранее принадлежали разработчикам или специалистам по тестированию). Но если база данных восстанавливается, например, из предыдущего архива, использовать ключ – 0 не рекомендуется.
Внимание
Помните, что приложение pg_restore создавалось только для файлов, сгенерированных в формате tar (t) или.tar.gz (с). Простые текстовые архивы обрабатываются клиентом psql, о чем упоминалось в пункте "Использование psql при восстановлении простых текстовых архивов" данного подраздела.
Когда следует архивировать и восстанавливать данные
При использовании программ pg_dump, pg_dumpall и pg_restore приходится учитывать и такой важный фактор, как правильный выбор моментов архивации и восстановления. К счастью, в отношении каждой из этих операций PostgreSQL предоставляет достаточно большую свободу действий.
Когда проводить архивацию
Начиная с версии 6.5, в PostgreSQL поддерживается режим оперативной архивации, не мешающий нормальной работе других пользователей. Таким образом, основным фактором остается быстродействие системы. На архивацию очень большой базы данных может потребоваться много времени. Также приходится учитывать наличие больших двоичных объектов, если вы собираетесь выполнять команду pg_dump с ключом – b (что приводит к дальнейшему увеличению объема архивируемых данных).
Если полная архивация базы данных занимает много времени, выполнение программы pg_dump лучше запланировать на время, когда база данных находится под минимальной нагрузкой. Даже несмотря на то, что архивация не мешает созданию и завершению транзакций, она все равно снижает общее быстродействие системы при повышенной и даже средней нагрузке.
Когда проводить восстановление
При восстановлении приходится учитывать больше факторов, чем при простой архивации. Эти факторы в основном связаны с "глубиной" восстановления, которое принципиально отличается от простого воссоздания базы данных "на пустом месте", и действующих при этом ограничений.
Меньше всего неудобств причиняет простое восстановление данных. Эта операция может выполняться при наличии активных пользователей, подключенных к базе данных, и даже если у этих пользователей открыты незавершенные транзакции. Такое стало возможным благодаря механизму контроля версий, действующему в PostgreSQL. Восстановление данных может выполняться во время работы без перезапуска сервера. После того как модификации будут синхронизированы с базой данных, они немедленно становятся доступными для подключившихся пользователей.
Восстановление, связанное с удалением и воссозданием структурных элементов базы данных (таблиц, представлений и т. д.), также может выполняться во время работы системы. В этом варианте возникает больше проблем, чем при восстановлении данных, поскольку объекты ненадолго удаляются из системы, а это может вызвать временные трудности в приложениях, предполагающих существование этих объектов. Характер этих ограничений зависит от природы приложения, работающего с базой.
Больше всего трудностей возникает при восстановлении, требующем удаления всей базы данных. Такие операции выполняются только в то время, когда к базе данных не подключены пользователи. Если в момент выполнения команды DROP DATABASE имеются активные подключения, попытка удаления базы завершается неудачей.
Возможно, при удалении и воссоздании особо интенсивно используемой базы данных следует завершить систему PostgreSQL и перезапустить ее с запретом подключений TCP/IP; тем самым предотвращаются внешние подключения к серверу до завершения работы.