Язык структурированных запросов для работы с СУБД PostgreSQL. Учебное пособие

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

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

процесс выгрузки создает значительную нагрузку на системуисточник;

выгрузка занимает много времени – к моменту окончания выгрузки она станет уже неактуальной;

сделать согласованную выгрузку всей базы данных при высокой нагрузке практически невозможно, поскольку СУБД вынуждена хранить снимок своего состояния на момент начала выгрузки. Чем больше транзакцийсовершеносмоментаначалавыгрузки, тембольшеобъемснимка;

выгрузка сохраняет логическую структуру данных, но не сохраняет их физической структуры – параметры физического хранения таблиц, индексы;

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

Тем не менее у выгрузки есть и достоинства:

высокая избирательность: можно выгрузить отдельные таблицы, отдельные поля и даже отдельные строки;

выгруженные данные можно загрузить в базу данных другой версии, а если выгрузка сделана в текстовом формате, то и в другую базу данных после адаптации диалекта SQL.

Приложение pg_dump из комплекта утилит PostgreSQL запускается

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

71

Синтаксис приложения pg_dump: pg_dump [параметры] база_данных

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

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

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

-a, --dataonly. Приложение генерирует только команды SQL COPY и INSERT (в зависимости от того, установлен ли ключ -d). В результате архивируются только данные, хранящиеся в базе, но не объекты базы данных. Если ключ -а указывается без ключа -d, сгенерированные команды COPY копируют все данные из stdin (т. е. записи буквально сохраняются в выходном файле). В противном случае записи представляются последовательными командами INSERT.

-b, --blobs. Большие двоичные объекты архивируются наряду с обычными данными.Также должен быть установлен ключ -F с форматом t или с. По умолчанию данные больших двоичных объектов не архивируются.

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

-С, --create. В выходные данные включается команда SQL для со-

здания базы данных (CREATE DATABASE).

-d, --inserts. Для записей генерируются команды INSERT вместо используемых по умолчанию команд COPY. Этот вариант безопаснее, так как одна поврежденная запись приводит к сбою всей команды COPY, но процесс восстановления занимает гораздо больше времени.

-D, --attributeinserts. Ключ -D, как и -d, генерирует команды

INSERT, но в каждую команду INSERT перед секцией VALUES включается список полей в круглых скобках.

72

-f файл, --filе=файл. Результаты работы pg_dump направляются в заданный файл вместо потока stdout. Пользователь, запускающий pg_dump, должен иметь системные права записи в этот файл.

-F {с | t | р | d}, --format {с | t | р | d}. Формат выходного файла. с (сжатие gzip) – файл .tar, сжатый утилитой gzip (т. е. .tar.gzip). t – файл .tar. р (простой текст) – выходной файл генерируется в простом текстовом варианте (режим используется по умолчанию). d – формат аналогичен tar, но выходной каталог не обрабатывается архиватором.

-h хост, --host=xocm. Хост, с которым устанавливается связь вместо хоста local host. Используется в тех случаях, когда архивируемая база данных находится на другом сервере.

-i, --ignore-version. Запрет сравнения версии pg_dump с текущей версией PostgreSQL. Ключ следует использовать лишь в крайних случаях, поскольку различия в структуре системных каталогов разных версий с большой вероятностью приведут к возникновению ошибок. Обычно версия pg_dump должна соответствовать версии архивируемой базы данных.

-n, --noquotes. Идентификаторы заключаются в кавычки только при наличии недопустимых символов (пробелов, символов верхнего регистра и т. д.).

-N, --quotes. Все идентификаторы обязательно заключаются в кавычки. Используетсяв pg_dump поумолчанию, начинаясPostgreSQL 6.4.

-О, --no-owner. При создании архива не учитывается принадлежность базы данных. Объекты, созданные в результате восстановления данных, будут принадлежать пользователю, выполняющему эту операцию.

