ЗАПИСКИ АДМИНИСТРАТОРА FREEBSD

Есть несколько путей для проведения резервного копирования и которые могут быть сгруппированы в следующие категории:

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

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

Для этого, у СУБД должны быть логи по упреждающей журнализации WAL (Write Ahead Logs), которые СУБД использует при отказе аппаратуры и т.п. От уровня архивации этих логов зависит и степень физического архивирования: можно настроить архивирование от одной логической точки до другой, либо в качестве непрерывного процесса, либо отсылая логи на другую машину, которая в свою очередь будет использовать их и работать в качестве резервного “клонирующего” узла (вот, в принципе, как работает репликация данных).

Стандартный способ для совершения логического архивирования – это задействовать команду pg_dump(1), которая выгрузит содержимое базы в виде текстового SQL-файла (обычного или сжатого). У этой команды есть много параметров и можно выбрать, что именно сохранять – только данные, только структуру базы, единичную таблицу или объект, либо же всё вместе. Также есть другая утилита под названием pg_dumpall(1), которую можно использовать для сохранения всего кластера, вместо одной какой-либо базы. Использование двух утилит похоже и в листинге 12 показано, как сделать архивирование нашего примера с базой bsddb. При установке из портов будет создан скрипт в  /usr/local/etc/periodic/daily, который при его активации будет запускать pg_dump для сохранения всех баз из кластера (кроме template0).

PITR является интересной функцией, разработанной в версии 8, и которая основана на физическом архивировании. Она позволяет вернуться к определенному состоянию базы в прошлом. Это можно описать так: система следит за состоянием логов WAL, в которых хранится состояние “образа” базы в

любой точке времени. Когда необходимо провести восстановление, то сервис останавливается и затем перезапускается с эмуляцией отказа (т.е. с “грязным” статусом). СУБД затем начинает процедуру отката с помощью WAL-логов так, чтобы была обеспечена внутренняя целостность транзакций. Определив, сколько информации в логах является лишней, можнооткатиться в нужную временную точку в прошлом. Чтобы посмотреть PITR в действии нам нужно

определить, где мы будет хранить WAL-логи, поэтому создадим директорию /postgresql/pitr  и сконфигурируем следующие опции в файле postgresql.conf:

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

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

копирования начался и закончился. Сделать это можно запустив функции pg_start_backup() и pg_stop_backup(). В листинге 13 показано, что для упрощения процедур, наша копия выгружается в зеркальную директорию PGDATA, которая называется /postgresql/cluster2. Пока копирование идет, кластер может продолжать работу (т.е. пользовательские подключения разрешены). В конце процесса мы вставляем, с помощью четырех инструкций, миллион кортежей с четырьмя разными временными метками. А после этого все их удаляем

(см. листинг 13). Таким образом мы моделируем ошибку в приложении, но аналогично можно смоделировать и другие (более сложные) случаи отказов. 

Теперь представьте, что мы хотим вернуться в момент времени 08:23:18 (третья инструкция отработана, но четвертый блок еще не завершен – временные метки в листинге 13 определяются, когда запускается команда INSERT).

В Листинге 14 показано, что при перезапуске базы содержимое таблицы magazine возвращается к состоянию, когда третий блок отработал.

Стоит отметить, что как только восстановление отработало, система переименовывает файл recovery. conf в recovery.done, а другой текстовый файл –backup_label – переименовывается в backup_label.old. В последнем хранится информация о том, когда физическое архивирование началось, название для

архива (которое было передано в pg_start_backup()), а также информация об WAL. Оба файла могут использоваться для анализа текущего состояния кластера.

Как видите, PITR – очень мощный инструмент для кластерного архивирования.Ограничений отката назад по времени для PITR нет,как и ограничений на сам метод архивирования логов WAL – достаточно выделить для них необходимое пространство и задействовать нужную команду (например, cp, scp, tar и т.д.), чтобы иметь возможность сохранить и восстановить всю историю СУБД.

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

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

Вы даже можете использовать оба варианта – логическое и физическое архивирование – делая архивные копии WAL-логов для нужд PITR в промежутках между двумя логическими архивами.

Таким образом вы получаете инкрементальный архив до следующего полного (логического) архива.

Убедитесь, что выбранная стратегия удовлетворяет вашим потребностям и работает правильно.