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

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

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

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

Архивация и восстановление данных

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

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

Чтение комментариев

Комментарии к объектам базы данных легко читаются при помощи управляющих команд psql. Список этих команд приведен ниже.

\d+. Выводит ту же информацию, что и стандартная команда \d (данные обо всех таблицах, представлениях, последовательностях и индексах текущей базы данных), но добавляет к ней столбец комментариев. \1+. Выводит комментарии ко всем базам данных. \df+ [ шаблон ]. Выводит описания всех функций текущей базы данных (с информацией о языке и реализации каждой функции). Чтобы просмотреть результаты этой команды в расширенном режиме вывода, следует предварительно выполнить команду \х (за дополнительной информацией обращайтесь к главе 6). Команде можно передать регулярное выражение шаблон, с которым должны сравниваться имена функций. Это сужает круг поиска и уменьшает количество выводимых функций. \dt+. Выводит комментарии ко всем таблицам текущей базы данных. \di+. Выводит комментарии ко всем индексам текущей базы данных. \ds+. Выводит комментарии ко всем последовательностям текущей базы данных. \dv+. Выводит комментарии ко всем представлениям текущей базы данных. \dS+. Выводит комментарии к системным таблицам. Следует помнить, что комментарии к системным таблицам тоже привязываются к конкретной базе данных и не выводятся, если команда \dS+ выполняется при подключении к другой базе данных. \dd. Выводит все описания всех объектов базы данных.

В листинге 9.19 приведен пример вывода комментариев к таблице books (листинг 9.18) командой \d+ клиента psql.

Документирование базы данных

Команда COMMENT

В PostgreSQL поддерживается нестандартная команда SQL COMMENT, при помощи которой можно документировать любой объект базы данных. Используя команду COMMENT с таблицей, функцией, оператором или другим объектом базы данных, вы можете ввести описание, которое будет храниться в системной таблице pg_descri pti on. Выборка описаний легко производится при помощи управляющих команд psql.

У многих стандартных объектов баз данных имеются стандартные описания, которые выводятся (вместе с описаниями, добавленными пользователем) командой \dd клиента psql.

Синтаксис команды COMMENT:

COMMENT ON [ [ DATABASE | INDEX | RULE SEQUENCE TABLE | TYPE j VIEW ]

{ объект |

COLUMN таблица.поле \

AGGREGATE агрегат тип_агрегата \

FUNCTION функция ( тип_аргумента [. ...] ) |

OPERATOR оператор ( тип_левого_операнда. тип_правого_операнда ) |

TRIGGER триггер ON таблица } ] IS 'описание'

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

Примечание 1
Примечание 1

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

Строка описание, следующая за ключевым словом IS, содержит текст комментария, сохраняемого в базе данных. В листинге 9.18 создается простое описание для поля id базы данных booktown.

Инициализация файловой системы

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

Кластер представляет собой несколько взаимосвязанных баз данных. Один экземпляр процесса postmaster в любой момент времени работает только с одним кластером. При помощи приложения initlocation можно создать базы данных, принадлежащие существующим кластерам, но хранящиеся в других каталогах данных.

Инициализация кластера баз данных

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

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

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

ВНИМАНИЕ

Не запускайте программу initdb с правами root! Обычный пользователь, создавший кластер, становится владельцем нового кластера, то есть его суперпользователем.

Программа initdb также может исправить поврежденную базу данных template 1, для чего она запускается с ключом -t (или - -template). В этом случае база данных template 1 строится заново.

Синтаксис команды запуска программы initdb:

Initdb [ -D каталог \ --pgdata=Karanor ]

[ -1 sysid | --sysid=sysid ]

[ -W | --pwprompt ]

t -E кодировка | --еncoding=кодировка ]

[ -L каталог \ --pglib=каталог ]

[ -n | --noclean ]

[ -d | --debug ]

С -t I --template ]

Ключи initdb описаны ниже.

-D каталог \ - -pgdata=Kamonoz. Каталог, в котором инициализируется новый кластер баз данных. Если имя каталога не задано, команда 1 ni tdb проверяет значение переменной PGDATA. -i sysid \ --sysid=sysid. Системный идентификатор суперпользователя нового кластера. Если параметр не задан, используется системный идентификатор пользователя, запустившего программу initdb. -W | - -pwprompt. Приглашение для ввода пароля после подключения. -Е кодировка \ --еncoding=кодировка. Имя расширенной кодировки для базы данных-шаблона в новом кластере. Заданная кодировка будет использоваться по умолчанию для всех баз данных, создаваемых в этом кластере. Ключ используется лишь в том случае, если вы активизировали поддержку расширенных кодировок в PostgreSQL -L каталог pglib=каталог. Местонахождение библиотечных файлов PostgreSQL, используемых программой initdb при создании кластера. Необходимость в передаче этого параметра возникает крайне редко. Обычно местонахождение файлов известно программе initdb, а если неизвестно — она запросит необходимые данные. -t --template. С ключом template программа initdb заново инициализирует базу данных template 1 в существующем кластере баз данных. Такая возможность может пригодиться при обновлении версии PostgreSQL, при потере или нарушении целостности данных. -n | --noclean. Ключ nodean означает, что программа initdb не должна удалять файлы, если ей не удастся завершить создание кластера из-за ошибки. Используется только при отладке. -d | - -debug. Ключ debug обеспечивает вывод отладочной информации при создании служебных таблиц.

В случае успешного завершения команда initdb создает кластер баз данных в заданном каталоге. Созданный кластер может использоваться PostgreSQL для хранения баз данных.

В листинге 9.7 приведен пример инициализации кластера в каталоге /usr/local/ psql/booktown.

Инициализация вторичного каталога

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

Параметр каталог содержит путь к новому вторичному каталогу. Команда i ni tl ocation должна выполняться пользователем, запустившим процесс postmaster, чтобы он имел необходимые права для созданного каталога.

В листинге 9.8 приведен пример инициализации вторичной области хранения баз данных в каталоге /usr/local/pgsql/booktown2.

Использование pg_restore при восстановлении

Использование 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»).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Команда CREATE DATABASE

Команда SQL CREATE DATABASE имеет следующий синтаксис:

CREATE DATABASE база_дднных

[ WITH [ LOCATION = 'каталог' ]

[ TEMPLATE = шаблон ]

[ ENCODING = кодировка ] ]

Параметр база_данных определяет имя создаваемой базы данных. Имена баз данных должны начинаться с алфавитного символа, а их длина не должна превышать 31 символа. PostgreSQL позволяет создать в заданном каталоге любое количество баз данных (естественно, при наличии свободного места на диске).

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

LOCATION = 'каталог'. В апострофах передается имя переменной среды, инициализированной в среде пользователя, запустившего серверный процесс PostgreSQL. Предположим, в файл /home/postgres/.bash_profile входит следующая строка:

export PGDATA2="/usr/local/pgsql/data2"

После запуска PostgreSQL (при наличии определенной переменной PGDATA2) переменная может использоваться в качестве значения параметра LOCATION. Эта общая мера безопасности предотвращает запись в посторонние каталоги файловой системы. Если ключевое слово LOCATION отсутствует, PostgreSQL создает базу данных в каталоге данных по умолчанию (например, /usr/local/pgsql/data).