-р порт, --port=пopm. Порт, по которому должно производиться подключение к серверу, вместо порта по умолчанию 5432.

-R, --no-reconnect. Подавляет все команды \connect, которые обычно обеспечивают сохранение прав владельцев при восстановлении из архива. На практике ключ аналогичен ключу -О, но он также исключает возможность использования ключа -С, поскольку после создания новой базы необходимо заново установить подключение.

-s, --schema-only. Генерируются только команды SQL для архивации таких объектов, как таблицы, последовательности, индексы

73

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

-t таблица, --tablе=таблица. В заданной базе данных архивируется только заданная таблица.

-u, --password. Запрос имени пользователя и пароля. Если пароль не задан (NULL), то в ответ на запрос можно просто нажать клавишу

Enter.

-v, --verbose. Вывод функций pg_dump направляется в поток stderr,

а не в stdout.

-х, --no-acl. Подавление команд GRANT и REVOKE, обычно используемых для сохранения прав, действующих на момент архивации. Ключ используется в том случае, если при восстановлении базы данных из архива не нужно восстанавливать существовавшие ранее права или ограничения.

-Z, --compress {0-9}. Уровень сжатия (0 – минимальный, 9 – максимальный) при использовании с ключом -F с.

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

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

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

74

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

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

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

зова psql.

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

вактуальности данных архива.

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

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

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

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

Если файл не задан, pg_restore ожидает поступления данных из по-

тока stdin.

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

75

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

Многие ключи pg_restore совпадают с аналогичными ключами ко-

манды pg_dump.

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

Пример выгрузки и загрузки БД: pg_dump -Fp -d study -f study_dump.sql psql -d study1 < study_dump.sql

или

pg_dump -Ft -d study -f study_dump.tar pg_restore -d study2 study_dump.tar

2.6.2. СНИМОК СОСТОЯНИЯ ФАЙЛОВ БД

Большинство резервных копий современных баз данных выполняется путем копирования файлов базы данных без остановки базы. Здесь видно несколько проблем.

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

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

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

76

Для того чтобы резервная копия получилась согласованной, у каждой СУБД существует команда, которая сообщает, что начат процесс резервного копирования, в PostgreSQL – это функция pg_start_backup().

Подготовка к резервному копированию в СУБД с изменяемыми дисковыми структурами, т. е. во всех традиционных дисковых реляционных системах, ведется в следующем порядке.

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

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

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

4.  Блокируется изменение заголовков файлов данных, т. е. той его части, изменения которой не отражаются в журналах. Это гарантирует, что заголовок будет скопирован корректно, а потом к файлу данных корректно будут применены журналы.

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

77

По окончании резервного копирования нужно перевести базу данных обратно в обычное состояние, в PostgreSQL это делается вызовом функции pg_stop_backup().

Создание снимка БД в PostgreSQL:

1)  psql: SELECT pg_start_backup('BACKUP_20230420'); 2)  копируем каталог кластера БД:

cp -R /var/lib/pgsql/15.2/data /opt/archive/pg_backup/20230420/ 3)  psql: SELECT pg_stop_backup();

2.7.КОНТРОЛЬНЫЕ ВОПРОСЫ

1.Каким образом можно выполнить проверку ролей пользователя?

2.Как получить информацию об изменении данных из журнала сервера?

3.Какие роли можно определить для конечных пользователей?

4.С помощью какой команды можно отнять все права на таблицу

упользователя?

5.Кто имеет право создавать новых пользователей?

6.Каким образом можно временно запретить пользователю вход в систему?

7.С помощью каких команд можно узнать, у каких пользователей незашифрованные пароли? Зашифрованные пароли?

8.КакиевозможностипредоставляетфункцияSECURITY DEFINER?

9.Каким образом можно предоставить разработчикам право настраивать добавление записей в журнал?

10.На какие группы можно разделить всех пользователей?

11.Кто изменяет права доступа пользователей?

12.Как можно настроить удаленную запись изменений?

78