Резервное копирование и восстановление в PostgreSQL

в 12:43, , рубрики: postgres, postgresql, метки: ,

Резервное копирование и восстановление в PostgreSQL

image

Предположим что у нас есть 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

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js