TEMPLATE = шаблон. Шаблон, используемый в качестве прототипа для создания новой базы данных. Все объекты, присутствующие в шаблоне, воспроизводятся в созданной базе. Если шаблон не задан, PostgreSQL создает новую базу данных на основе шаблона tempi atel. Если вы хотите создать пустую базу данных, не содержащую объектов из tempi atel, укажите шаблон tempi ateO. ENCODING = кодировка. Значение параметра определяется либо в виде строковой константы, описывающей тип кодировки (SQL_ASCII, LATIN1 и т. д.), либо в виде эквивалентной числовой константы PostgreSQL. Допустимые типы кодировок PostgreSQL и их числовые значения перечислены в приложении А. Если ключевое слово ENCODING не задано, PostgreSQL создает базу данных в кодировке по умолчанию. Обычно это кодировка SQL_ASCII, хотя в процессе первоначальной настройки конфигурации PostgreSQL можно выбрать другую кодировку (процедура выбора кодировки описана в главе 2).

ВНИМАНИЕ

Значение, передаваемое с ключевым словом LOCAi ION, должно определять имя переменной среды. Оно не может напрямую описывать системный путь (например, /usr/local/pgsql/data2), если только в процессе первоначальной компиляции и установки PostgreSQL команде gmake не был передан аргумент CPPFLAGS=-DALLOW_ABSOLUTE_DBPATHS.

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

Создатель автоматически становится владельцем новой базы данных (также используется термин «администратор», или DBA — database administrator). Владельцу базы данных принадлежат все объекты, хранящиеся в базе, и он может предоставлять право доступа к ним другим пользователям. База данных должна создаваться пользователем, который в дальнейшем будет активно заниматься ее сопровождением.

В листинге 9.10 пользователь manager подключается к шаблону tempi atel и создает базу данных booktown. В примере использован клиент psql, но аналогичный синтаксис подходит для любого другого клиента PostgreSQt.

Команда DROP DATABASE

Синтаксис команды SQL DROP DATABASE: DROP DATABASE база_данных

Параметр команды DROP DATABASE определяет имя базы данных, удаляемой из системы. Учтите, что удаление базы данных возможно лишь при отсутствии подключившихся пользователей, в противном случае команда завершается неудачей. В листинге 9.12 приведен пример удаления базы данных с именем example.

Команда VACUUM

Команда SQL VACUUM имеет следующий синтаксис:

VACUUM [ VERBOSE ] [ ANALYZE ] [ таблица ]

VACUUM [ VERBOSE ] ANALYZE [ таблица [ ( поле [. ...] ) ] ]

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

Необязательный идентификатор таблица задается в том случае, если команда VACUUM должна очистить только одну таблицу в подключенной базе данных. Команда также обновляет в системных каталогах статистику по количеству записей и объемам данных. В листинге 9.14 приведен пример использования команды VACUUM для таблицы books в базе данных booktown.

Запуск PostgreSQL в приложении pg_ctl

Листинг 9.1. Запуск PostgreSQL в приложении pg_ctl

[postgres@booktown -]$ pg_ctl -D /usr/1oca!/pgsql/data start

postmaster successfully started

DEBUG: database system was shut down at 2001-09-17 08:06:34 POT

DEBUG: Checkpoint record at (0. 1000524052)

DEBUG: Redo record at (0. 1000524052): Undo record at (0. 0): Shutdown TRUE

DEBUG: NextTransactionld: 815832: NextOid: 3628113

DEBUG: database system is in production state

[postgres@booktown -]$

Завершение PostgreSQL в приложении pg_ctl

Листинг 9.2. Завершение PostgreSQL в приложении pg_ctl

[postgres@booktown -]$ pg_ctl -D /usr/local/pgsql/data stop -m fast

Fast Shutdown request at Mon Sep 17 09:23:39 2001 DEBUG: shutting down

waiting for postmaster to shut down.....

DEBUG: database system is shut down

done

postmaster successfully shut down

[postgres@booktown -]$

Примечание 2
Примечание 2

Завершение в режиме smart эквивалентно команде kil I -TERM для процесса postmaster. Режим fast эквивалентен команде kill -INT, а аналогом режима immediate является команда kill -QUIT.

Перезапуск PostgreSQL в приложении pg_ctl

Листинг 9.3. Перезапуск PostgreSQL в приложении pg_ctl

[postgres@booktown ~]$ pg_ctl -D /usr/1oca!/pgsql/data restart

Smart Shutdown request at Mon Sep 17 08:33:51 2001

DEBUG: shutting down

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

done

postmaster successfully shut down

postmaster successfully started

[postgres@booktown -]$

DEBUG: database system was shut down at 2001-09-17 08:33:53 PDT

DEBUG: Checkpoint record at (0. 1000524116)

DEBUG: Redo record at (0. 1000524116): Undo record at (0. 0): Shutdown TRUE

DEBUG: NextTransactionld: 815832: NextOid: 3628113

DEBUG: database system is in production state

