HotBackupPostgreSQL
Содержание
Организация горячего бэкапа PostgreSQL
Задача - организовать горячий бэкап PostgreSQL с возможностью в любой момент поднятия запасного сервера.
Создание бэкапа
Включаем копирование WAL (Write-Ahead Logs, журнал транзакций) файлов в postgresql.conf
archive_command = 'cp -i %p /backup/pgsql/wal_backup/%f < /dev/null'
Через %p подставляется полный путь к WAL файлу который следует скопировать, %f - имя файла. Где опция -i нужна для предотвращения перезаписи существующих файлов из-за ошибки администратора (в ответ на вопрос будет перенаправлен /dev/null и команда вернет ошибку в коде возврата). При возврате командой не нулевого кода, postgresql попытается повторить копирование текущего файла позже. Раздел /backup в нашем случае примонтирован через NFS. Файл записывается с правами под которыми запущен PostgreSQL. Можно использовать для копирования на удаленный сервер и scp, предварительно настроив авторизацию SSH по открытым ключам, без запроса пароля:
archive_command = '/usr/bin/scp %p postgresql@backup.test.ru:/usr/local/pgsql/wal_backup/%f </dev/null'
Первичная синхронизация запасного сервера
Перед началом WAL бэкапа необходимо обеспечить синхронность основного и резервного серверов.
Копируем файлы конфигурации postgresql.conf, pg_hba.conf, pg_ident.conf.
Устанавливаем контрольную точку, свидетельствующую о начале бэкапа файлов данных. При этом основной сервер продолжает работать в обычном режиме, но данные на диск не сбрасываются (пишутся только WAL логи в pg_xlog ), что замедляет работу.
SELECT pg_start_backup('backup1');
Далее просто копируем содержимое директории data, кроме файлов в pg_xlog (pg_xlog на запасном сервере в момент раскрытия архива data должен быть пустой !) на запасной сервер (для ускорения вначале лучше скопировать на локальный диск), не обращая внимание на предупреждение rsync или tar о копированнии незакрытых файлов.
Закрываем контрольную точку, сигнализируя о завершении копирования файлов. Сервер продолжает работать в обычном режиме.
SELECT pg_stop_backup();
Восстановление на резервном сервере из WAL бэкапа
На запасном сервере в data директории создаем файл recovery.conf, содержащий
restore_command = 'cp /usr/local/pgsql/wal_backup/%f %p'
Перезапускаем PostgreSQL и он сам загружает WAL файлы, необходимые для полного восстановления состояния базы.
PS. Если в запасном PostgreSQL нет необходимости, а нужен только бэкап, достаточно сохранить первичный дамп базы и WAL логи. В случае краха, заменяем data, создаем recovery.conf и чистим содержимое pg_xlog. В момент восстановления, будет запрошен несуществующий файл 00000001.history, это нормально. В случае постоянного бэкапа для поддержания всегда готового запасного сервера, недавно загруженные WAL файлы нельзя удалять, так как на завершающей стадии восстановления они могут быть запрошены еще раз.
Ссылки
- online-backup - заметка на русском языке
- PostgreSQL crash recovery
- Evaluation of a Large-scale DB (Operation ability)
- Procedure for Evaluating Backup and Restoration Performance of PostgreSQL 8.1.4 by Using OSDL DBT-1
- Data Protection for LAMP Applications
- Postgres Backup and Restore
- PostgreSQL 8.2 Documentation: 23.4. Warm Standby Servers for High Availability
- PostgreSQL 8.2 Documentation: 23.3. Continuous Archiving and Point-In-Time Recovery (PITR)
- Pg_lesslog 1.2 - позволяет уменьшить размер архива WAL-логов. Pg_lesslog заменяет полные записи на их инкрементальные аналоги, созданные с учетом предыдущих изменений. Подобные манипуляции производятся только для блоков помеченных флагом "removable", поддержка которого появилась в PostgreSQL 8.3. При тестировании использование Pg_lesslog позволило сократить размер бэкапа в 6 раз.