- PVSM.RU - https://www.pvsm.ru -
Резервное копирование и восстановление в PostgreSQL
Предположим что у нас есть postgresql в режиме потоковой репликации. master-сервер и hot-standby готовый заменить погибшего товарища. При плохом развитии событий, нам остается только создать trigger-файл и переключить наши приложения на работу с новым мастером. Однако, возможны ситуации когда вполне законные изменения были сделаны криво написанной миграцией и попали как на мастер, так и на подчиненный сервер. Например, были удалены/изменены данные в части таблиц или же таблицы были вовсе удалены. С точки зрения базы данных все нормально, а с точки зрения бизнеса — катастрофа. В таком случае провозглашение горячего hot-standby в мастера, процедура явно бесполезная…
Для предостережения такой ситуации есть, как минимум, два варианта…
Первый способ достаточно прост в реализации и требует минимум усилий по установке и сопровождению. Ставим «pg_dump | lbzip2» в крон и забываем. Однако этот вариант не предлагает восстановить каталог базы данных на момент предшествующий сбою, алишь на момент выполнения бэкапа. Второй вариант чуть сложней и затратней в плане хранения, но этот вариант является более гибким решением в случае восстановления. О нем как раз и пойдет речь.
Из плюсов:
Минусы:
Как уже было сказано выше, этот способ резервного копирования предлагает гибкие возможности по восстановлению (можно восстановить состояния базы данных в четко указанный момент времени или в момент до или после выполнения определенной транзакции), но в то же время добавляет значительные требования к хранению резервных копий. Реализация выглядит следующим образом:
Режим архивирования WAL-логов настраивается через включение параметров архивирования в postgresql.conf
Резервное копирование настраиваем средствами pg_basebackup и cron.
Хранение резервных копий задача опциональная, так как достаточно иметь хотя бы одну проверенную резервную копию.
Удаление архивов выполняется с помощью утилиты pg_archivecleanup.
Дополнительно можно настроить процедуру проверки созданной резервной копии (запускаем сбоку постгрес и анализируем логи).
На этом работа по настройке завершена.
Теперь предположим что случилось наихудшее и нужно выполнить восстановление. Нужно остановить основной кластер postgres и переименовать каталог базы данных в произвольное имя. Каталог резервной копии нужно переименовать в каталог кластера базы данных. При необходимости скопировать файлы конфигурации. После определения конфигурационных файлов, запускаем postgres относительно нашего каталога. При запуске, Postgres обнаружит recovery.conf и запустится в режиме восстановления. Остается дождаться пока postgres восстановит свое состояние с помощью архивов, после чего можно будет подключаться к базе данных и продолжить работу. Вот и все, процедура восстановления завершена.
Вот так вот. Держите данные в сохранности! Скрипты для резервного копирования и валидации копий здесь [1].
Автор: lesovsky
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/postgresql/34161
Ссылки в тексте:
[1] здесь: https://github.com/lesovsky/uber-scripts/tree/master/postgresql/pgbackup
[2] Источник: http://habrahabr.ru/post/178567/
Нажмите здесь для печати.