[postgres@booktown ~J$

Проверка состояния

Листинг 9.4. Проверка состояния PostgreSQL в приложении pg_ctl

[postgres@booktown -]$ pg_ctl -D /usr/local/pgsql/data status

pg_ctl: postmaster is running (pid: 11575)

Command line was:

/usr/local/pgsql/bin/postmaster '-D' '/usr/local/pgsql/data'

[postgres@booktown -]$

Примечание 3
Примечание 3

Использование переменной PGDATA заметно сокращает объем команды. Если вы всегда работаете с одним каталогом данных, присвойте значение переменной PGDATA (например, в файле /etc/profile, как рекомендовалось в главе 2), и вам не придется использовать ключ -D.

Запуск PostgreSQL командой service

Листинг 9.5. Запуск PostgreSQL командой service

[root@booktown -]# service postgresql start

Starting PostgreSQL: ok [root@booktown -]#

Если команда service не поддерживается в вашей системе, сценарий postgresql можно вызвать вручную с указанием полного пути:

/etc/re.d/init.d/postgresql { start | stop | restart | status }

В листинге 9.6 состояние серверного процесса PostgreSQL проверяется прямым вызовом сценария postgresql с указанием полного пути. Предполагается, что в вашей системе стартовые сценарии SysV хранятся в каталоге /etc/rc.d/init.d/.

Проверка состояния

Листинг 9.6. Проверка состояния PostgreSQL с использованием сценария postgresql

[root@booktown -]# /etc/re.d/init.d/postgresql status

pg_ctl: postmaster is running (pid: 13238)

Command line was:

/usr/local/pgsql/bin/postmaster '-D' '/usr/local/pgsql/data'

[root@booktown -]#

Как видно из результатов, сценарий SysV всего лишь является удобной «оболочкой» для вызова команд приложения pg_ctl, описанного в предыдущем подразделе.

Инициализация нового кластера

Листинг 9.7. Инициализация нового кластера

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

This database system will be initialized with username "postgres".

This user will own all the data files and must also own the server process.

Creating directory /usr/local/pgsql/booktown

Creating directory /usr/local/pgsql/booktown/base

Creating directory /usr/local/pgsql/booktown/global

Creating directory /usr/local/pgsql/booktown/pg_xlog

Creating tempiatel database in /usr/local/pgsql/booktown/base/1

DEBUG: database system was shut down at 2001-08-27 16:51:07 PDT

DEBUG: Checkpoint record at (0. 8)

DEBUG: Redo record at (0, 8);
Undo record at (0. 8): Shutdown TRUE

DEBUG: Next Transaction: 514: NextOid: 16384

DEBUG: database system is in production state

Creating global relations in /usr/local/pgsql/booktown/global

DEBUG: database system was shut down at 2001-08-27 16:51:14 PDT

DEBUG: Checkpoint record at (0. 108)

DEBUG: Redo record at (0. 108): Undo record at (0. 0): Shutdown TRUE

DEBUG: NextTransactionld: 514: NextOid: 17199

DEBUG: database system is in production state

Initializing pg_shadow.

Enabling unlimited row width for system tables.

Creating system views.

Loading pg_description.

Setting lastsysoid.

Vacuuming database.

Copying tempiatel to tempiateO.

Success. You can now start the database server using:

/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/booktown or

/usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/booktown -1 logfile start

Инициализация вторичного каталога

Листинг 9.8. Инициализация вторичного каталога

[postgres@booktown -]$ initlocation /usr/local/pgsql/booktown2

Проверка наличия права usecreatedb

Листинг 9.9. Проверка наличия права usecreatedb

tempiatel=>
SELECT usecreatedb FROM pg_user WHERE usename='guest':

usecreatedb

(1 row)

Создание базы данных

Листинг 9.10. Создание базы данных

[jworsley@booktown -]$ psql -U manager tempiatel

Welcome to psql. the PostgreSQL interactive terminal.

Type: \copyright for distribution terms

\h for help with SQL commands

\? for help on internal slash commands

\g or terminate with semicolon to execute query

\q to quit

tempiatel-# CREATE DATABASE booktown;

CREATE DATABASE

Сообщение CREATE DATABASE говорит о том, что база данных была создана успешно. Также встречаются сообщения об ошибках.

ERROR: CREATE DATABASE: permission denied. Пользователь пытается создать базу данных, не имея для этого необходимых прав. Право создания баз данных определяется состоянием поля usecreatedb таблицы pg_shadow, упоминавшейся ранее в этой главе. За дополнительной информацией о предоставлении этого права обращайтесь к главе 10. ERROR: CREATE DATABASE: database "booktown" already exists. База данных с заданным именем (в данном примере — booktown) уже существует. PostgreSQL запрещает создавать базы данных с одинаковыми именами, даже если они находятся в разных физических каталогах файловой системы.

Примечание 1
Примечание 1

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

Использование приложения createdb

Листинг 9.11. Использование приложения createdb

[jworsley@booktown -]$ createdb --location=PGDATA2 -U manager example

CREATE DATABASE

Команда DROP DATABASE

Листинг 9.12. Команда DROP DATABASE

tempiatel=# DROP DATABASE example;

DROP DATABASE

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

ERROR: DROP DATABASE: cannot be executed on the currently open database. Вы подключены к базе данных, которую пытаетесь удалить. Прежде чем удалять базу данных, необходимо отключиться от нее. ERROR: DROP DATABASE: database "example" Is being accessed by other users. Кбазе данных, которую вы пытаетесь удалить, подключены другие пользователи. Подождите, пока они не завершат работу с базой данных. ERROR: DROP DATABASE: database "example" does not exist. База данных с указанным именем (в данном примере — база данных example) не существует.

Использование команды dropdb

Листинг 9.13. Использование команды dropdb

[jworsley@booktown -]$ dropdb -U manager -1 example

Database "example" will be permanently deleted.

Are you sure? (y/n) у

DROP DATABASE

Применение команды VACUUM к отдельной таблице

Листинг 9.14. Применение команды VACUUM к отдельной таблице

booktown=# VACUUM books;

VACUUM

Сообщение VACUUM означает, что процесс завершился успешно. Если заданную таблицу не удается найти, выводится следующее сообщение об ошибке:

NOTICE: Vacuum: table not found

При наличии необязательного ключевого слова ANALYZE PostgreSQL анализирует структуру данных во всех полях всех таблиц (или только заданной таблицы, если она указана), после чего эта информация используется оптимизатором запросов для более эффективного планирования. Ключевое слово ANALYZE также позволяет ограничить анализ отдельными полями. В листинге 9.15 приведен пример использования команды VACUUM ANALYZE для всей базы данных booktown.

Применение команды

Листинг 9.15. Применение команды VACUUM ANALYZE ко всей базе данных

booktown=# VACUUM ANALYZE;

VACUUM

Наконец, необязательное ключевое слово VERBOSE применяется в том случае, если вы хотите получить подробный внутренний отчет по результатам выполнения команды VACUUM. Скорее всего, эта информация представляет интерес только для программистов, занимающихся разработкой PostgreSQL или взаимосвязанных программ.

Применение сценария

Листинг 9.16. Применение сценария vacuumdb ко всем базам данных

[jworsley@booktown -]$ vacuumdb -U manager --all

Vacuuming postgres

VACUUM

Vacuuming booktown

VACUUM

Vacuuming tempiatel

VACUUM

Как упоминалось выше, параметры подключения позволяют легко выполнять сценарий vacuumdb с удаленного сервера. В листинге 9.17 происходит практически то же самое, что и в листинге 9.16, но на этот раз ключ - h определяет удаленный сервер с именем booktown.commandprompt.com. Кроме того, в листинге 9.17 обрабатывается конкретная база данных booktown (вместо чистки всех баз данных).

Применение сценария

Листинг 9.17. Применение сценария vacuumdb к удаленной базе данных

[jworsley@cmd ~]$ vacuumdb -h booktown.commandprompt.com -U manager booktown

VACUUM

Создание комментария к таблице books

Листинг 9.18. Создание комментария к таблице books

booktown=# COMMENT ON COLUMN books.id

booktown-# IS 'An Internal Book Town Identifier';

COMMENT

Сообщение COMMENT означает, что комментарии к полю успешно создан.

Вывод комментариев booktown=# \d+ books

Листинг 9.19. Вывод комментариев booktown=# \d+ books

Table "books"

Attribute j Type Modifier | Description

id | integer not null | An Internal Book Town Identifier

title text not null j

authorjd j integer subject_id | integer

Index: books_id_pkey

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

Использование приложения pg_dump

Листинг 9.20. Использование приложения pg_dump

[jworsley@booktown -]$ pg_dump -u -C -f booktown.sql booktown

Username: manager Password:

[jworsley@booktown -]$ Is -1 booktown.sql

-rw-rw-r-- 1 jworsley jworsley 46542 Sep 13 16:42 booktown.sql

Приложение pg_dump поддерживает стандартные параметры хостовых соединений (ключи -h, -u и -р), что позволяет выполнять удаленную архивацию с любого хоста, которому разрешено удаленное подключение в соответствии с содержимым файла pgjiba.conf (более подробная информация приведена в главе 8).

В листинге 9.21 производится подключение с удаленного сервера к серверу booktown.commandprompt.com для создания архивного файла в формате gzip (ключ -F с) с именем booktown.sql.tar.gz.

Удаленный запуск pg_dump

Листинг 9.21. Удаленный запуск pg_dump

[jworsley@cmd ~]$ pg_dump -u -h booktown.commandprompt.com \

-F с -f booktown.sql.tar.gz booktown

Username: manager

Password:

[jworsley@cmd -]$ Is -1 booktown.sql.tar.gz

-rw-rw-r-&th1nsp:- 1 jworsley jworsley 45909 Sep 13 17:12 booktown.sql.tar.gz

Если архивный файл должен содержать большие двоичные объекты, воспользуйтесь форматом tar (t) или gzip (с), потому что текстовый формат не дает такой возможности. В остальных случаях обычных текстовых архивов бывает вполне достаточно.

Архивы в формате tar нередко более чем в два раза превышают по объему свои текстовые прототипы, даже если они не содержат двоичных объектов. Дело в том, что в формат tar включается иерархическое оглавление файлов .dat. В этом оглавлении хранится информация, необходимая для распаковки формата tar соответствующей командой pg_restore; дополнительные инструкции занимают лишнее место на диске. Поскольку tar архивирует файлы без сжатия, был предусмотрен формат с, обеспечивающий автоматическое сжатие tar-файлов в формат gzip.

Использование команды pg_dumpall

Листинг 9.22. Использование команды pg_dumpall

[jworsley@booktown -]$ PGUSER=postgres pg_dumpall >
all.sql

Первая часть команды, приведенной в листинге 9.22, присваивает временной переменной PGUSER значение postgres. Переменная создается на время работы pg_dumpall и прекращает свое существование при завершении программы.

Примечание 2
Примечание 2

В общем случае приложение pg_dumpall должно выполняться суперпользователем PostgreSQL. Это связано с тем, что команда pg_dumpall обращается к системным каталогам PostgreSQL, поскольку наряду с объектами баз данных она архивирует глобальные объекты.

Команду pg_dumpal 1 также можно выполнять в удаленном режиме, хотя для этого следует задать значения всех необходимых переменных среды. Процедура сильна зависит от настройки удаленного хоста в файле pg_hba.conf.

Команда pg_dumpa11 используется в ситуациях, когда базы данных особенно не удобно архивировать по отдельности или при наличии сложной системы пользо вателей и групп. Если вам мешают ограничения pg_dumpall в области вывода дан ных (особенно если ваша база данных использует большие объекты), проще всеп выполнить команду pg_dumpal1 с ключом -д, чтобы заархивировать все данные пользователей и групп, и затем поочередно вызвать программу pg_dump для все) баз данных, которые необходимо заархивировать.

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

