Резервное копирование и восстановление в PostgreSQL
Предположим что у нас есть postgresql в режиме потоковой репликации. master-сервер и hot-standby готовый заменить погибшего товарища. При плохом развитии событий, нам остается только создать trigger-файл и переключить наши приложения на работу с новым мастером. Однако, возможны ситуации когда вполне законные изменения были сделаны криво написанной миграцией и попали как на мастер, так и на подчиненный сервер. Например, были удалены/изменены данные в части таблиц или же таблицы были вовсе удалены. С точки зрения базы данных все нормально, а с точки зрения бизнеса — катастрофа. В таком случае провозглашение горячего hot-standby в мастера, процедура явно бесполезная…
Для предостережения такой ситуации есть, как минимум, два варианта…
- использовать периодическое резервное копирование средствами pg_dump;
- использовать резервное копирование на основе базовых копий и архивов WAL.
Первый способ достаточно прост в реализации и требует минимум усилий по установке и сопровождению. Ставим «pg_dump | lbzip2» в крон и забываем. Однако этот вариант не предлагает восстановить каталог базы данных на момент предшествующий сбою, алишь на момент выполнения бэкапа. Второй вариант чуть сложней и затратней в плане хранения, но этот вариант является более гибким решением в случае восстановления. О нем как раз и пойдет речь.
Из плюсов:
- возможность восстановить кластер базы на любой момент времени относительно времени создания базовой копии и времени сбоя;
- в качестве условия для восстановления может служить как временная отметка так и конкретная транзакция.
Минусы:
- базовая копия занимает приблизительный размер кластера базы данных;
- необходимость хранения WAL-архивов за период хранения базовой копии.
Как уже было сказано выше, этот способ резервного копирования предлагает гибкие возможности по восстановлению (можно восстановить состояния базы данных в четко указанный момент времени или в момент до или после выполнения определенной транзакции), но в то же время добавляет значительные требования к хранению резервных копий. Реализация выглядит следующим образом:
- настройка режима архивирования WAL-логов;
- настройка резервного копирования;
- хранение одной или более резервных копий;
- удаление самой старой резервной копии в случае успешного выполнения п.1;
- удаление соответствующих WAL-архивов от резервной копии из п.3;
- опционально можно проводить процедуру проверки резервных копий на предмет их «профпригодности».
Режим архивирования WAL-логов настраивается через включение параметров архивирования в postgresql.conf
Резервное копирование настраиваем средствами pg_basebackup и cron.
Хранение резервных копий задача опциональная, так как достаточно иметь хотя бы одну проверенную резервную копию.
Удаление архивов выполняется с помощью утилиты pg_archivecleanup.
Дополнительно можно настроить процедуру проверки созданной резервной копии (запускаем сбоку постгрес и анализируем логи).
На этом работа по настройке завершена.
Теперь предположим что случилось наихудшее и нужно выполнить восстановление. Нужно остановить основной кластер postgres и переименовать каталог базы данных в произвольное имя. Каталог резервной копии нужно переименовать в каталог кластера базы данных. При необходимости скопировать файлы конфигурации. После определения конфигурационных файлов, запускаем postgres относительно нашего каталога. При запуске, Postgres обнаружит recovery.conf и запустится в режиме восстановления. Остается дождаться пока postgres восстановит свое состояние с помощью архивов, после чего можно будет подключаться к базе данных и продолжить работу. Вот и все, процедура восстановления завершена.
Вот так вот. Держите данные в сохранности! Скрипты для резервного копирования и валидации копий здесь.
Автор: lesovsky