Листинг 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

HANGE

[...]

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

Примечание 1
Примечание 1

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

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

Листинг 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 при восстановлении простых текстовых архивов» данного подраздела.

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

Листинг 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.

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

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

Перезапуск PostgreSQL в приложении pg_ctl

Последовательные вызовы pg_ctl с операциями stop и start можно заметить одним вызовом с операцией restart. В команде также может присутствовать флаг -т, определяющий режим завершения.

Параметры, использованные при последнем запуске PostgreSQL, хранятся во временном файле postmaster.opts в каталоге данных PostgreSQL (переменная PGDATA). Файл используется при вызове pg_ctl с аргументом restart и обеспечивает сохранение предыдущих настроек при перезапуске. Не размещайте собственные параметры конфигурации в файле postmaster.opts, поскольку они будут стерты при запуске pg_ctl с аргументом start.

В листинге 9.3 приведен пример перезапуска сервера базы данных booktown пользователем postgres.

Приложение createdb

В PostgreSQL вместо команды CREATE DATABASE также можно воспользоваться приложением командной строки createdb. Единственное функциональное отличие createdb от команды SQL заключается в том, что программа запускается в режиме командной строки и позволяет включить комментарий в базу данных одновременно с ее созданием. В SQL для этого потребовалось бы две команды: CREATE DATABASE и COMMENT.

Синтаксис запуска программы createdb:

createdb [ параметры ] база_данных [ описание ]

Параметр база_данных определяет имя создаваемой базы данных. В строке параметры передаются любые из перечисленных ниже ключей, а описание содержит комментарий, включаемый в базу данных скрытой командой COMMENT (комментарии описаны в подразделе «Документирование базы данных» раздела «Сопровождение базы данных»).

Строка параметров может содержать либо ключи с дефисом, отделенные от значения пробелом (например, -D каталог), либо ключи в стиле GNU с двумя дефисами и знаком равенства, если он нужен (например, - -1оса11оп=католог). Ключи с одним дефисом всегда ограничиваются одной буквой, а ключи с двумя дефисами состоят из нескольких букв (обычно это целое слово).

Ниже перечислены ключи программы createdb.

-О каталог, --]осаИоп=каталог. Аналог ключевого слова LOCATION в команде CREATE DATABASE. В качестве значения ключа указывается имя переменной среды (установленной для пользователя, запустившего серверный процесс PostgreSQL), содержащей путь к каталогу, в котором размещаются файлы новой базы данных. -Т шаблон, - -tempi ate=шaблoн. Аналог ключевого слова TEMPLATE в команде CREATE DATABASE. Ключ определяет идентификатор базы данных (например, tempi ateO), которая используется в качестве шаблона для новой базы с дублированием всех объектов. -Е кодировка, - -епсоб1пд=кодировка. Аналог ключевого слова ENCODING в команде CREATE DATABASE. Ключ содержит строковую константу кодировки (см. приложение А). Числовые константы не могут передаваться программе createdb, хотя у команды CREATE DATABASE такая возможность имеется. - h хост, - - host=xocm. Хост, с которым устанавливается связь для создания базы данных. По умолчанию используется имя local host или значение переменной среды PGHOST. - р порт, - - рогЪ=порт. Порт, по которому должно производиться подключение к серверу, вместо порта по умолчанию (обычно 5432, хотя при компиляции PostgreSQL можно задать другой порт при помощи флага - -with-pgport). -U пользователь, Имя пользователя, с которым производится подключение к PostgreSQL для создания базы данных (вместо имени системного пользователя, запустившего программу createdb). -W, - -password. Ключ передается без параметров и обеспечивает запрос пароля у пользователя. Это происходит автоматически, если в файле pg_hba.conf хост, от которого поступил запрос, не объявлен доверенным. -е, - -echo. Ключ передается без параметров. При включении вывода эха команда CREATE DATABASE, передаваемая PostgreSQL, выводится на экран в момент ее выполнения программой createdb. -q, - -quiet. Ключ передается без параметров и запрещает вывод данных в стандартный поток stdout (хотя ошибки по-прежнему направляются в стандартный поток stderr).

Сообщения об успешном выполнении и ошибках, выводимые программой createdb, совпадают с сообщениями команды CREATE DATABASE, хотя к ним добавляются сообщения об ошибках подключения, аналогичные тем, которые выводятся клиентом psql при указании неверного хоста или данных пользователя. Дополнительная информация о сообщениях приведена выше в пункте «Команда CREATE DATABASE» этого подраздела.

В листинге 9.11 приведен пример использования программы createdb. База данных example создается пользователем manager в каталоге, заданном переменной PGDATA2. Обратите внимание на смешанное использование двух разновидностей ключей (с одним дефисом и в стиле GNU).

Приложение dropdb

Для команды SQL DROP DATABASE также существует вспомогательное приложение dropdb, работающее в режиме командной строки. Единственное отличие между двумя способами заключается в том, что при запуске приложения из командного интерпретатора можно установить флаг, по которому приложение предлагает подтвердить удаление базы данных.

Синтаксис запуска сценария dropdb:

dropdb [ параметры ] база_данных

Параметр 6аза_данных определяет имя удаляемой базы данных. В строке параметры передаются ключи приложения. Большинство ключей dropdb описывает параметры подключения к PostgreSQL и совпадает с ключами, описанными выше в пункте «Команда createdb» подраздела «Создание базы данных». Добавился всего один новый ключ — -1 или --interactive.

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

- h хост, -- host=xocm. Хост, с которым устанавливается связь для удаления базы данных. По умолчанию используется имя local host или значение переменной среды PGHOST. -р порт, --port=nopm. Порт, по которому должно производиться подключение к серверу, вместо порта по умолчанию (обычно 5432, хотя при компиляции PostgreSQL можно задать другой порт при помощи флага - -with-pgport). -U пользователь, --цзегтте^пользователь. Имя пользователя, с которым производится подключение к PostgreSQL для удаления базы данных (вместо имени системного пользователя, запустившего программу dropdb). -W, - -password. Ключ передается без параметров и обеспечивает запрос пароля у пользователя. Это происходит автоматически, если в файле pg_hba.conf хост, от которого поступил запрос, не объявлен доверенным. -i, --interactive. Ключ передается без параметров. Перед уничтожением данных пользователю предлагается подтвердить свое решение. -е, - -echo. Ключ передается без параметров. При включении вывода эха команда DROP DATABASE, передаваемая PostgreSQL, выводится на экран в момент ее выполнения программой dropdb. -q, - -quiet. Ключ передается без параметров и запрещает вывод данных в стандартный поток stdout (хотя ошибки по-прежнему направляются в стандартный поток stderr).

Команду dropdb всегда рекомендуется выполнять с флагом - i, поскольку это дает возможность лишний раз подумать перед удалением информации из PostgreSQL.

В листинге 9.13 приведен пример удаления базы данных example пользователем manager с ключом -1.

Приложение pg_ctl

В поставку PostgreSQL входит приложение pg_ctl, предназначенное для решения общих задач управления. В частности, оно позволяет запускать, завершать, перезапускать и получать информацию о состоянии PostgreSQL.

При запуске pg_ctl с ключом - -help выводится следующее описание:

pg_ctl start [-w] [-D каталог] [-s] [-1 файл] [-о "параметры"]

pg_ctl stop [-W] [-0 каталог] [-s] [-m режим_завершения]

pg_ctl restart [-w] [-D каталог] [-s] [-m режим_завершения] [-о "параметры"]

pg_ctl status [-D каталог]

Ключи приложения pg_ctl описаны ниже.

- w. Приложение pg_ctl ож] [дает завершения операции перед возвратом в режим командной строки. Параметр используется с операциями start или restart; по умолчанию приложение передает команду процессу postmaster и немедленно завершается. -W. Приложение pg_ctl не ожидает завершения операции перед возвратом в режим командной строки. Параметр используется только с операцией stop; по умолчанию приложение передает команду процессу postmaster и ожидает ее выполнения перед завершением. -D каталог. Каталог, содержащий файлы базы данных. Данный ключ не обязателен, поскольку информация может храниться в переменной среды PGDATA. Если переменная не существует, флаг -D является обязательным. -s. Подавление вывода pg_ctl, кроме системных ошибок. Если флаг не задан, сведения о действиях с базой данных (или запуске/завершении в зависимости от выбранной операции) выводятся на экране пользователя, выполнившего команду. -1 файл. Имя файла, в который записываются сведения об операциях с базой данных. Параметр используется только с операцией start. -m режим_завершения. Режим завершения postmaster (конечно, этот параметр доступен только для операций stop и restart): smart — перед завершением процесс postmaster ожидает отключения всех клиентов; fast — процесс postmaster завершается, не ожидая отключения клиентов; immediate — процесс postmaster прекращает работу еще быстрее, чем в режиме fast, без выполнения стандартных завершающих процедур, при следующем запуске база данных запускается в режиме восстановления (recovery) и проверяет целостность системы. -о "параметры". Заданная строка параметров, заключенная в кавычки, напрямую передается процессу postmaster (например, флаг - i для активизации поддержки TCP/IP). Полный список флагов приведен в подразделе «Прямое обращение к postmaster» этого раздела.

Примечание 1
Примечание 1

Многие параметры конфигурации postmaster задаются в файле postgresql.conf, находящемся в каталоге данных PostgreSQL (например, /usr/local/pgsql/data). Эти параметры управляют более сложными техническими аспектами работы PostgreSQL. He изменяйте их, если не уверены в правильности своих действий.

Приложение pg_dump

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

Синтаксис приложения pg_dump:

pg_dump [ параметры ]база_данных

Параметр база_данных определяет имя базы данных, для которой генерируются команды SQL. Строка параметров имеет такой же формат, как у других утилит управления базами данных (например, createdb). В ней чаще всего передается ключ - f для определения файла, в котором сохраняются сгенерированные команды.

Примечание 1
Примечание 1

Если флаг -f не указан, сгенерированные команды SQL вместо записи в файл выводятся в поток stdout.

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

-а, - -data_only. Приложение генерирует только команды SQLCOPY и INSERT(B зависимости от того, установлен ли ключ -d). В результате архивируются только данные, хранящиеся в базе, но не объекты базы данных. Если ключ -а указывается без ключа -d, сгенерированные команды COPY копируют все данные из stdi n (то есть записи буквально сохраняются в выходном файле). В противном случае записи представляются последовательными командами INSERT. -b, --blobs. Большие двоичные объекты архивируются наряду с обычными данными. Также должен быть установлен ключ - F с форматом t или с. По умолчанию данные больших двоичных объектов не архивируются. -с, - -clean. Командам SQL, создающим объекты базы данных, должны предшествовать команды удаления этих объектов. Ключ обычно используется при повторной инициализации существующей базы данных (вместо ее удаления и создания на пустом месте). -С, --create. В выходные данные включается команда SQL для создания базы данных (CREATE DATABASE). -d, --inserts. Для записей генерируются команды INSERT вместо используемых по умолчанию команд COPY. Этот вариант безопаснее, так как одна поврежденная запись приводит к сбою всей команды COPY, но процесс восстановления занимает гораздо больше времени. -D, - -attribute_inserts. Ключ -D, как и -d, генерирует команды INSERT, но в каждую команду INSERT перед секцией VALUES включается список полей в круглых скобках. -f файл, --т"11е=0айл. Результаты работы pg_dump направляются в заданный файл вместо потока stdout. Пользователь, запускающий pg_dump, должен иметь системные права записи в этот файл. -F { с | t р }, --format { с | t | p }. Формат выходного файла (приложение pg_restore обычно используется для работы с файлами, созданными в форматах с или t — соответственно gzip или tar): с (сжатие gzip) — файл .tar, сжатый утилитой gzip (то есть .tar.gz); о t — файл .tar; р (простой текст) — выходной файл генерируется в простом текстовом формате (режим используется по умолчанию). -h хост, --bost=xocm. Хост, с которым устанавливается связь вместо хоста local host. Используется в тех случаях, когда архивируемая база данных находится на другом сервере. -i, - -ignore-version. Запрет сравнения версии pg_dump с текущей версией PostgreSQL. Ключ следует использовать лишь в крайних случаях, поскольку различия в структуре системных каталогов разных версий с большой вероятностью приведут к возникновению ошибок. Обычно версия pg_dump должна соответствовать версии архивируемой базы данных. -n, - -no_quotes. Идентификаторы заключаются в кавычки только при наличии недопустимых символов (пробелов, символов верхнего регистра и т. д.). - N, - - quotes. Все идентификаторы обязательно заключаются в кавычки. Используется в pg_dump по умолчанию, начиная с PostgreSQL 6.4. -о, - -old. Вместе с данными записей архивируются OID (идентификаторы объектов). Ключ очень важен в приложениях, которые так или иначе осмысленно используют OID. -0, - -no-owner. При создании архива не учитывается принадлежность базы данных. Объекты, созданные в результате восстановления данных, будут принадлежать пользователю, выполняющему эту операцию. -р порт, --port=nopm. Порт, по которому должно производиться подключение к серверу, вместо порта по умолчанию (обычно 5432, хотя при компиляции PostgreSQL можно задать другой порт при помощи флага - -with-pgport). -R, - -no-reconnect. Подавляет все команды \connect, которые обычно обеспечивают сохранение прав владельцев при восстановлении из архива. На практике ключ аналогичен ключу -0, но он также исключает возможность использования ключа -С, поскольку после создания новой базы необходимо заново установить подключение. - s, - - schema - on! у. Генерируются только команды SQL для архивации таких объектов, как таблицы, последовательности, индексы и представления, а хранящиеся в таблицах данные игнорируются. Ключ может использоваться для копирования общей структуры базы данных с компьютера разработчика на компьютер, на котором база будет реально эксплуатироваться. -t таблица, . В заданной базе данных архивируется только заданная таблица. -u, --password. Запрос имени пользователя и пароля. В PostgreSQL 7.1.x этот ключ был единственным средством указания другого имени пользователя. Если пароль не задан (NULL), то в ответ на запрос можно просто нажать клавишу Enter. -v, --verbose. Вывод функций pg_dump направляется в поток stderr, а не, как обычно, в поток stdout! -х, --no-acl. Подавление команд GRANT и REVOKE, обычно используемых для сохранения прав, действующих на момент архивации. Ключ используется в том случае, если при восстановлении базы данных из архива не нужно восстанавливать существовавшие ранее права или ограничения. -Z,--compress {0-9 }. Уровень сжатия (0 — минимальный, 9 — максимальный) при использовании с ключом -F с.

По умолчанию приложение pg_dump может запускаться любым системным пользователем, но пользователь, подключающийся к PostgreSQL, должен обладать правом выборки для всех объектов в архивируемой базе данных. В листинге 9.20 приведен пример использования программы pg_dump пользователем manager для базы данных booktown. Ключ -С включает в архив команду CREATE DATABASE. Эта команда включается не всегда, поскольку в некоторых случаях база данных создается заранее в нестандартной конфигурации.

Приложение pg_dumpall

В PostgreSQL также существует приложение pg_dumpall, которое является своего рода «оболочкой» для вызова программы pg_dump. Основная функция этого приложения заключается в одновременной архивации всего кластера баз данных PostgreSQL в системе без вызова pg_dump для всех баз данных по очереди. Синтаксис команды pg_dumpaTl, выводимый с флагом - -help:

pg_dumpall [ -с ] [ -h хост ] [ -р порт ] [ -д ]

Приложение pg_dumpall получает те же параметры подключения, что и приложение pg_dump. Ниже перечислены ключи pg_dumpall.

-с. Командам SQL, создающим глобальные объекты, должны предшествовать команды удаления этих объектов. -h хост, - -host=.roaw. Хост, с которым устанавливается связь вместо хоста local host или хоста, определяемого переменной среды PGHOST. Используется в тех случаях, когда архивируемая база данных находится на другом сервере. -р порт, --port=nopm. Порт, по которому должно производиться подключение к серверу, вместо порта по умолчанию (обычно 5432). -g, --globals-only. Архивируются только глобальные объекты. Обычно этот режим используется при воссоздании пользователей и групп, а также их дублирования на другом компьютере (архив переносится на другой компьютер и восстанавливается). При установке ключа -д перед выполнением команд CREATE из таблицы pg_shadow автоматически удаляются все пользователи. Будьте внимательны!

ВНИМАНИЕ

Не выполняйте команду pg_dumpall с ключом -?. Это приведет к тому, что ключ будет передан приложению pg_dump для каждой базы и выходные данные займут гораздо больше места, чем можно предположить. Для получения справки о команде pg_dumpall используется ключ --help.

Обратите внимание: в PostgreSQL 7.1.x возможности сценария pg_dumpall несколько ограничены по сравнению с обычным сценарием pg_dump. Например, ключ -и не позволяет передать другое имя пользователя и пароль, а ключ -F не может задать другой формат, кроме простого текста (архивы создаются в текстовом виде независимо от выбранного формата). Отсюда следует, что ключ -Ь тоже не может передаваться программе pg_dumpall, поскольку для него необходимы другие форматы, кроме текстового.

Хотя приложению pg_dump можно передать имя файла при помощи ключа -f, полученный архив будет неполным, поскольку глобальные данные pg_dumpall все

равно направляются в поток stdout. Проблемы с ключом ^решаются перенаправлением вывода pg_dumpall в файл средствами командного интерпретатора (>).

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

В листинге 9.22 приведена простая команда bash для определения временной переменной среды PGUSER при вызове клиента PostgreSQL Хотя необходимость в таких переменных возникает редко, это полезный прием, о котором следует помнить в некоторых специфических случаях — например, при работе со сценарием pg_dumpall. В листинге 9.22 переменная PGUSER обеспечивает создание одного архивного файла для всех баз данных.

Приложение vacuumdb

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

Кроме того, сценарию передаются параметры подключения к PostgreSQL, что позволяет использовать его в удаленном режиме (то есть без предварительного подключения к компьютеру при помощи терминального клиента и последующего выполнения программ vacuumdb или psql с удаленного компьютера). Впрочем, для этого режим аутентификации в файле pg_hba.conf должен быть настроен для внешнего доступа (за дополнительной информацией обращайтесь к главе 8).

Синтаксис запуска приложения vacuumdb:

vacuumdb [ параметры ] [ бдза_данных ]

Ключи командной строки сценария vacuumdb, как и сценариев createdb и dropdb, могут задаваться как с одним дефисом, так и с двумя дефисами в стиле GNU. Обязательным является только параметр база_дапных (который может быть заменен ключом --all); этот параметр определяет базу данных, с которой выполняются операции очистки и анализа. Строка параметры определяет режим выполнения команды VACUUM. Ниже приведен полный список ключей приложения vacuumdb.

- h хост, -- host=*oc//z. Хост, с которым устанавливается связь для очистки базы данных. Ключ используется для очистки удаленных баз данных. -р порт, --port=nopm. Порт, по которому должно производиться подключение к серверу, вместо порта по умолчанию (обычно 5432, хотя при компиляции PostgreSQL можно задать другой порт при помощи флага --with-pgport). U пользователь, -- изегтте=полъзова7пелъ. Имя пользователя, с которым производится подключение к PostgreSQL для очистки базы данных (вместо имени системного пользователя, запустившего программу vacuumdb). -W, - - password. Ключ передается без параметров и обеспечивает запрос пароля у пользователя. Это происходит автоматически, если в файле pg_hba.conf хост, от которого поступил запрос, не объявлен доверенным. -d 6аза_даппых, —6Ьг\ате=база_данньис. Имя базы данных, для которой выполняется команда VACUUM. Ключ -d является взаимоисключающим по отношению к ключу -а. - а, - - а! 1. Команда VACUUM с заданными параметрами применяется ко всем базам данных, присутствующим в системном каталоге. -z, - -analyze. Аналог ключевого слова ANALYZE в команде SQL VACUUM. Обновляет статистику распределения данных в полях, используемую оптимизатором запросов в процессе внутреннего планирования. -t 'таблица [ (поле\_, ...])]', --tab~\e='таблица [ (поле[, ...])]'. Ключ определяет таблицу (или конкретные поля в таблице), обрабатываемые командой VACUUM. Для обработки отдельных полей должен быть установлен ключ : - analyze. -v, - -verbose. Аналог ключевого слова VERBOSE в команде SQL VACUUM. Обеспечивает вывод подробного внутреннего отчета по результатам выполнения команды VACUUM. -е, - -echo. Ключ передается без параметров. При включении вывода эха запрос, передаваемый PostgreSQL, выводится на экран в момент его выполнения программой vacuumdb. -q, - -quiet. Ключ передается без параметров и запрещает вывод данных в стандартный поток stdout (хотя ошибки по-прежнему направляются в стандартный поток stderr).

В листинге 9.16 приведен пример использования сценария vacuumdb для сервера базы данных booktown. Ключ -U указывает, что для подключения должно использоваться имя пользователя manager, а флаг - -all обеспечивает последовательную обработку всех баз данных в системном каталоге.

Прямое обращение к postmaster

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

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

В любой момент времени postmaster работает с одним кластером баз данных, хотя вы можете открыть на разных портах несколько экземпляров postmaster, каждый из которых будет работать со своим кластером.

Синтаксис командной строки postmaster:

postmaster [ -А { 0 | 1 } ] [ -В буферы ] [ -с имя=значение ]

[ -d уровень_отладки ] [ -D каталог_цанных ] [ -F ] [ -h хост ]

[ -i ] [ -k каталог ] [ -1 ] [ -N макс_подключений ]

[ -о параметры ] [ -р порт ] [ -S ] [ -n | -s ]

Ниже описаны ключи программы postmaster для PostgreSQL версии 7.1.x.

-А { 0 | 1 }. Флаг проверки отладочных директив на стадии выполнения. Позволяет выполнять отладку, если соответствующий ключ был указан во время компиляции. Флаг -А используется только опытными программистами, работающими над самим пакетом PostgreSQL. -В буферы. Количество дисковых буферов в общей памяти, выделяемых для использования postmaster. По умолчанию — 64.

Примечание 1
Примечание 1

Значение ключа -В должно быть по крайней мере вдвое больше значения, передаваемого с ключом -N.

-с имя=значение. Произвольные параметры времени выполнения. Ключ позволяет переопределить любой параметр конфигурации, находящийся в файле postgresql.conf (в каталоге данных кластера). -d уровенъ_отладки. Объем отладочного вывода, регистрируемого серверным процессом. По умолчанию равен 0. Чем больше число, тем подробнее вывод. Обычно значения 4 или ниже оказывается вполне достаточно, хотя при уровне 4 сохраняемые отладочные данные могут быстро заполнить все свободное место на диске.

Примечание 2
Примечание 2

Если стандартные потоки вывода и ошибок не были перенаправлены от postmaster в файл (на уровне командного интерпретатора или в pg_ctl при помощи ключа -1), вся отладочная информация выводится на управляющем терминале процесса postmaster.

-D каталог. Каталог данных кластера. Если каталог не задан, postmaster использует либо значение переменной среды PGDATA, либо подкаталог /data каталога, указанного в переменной POSTGRESHOME. Если вторая переменная также не существует, используется стандартный каталог, заданный на стадии компиляции (например, /usr/local/pgsql/data). -F. Запрет isync. Ключ повышает быстродействие, но повышает риск порчи данных при внезапных сбоях оборудования или операционной системы. Хорошенько подумайте, прежде чем устанавливать этот флаг! -h хост. Адрес, по которому осуществляется прослушивание. По умолчанию PostgreSQL ведет прослушивание по всем настроенным адресам, включая local host. -i. Активизация клиентских подключений через TCP/IP. Если ключ не задан, postmaster принимает подключения только от сокетов локального домена. -k каталог. Каталог доменного сокета Unix, в котором postmaster прослушивает локальные подключения. По умолчанию равен /tmp/. -1. Активизация подключений SSL. Используется в сочетании с ключом -1.

Примечание 3
Примечание 3

Чтобы использовать ключ -1, необходимо откомпилировать PostgreSQL с поддержкой SSL.

-N макс_соединеиий. Максимальное количество серверных процессов, одновременно обслуживаемых процессом postmaster. По умолчанию — 32. Максимально возможное значение параметра равно 1024. Проследите за тем, чтобы количество выделенных буферов соответствовало максимальному количеству одновременных подключений (параметр -В должен быть по крайней мере вдвое больше параметра -N). -о параметры. Параметры, передаваемые процессом postmaster серверным процессам postgres при запуске. Список параметров приведен в приложении Б. При передаче нескольких параметров строка должна заключаться в кавычки. -р порт. Номер порта TCP/IP (или расширение файла сокета), по которому данный экземпляр postmaster должен принимать подключения. Если ключ не задан, значение берется из переменной среды PGPORT или значения по умолчанию, заданного на стадии компиляции (обычно 5432). -S. Флаг подавления вывода. PostgreSQL отключается от терминального сеанса пользователя, создает собственную группу процессов и перенаправляет свои стандартные потоки вывода и ошибок в /dev/null.

ВНИМАНИЕ

Ключ -S затрудняет диагностику ошибок, поскольку весь трассировочный и отладочный вывод, обычно порождаемый процессом postmaster и его производными процессами, теряется.

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

-n. Ключ -п запрещает повторную инициализацию общих структур данных. Далее средствами отладки программист получает информацию о состоянии памяти на момент сбоя. -s. Процесс postmaster останавливает серверные процессы без их завершения сигналом SIGSTOP. Серверные процессы остаются в памяти, что позволяет программисту вручную получить дамп каждого процесса и проанализировать их по отдельности.

Проверка состояния PostgreSQL в приложении pg_ctl

При вызове с аргументом status приложение pg_ctl возвращает информацию о состоянии процесса postmaster. Хотя выполнение команды никак не отражается на состоянии данных, приложению pg_ctl должен быть известен каталог данных PostgreSQL. Если переменная среды PGDATA не существует, при вызове необходимо передать ключ -D.

Пример получения информации о состоянии сервера PostgreSQL приведен в листинге 9.4.

Сценарий SysV

Сценарий SysV работает аналогично pg_ctl. В сущности, он играет роль управляющей программы для выполнения команд pg_ctl. Главное отличие заключается в том, что сценарий SysV запускается пользователем root, а не пользователем, запускающим PostgreSQL (например, postgres). Сценарий самостоятельно переключает идентификаторы пользователей в нужный момент.

По сравнению с ручным вызовом команд pg_ctl сценарии SysV упрощает процедуры запуска и завершения PostgreSQL. Файл сценария postgresql в каталоге /etc/re.d/init.d хранится в вид обычного текста и может редактироваться в любом стандартном текстовом редакторе. В нем можно легко найти процедуры запуска и завершения, а также добавить или убрать часто используемые аргументы вызова pg_ctl. Вызов postgresql с общим параметром start или stop значительно проще вызова команд pg_ctl с несколькими аргументами.

Инструкции по установке сценария postgresql приведены в главе 2. В зависимости от конфигурации компьютера может существовать несколько способов выполнения установленного сценария. Помните, что настоящее имя файла сценария SysV в каталоге /etc/rc.d/init.d/ выбирается произвольно. Обычно сценарию присваиваются имена postgresql и postgres.

Запуск сценария может осуществляться командой service, если она поддерживается в вашей системе. Команда имеет следующий синтаксис:

service postgresql { start | stop | restart status }

Команда servi се принимает только аргументы, перечисленные в фигурных скобках. Любые другие значения отвергаются. Конфигурацию всех перечисленных режимов можно изменить, отредактировав сценарий (например, /etc/rc.d/init.d/ postgresql). В листинге 9.5 приведен пример запуска PostgreSQL командой service.

Сопровождение базы данных

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

Основным средством физического и аналитического сопровождения баз данных в PostgreSQL является команда SQL VACUUM и ее аналог — сценарий vacuumdb. Оба средства выполняют две общие функции:

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

Для баз данных, работающих в условиях реальной эксплуатации, команду VACUUM рекомендуется выполнять каждую ночь. Хотя команда может выполняться параллельно с обращениями к данным, это замедляет работу сервера. По этой причине сопровождение рекомендуется запланировать на время с минимальным количеством операций с базой данных.

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

ВНИМАНИЕ

Команда VACUUM блокирует таблицы в монопольном режиме. Это означает, что все запросы, использующие обрабатываемую таблицу, приостанавливаются и ожидают снятия блокировки.

Создание базы данных

В PostgreSQL существует два способа создания новых баз данных: команда SQL CREATE DATABASE и программа createdb, работающая в режиме командной строки. Оба способа требуют наличия необходимых прав. Для создания базы данных не нужно быть суперпользователем PostgreSQL, но в таблице pg_shadow должно быть установлено право usecreatedb.

Если вы не уверены в том, обладает ли этим правом конкретный пользователь, для проверки можно воспользоваться запросом к представлению pgjjser (которое, в свою очередь, получает информацию из таблицы pg_shadow; прямые запросы к pg_shadow разрешены только суперпользователям). Поле usecreatedb таблицы pg_shadow содержит логический признак наличия права создания таблиц у данного пользователя. В листинге 9.9 приведен пример запроса к представлению pg_user, проверяющего наличие права usecreatedb для пользователя guest.

Создание и удаление баз данных

В процессе установки PostgreSQL создаются два стандартных шаблона баз данных, tempi ateO и tempi atel, на основе которых создаются новые базы данных. Из этих двух шаблонов вы можете подключиться только к tempi atel. Это связано с тем, что шаблон tempi ateO всегда остается пустым, a tempi atel можно модифицировать и включать в него поддержку языков, функции и даже объекты баз данных (таблицы, представления и последовательности). Удаление шаблонов из системы не разрешается.
Далее описаны процедуры создания и удаления баз данных в PostgreSQL.

Удаление базы данных

По аналогии с созданием баз данных в PostgreSQL предусмотрено два способа удаления базы данных из системы: команда SQL DROP DATABASE и программа dropdb. При удалении базы данных в таблице pg_shadow для соответствующего пользователя должно быть установлено право usecreatedb.

ВНИМАНИЕ

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

Управление базами данных

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

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

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

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

Запуск и завершение PostgreSQL

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

Во втором варианте применяется сценарий SysV, находящийся в подкаталоге contrib/start-scripts основного каталога PostgreSQL. Установка сценария SysV описана в главе 2. По умолчанию сценарий называется linux, поскольку он предназначен для запуска из стартового сценария Linux, хотя в инструкциях по установке он переименовывается в сценарий postgresql в каталоге запуска служб (например, /etc/rc.d/init.d).

Самое принципиальное различие между программой pg_ctl и сценарием SysV заключается в том, что программа pg_ctl выполняется пользователем, запускающим серверный процесс postmaster (например, postgres), а сценарий SysV должен запускаться пользователем root.

Сценарий службы не является специфическим для Linux. Он совместим с большинством систем, использующих стартовые сценарии SysV. Тем не менее, если вы не работаете в системе Linux, возможно, лучше выбрать pg_ctl.

Запуск PostgreSQL в приложении pg_ctl

Чтобы запустить серверный процесс PostgreSQL postmaster, передайте pg_ctl ключ start. Помните, что приложение pg_ctl должно запускаться пользователем postgres (или другим пользователем, которому принадлежит каталог данных PostgreSQL).

В листинге 9.1 приведен пример запуска postmaster с каталогом данных /usr/ local/pgsql/data. СУБД успешно запускается, выдает время последнего завершения работы базы данных и отладочную информацию, после чего пользователь postgres возвращается к приглашению командного интерпретатора.

Завершение PostgreSQL в приложении pg_ctl

Серверный процесс PostgreSQL postmaster можно остановить той же программой pg_ctl, которой он был запущен. Приложение pg_ctl проверяет Наличие работающего процесса postmaster, и если команда stop была выдана владельцем работающего процесса (например, пользователем postgres), сервер PostgreSQL прекращает работу.

Существуют три режима завершения серверного процесса PostgreSQL: интеллектуальный (smart), ускоренный (fast) и немедленный (immediate). Режим завершения задается ключом -т при вызове pg_ctl.

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

ВНИМАНИЕ

Никогда не завершайте процесс postmaster командой kill -9 (kill -KILL), что приводит к потере или порче данных.

В листинге 9.2 сценарий pg_ctl завершает процесс postmaster в ускоренном режиме. Процесс postmaster прекращает работу, не дожидаясь отключения клиентов.