Резервное копирование

В этом разделе рассматриваются следующие сценарии восстановления из резервной копии:

• Полное восстановление кластера. Например, кластер полностью неработоспособен и требуется восстановление из последней резервной копии всего кластера.
• Восстановление на определенный момент времени. Например, изменения в БД привели к сбою или потере данных. БД находится в рабочем состоянии, но требуется восстановление данных на определенный момент времени до сбоя. Также используется при миграции, для тестирования и аудита.
• Создание резервного сервера. Например, в результате сбоя на предыдущем резервном сервере БД на нем оказывается недоступна, требуется восстановление из резервной копии.

Резервное копирование файлов WAL обеспечивает целостность данных СУБД Pangolin. Такая резервная копия позволяет использовать таблицы базы данных во время сеанса без каких-либо ограничений.

Восстановление инициируется пользователем и предполагает ручное указание параметров восстановления. СУБД потребуется учетная запись с правами на создание резервных копий: отдельная роль с минимальными правами, необходимыми для выбранной стратегии копирования. Управление функциями резервного копирования СУБД Pangolin выполняется специалистами по резервному копированию.

Функциональность мониторинга резервных копий реализована через расширение pgse_backup.

Описание

СУБД Pangolin, как и все современные СУБД, поддерживает возможность резервного копирования для защиты данных от потери в случае отказа оборудования, ошибки администратора, ошибок приложений, проблем сервисных служб, а также для помощи при миграции данных на новые сервера.

Существует три подхода к резервному копированию данных:

1. Выгрузка в SQL.

   Этот подход основан на создании текстового файла с командами SQL, которые при выполнении на сервере восстановят базу данных в том же состоянии, в котором она была на момент создания дампа. Такой файл содержит инструкции для создания таблиц, вставки данных и других объектов базы. Для этого обычно используется стандартный инструмент pg_dump. Это удобный способ для переноса базы, ее просмотра или редактирования в текстовом виде.

2. Копирование на уровне файлов.

   Этот метод подразумевает создание физической копии файлов базы данных, которые хранят все данные, индексы и служебную информацию. Инструмент pg_basebackup создает точный «снимок» всей базы на диске, включая внутренние файлы. Такая резервная копия позволяет быстро восстановить систему, но требует совместимости версии и конфигурации между резервной копии и сервером.

3. Непрерывное архивирование (WAL-архивирование).

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

Доступные типы резервного копирования

Доступны следующие типы резервного копирования:

• полная резервная копия (включает все базы данных в экземпляре СУБД Pangolin);
• инкрементальное резервное копирование (режим ptrack). Подробнее в разделе «ptrack. Инкрементальное резервное копирование»;
• резервное копирование транзакций (включает только файлы WAL, заархивированные со времени предыдущего полного резервного копирования или резервного копирования транзакций. Данные резервной копии транзакции являются необходимыми для успешного восстановления кластера с применением непрерывного архивирования, поэтому цепочка архивированных WAL-файлов так же должна быть непрерывной. Для восстановления экземпляра сначала используется полная резервная копия и затем подается последовательность архивных WAL-файлов для применения на экземпляре, что позволяет восстановить копию на необходимый момент времени).

Вне зависимости от используемого способа резервного копирования автоматически вызываются стандартные функции управления резервным копированием СУБД Pangolin: pg_start_backup(), pg_stop_backup().

Создается отдельный процесс с подключением к libpq. Одновременно может быть выполнено только одно резервное копирование. Если существует старый сеанс резервного копирования, новое резервное копирование не будет запущено.

Резервное копирование журналов предзаписи (WAL) в режиме онлайн осуществляется с помощью утилиты pg_probackup. Таким образом обеспечивается целостность резервной копии и возможность восстановления данных на любой момент времени (Point-in-Time Recovery, PITR).

Такая резервная копия позволяет активно использовать таблицы базы данных во время сеанса без каких-либо ограничений в использовании.

Резервное копирование с помощью СРК

В СУБД Pangolin добавлены улучшения, упрощающие мониторинг, управление и интеграцию с различными системами резервного копирования (СРК):

• manage_backup.bin входит в пакет Manage Backup Tools и устанавливается в каталог /opt/pangolin-backup-tools-<package_version>/bin на сервере с БД при интеграции СУБД Pangolin c СРК;
• pgse_backup – расширение, включающее набор представлений и процедур для организации и контроля мониторинга прохождения заданий резервного копирования;
• pg_probackup – утилита резервного копирования для подготовки и контроля архивов резервной копии.

Главные функции механизма резервного копирования:

• создание полной резервной копии данных;
• резервное копирование файлов WAL (Write Ahead Log) для обеспечения целостности данных;
• восстановление данных из резервной копии;
• восстановление на определенный момент времени (Point-in-Time Recovery или PITR);
• интеграция с системами резервного копирования.

Утилита manage_backup.bin

Утилита manage_backup.bin представляет собой python-скрипт, который осуществляет резервное копирование экземпляра СУБД Pangolin. Утилита поставляется в пакете компонента Pangolin Backup Tools в рамках дистрибутива продукта.

Этот скрипт автоматизирует вызовы стандартных функций управления резервным копированием СУБД Pangolin: pg_start_backup(), pg_stop_backup(). Также он сохраняет историю (статусы и временные метки) резервных копий, которая потом просматривается с помощью представлений расширения pgse_backup.

Утилита имеет следующие ключи:

usage: manage_backup.bin [-h] -B label_dir --host host -p port -d database -U
                         user [--password password] [--session-timeout sec]
                         [--start-timeout sec] [--stop-timeout sec]
                         [--patroni-host patroni_host]
                         [--patroni-port patroni_port]
                         [--rotate-history rotate_history] --session-id
                         session_id [--ignore-degraded] [--version VERSION]
                         action

Аргументы утилиты:

• -h, --help — вывод справки по использованию утилиты;
• -B — каталог, в котором размещаются сопоставления табличных пространств и файл backup_label (параметр передается утилите pg_probackup);
• --host — хост СУБД, для которого выполняется резервное копирование;
• -p — порт подключения;
• -d — имя базы данных;
• -U — имя пользователя;
• --password — пароль пользователя;
• --session-timeout — максимальная продолжительность сессии резервного копирования в секундах (значение по умолчанию — 0 (без ограничения));
• --start-timeout — время ожидания выполнения функции pg_backup_start в секундах (значение по умолчанию — 3600);
• --stop-timeout — время ожидания выполнения функции pg_backup_stop в секундах (значение по умолчанию — 300);
• --patroni-host — хост Patroni (Pangolin Manager);
• --patroni-port — порт Patroni (Pangolin Manager);
• --rotate-history — удаление истории старше указанного количества успешных сеансов резервного копирования (0 — не удалять историю, значение по умолчанию — 6);
• --session-id — идентификатор сессии резервного копирования из Data Protector;
• --ignore-degraded — отсутствие записи статуса резервного копирования degraded как ошибочного;
• --version — вывод версии утилиты.

Ролевая модель

Для интеграции с СРК может потребоваться выделенная роль для проведения процедуры резервного копирования со следующими разрешениями:

BEGIN;
CREATE ROLE BACKUP_USER WITH LOGIN;
GRANT USAGE ON SCHEMA pg_catalog TO BACKUP_USER;
GRANT EXECUTE ON FUNCTION pg_catalog.current_setting(text) TO BACKUP_USER;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_is_in_recovery() TO BACKUP_USER;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_start_backup(text, boolean, boolean) TO BACKUP_USER;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_stop_backup(boolean, boolean) TO BACKUP_USER;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_create_restore_point(text) TO BACKUP_USER;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_switch_wal() TO BACKUP_USER;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_last_wal_replay_lsn() TO BACKUP_USER;
GRANT EXECUTE ON FUNCTION pg_catalog.txid_current() TO BACKUP_USER;
GRANT EXECUTE ON FUNCTION pg_catalog.txid_current_snapshot() TO BACKUP_USER;
GRANT EXECUTE ON FUNCTION pg_catalog.txid_snapshot_xmax(txid_snapshot) TO BACKUP_USER;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_control_checkpoint() TO BACKUP_USER;
COMMIT;

Где BACKUP_USER – пользователь для возможности подключения к СУБД Pangolin со стороны СРК.

Восстановление данных

СУБД Pangolin поддерживает различные способы восстановления данных.

Перед восстановлением данных необходимо определить следующие аспекты процесса восстановления:

• Область действия:

  • Восстановление всего экземпляра – в таком случае восстановление производится отдельно на каждый сервер, после чего выполняется синхронизация с помощью Pangolin Manager.
  • Восстановление ведомого сервера – в таком случае восстановление происходит из резервной копии на последний возможный момент времени.

• Расположение восстанавливаемых данных:

  • Исходное расположение.
  • Другой путь на исходном клиенте.
  • Другой клиент (на него тоже потребуется установить СУБД Pangolin).

• Восстановление на определенный момент времени при условии наличия соответствующей цепочки восстановления (включая полный образ резервной копии и резервную копию соответствующих файлов WAL):

  • На время последней резервной копии транзакции (откат к последнему возможному состоянию).
  • На определенный момент времени по выбору (восстановление на момент времени с повтором).
  • На момент выбранного успешного полного или резервного копирования транзакции.

На момент восстановления из резервной копии СУБД должна быть остановлена.

Настройка

Резервное копирование конфигурации СУБД Pangolin

Под копированием конфигурации понимается копирование конфигурационных файлов, в зависимости от типа конфигурации.

При установке СУБД Pangolin через скрипты развертывания, определить конфигурацию можно с помощью команды:

SHOW installer.cluster_type;

Ответ для standalone:

┌─────────────────────────────────┐
│     installer.cluster_type      │
├─────────────────────────────────┤
│ standalone-postgresql-pgbouncer │
└─────────────────────────────────┘
(1 row)

Ответ для кластера:

┌────────────────────────────────┐
│      installer.cluster_type    │
├────────────────────────────────┤
│ cluster-patroni-etcd-pgbouncer │
└────────────────────────────────┘
(1 row)

примечание

Перечень ниже включает все потенциальные файлы для резервного копирования. Их наличие и расположение может отличаться в зависимости от конфигурации и используемой инсталляции СУБД Pangolin и ее компонентов.

Файлы, подлежащие резервному копированию:

• для PostgreSQL:

  • с Pangolin Manager: /etc/pangolin-manager/postgres.yml;
  • standalone: $PGDATA/postgresql.conf и $PGDATA/pg_hba.conf, где $PGDATA – /pgdata/06/data (для 6 версии СУБД Pangolin);

• для Pangolin Pooler:

  • конфигурационный файл: /etc/pangolin-pooler/pangolin-pooler.ini;
  • исполняемый файл (с версии Pangolin 6.1.2): /opt/pangolin-pooler/bin/pangolin-pooler;

• для DCS (etcd):

  • конфигурационный файл: /etc/etcd/etcd.conf;

• утилита перекодирования:

  • конфигурационный файл: /etc/pangolin-auth-reencrypt/enc_util.cfg;
  • исполняемый файл: /opt/pangolin-common/bin/pangolin-auth-reencrypt;

• хранилище паролей (файл /etc/pangolin-auth-encryption/enc_utils_auth_settings.cfg);

• файл с параметрами оборудования и сетевыми интерфейсами (файл enc_params.cfg.postgres и enc_params.cfg.kmadmin_pg);

• настройки подключения к KMS (файл /etc/pangolin-security-utilities/enc_connection_settings.cfg);

• для восстановления утилиты из резервной копии необходимо хранить набор файлов:

  • конфигурационный файл утилиты (/etc/pangolin-auth-reencrypt/enc_util.cfg);

  • файл с параметрами оборудования и сетевыми интерфейсами (enc_params.cfg.postgres и enc_params.cfg.kmadmin_pg);

  • файлы с засекреченными параметрами подключения к БД (все, что перечислено в конфигурационном файле утилиты enc_util.cfg):

    • /etc/pangolin-security-utilities/enc_connection_settings.cfg;
    • /etc/pangolin-security-utilities/enc_connection_settings_cert.cfg;
    • /etc/pangolin-security-utilities/kms_static_params.cfg;
    • /pg_ssl/intermediate/server.p12.cfg;
    • /pg_ssl/intermediate/patroni_server.p12.cfg;
    • /etc/pangolin-auth-encryption/enc_utils_auth_settings.cfg;
    • /etc/pangolin-manager/postgres.yml;
    • pg_hba.conf.

Управление

Поддержка смещения значения LSN после переноса БД через pg_dump и pg_restore

При миграции базы данных с помощью связки утилит pg_dump и pg_restore значение LSN в новой базе оказывается меньше, чем в исходной. Если переключить логическую репликацию на новую базу, то изменения не будут реплицироваться, так как для корректной работы логической репликации последовательность LSN должна быть возрастающей.

Для решения этой проблемы в СУБД Pangolin реализована утилита psql_set_lsn, которая изменяет значение LSN для указанной базы данных. С ее помощью устанавливается возрастающая последовательность LSN, необходимая для корректной работы логической репликации после переключения на новую базу данных.

Внимание!

Ограничения psql_set_lsn:

• не работает при включенном прозрачном защитном преобразовании (TDE);
• не заполняет память между старым и новым LSN. Таким образом, между старым и новым LSN в WAL-сегменте остается сегмент без записей.

Сведения

Функциональность доступна только для редакций Enterprise и Enterprise для ERP-систем.

Утилита psql_set_lsn поставляется в составе пакета dbms (серверная часть).

Интерфейс утилиты psql_set_lsn

Утилита принимает на вход ключи:

• -D, --pgdata – директория с данными кластера;
• -L, --lsn – LSN, который необходимо установить для базы данных строго в шестнадцатеричном формате. Допускается формат LSN в виде 16 шестнадцатеричных цифр или двух групп по 8 шестнадцатеричных цифр, разделенных слешом (допускаются лидирующие нули);
• -B, --backup-dir – директория для резервной копии изменяемых файлов. По умолчанию сохраняются в PGDATA/psql_set_lsn_backups с таким же именем, как и у оригинальных файлов, но с добавленным суффиксом _backup. Если используется пользовательская директория, она должна быть создана пользователем;
• -S, --skip-error – игнорирование ошибки создания резервных копий изменяемых файлов (Control File и WAL-segment);
• -V, --version – версия psql_set_lsn;
• -h, --help – помощь.

Сценарий использования утилиты

Внимание!

После смещения LSN необходимо создать полную резервную копию кластера, так как после выполнения смещения, в случае аварийной ситуации, восстановиться из сделанной до смещения LSN резервной копии без потери данных будет невозможно.

Пример использования утилиты psql_set_lsn для изменения значения LSN при миграции данных:

1. Создайте копию DB1 при помощи утилит pg_dump и pg_restore;

   

   Сущности на диаграмме:

   • DB1 – первоначальная база данных;
   • relation_1, relation_2, ... , relation_n – отношения в DB1;
   • publication – публикация для отношений relation_1, relation_2, ... , relation_n;
   • replication slot – слот репликации для publication;
   • DB_REP – реплика DB1;
   • subscription – подписка, присоединенная к replication slot;
   • DB2 – копия базы DB1, созданная при помощи pg_dump и pg_restore;
   • lsn_1 - LSN базы DB1;
   • lsn_2 - LSN базы DB2;
   • lsn_rep - LSN базы DB_REP.

2. Остановите базу DB1 и DB_REP.

   

   Сущности на диаграмме аналогичны сущностям на диаграмме в пункте 1.

3. Определите LSN базы DB1, например, при помощи pg_controldata:

   pg_controldata -D <DB1_dir>/data | grep 'Latest checkpoint location';

   <DB1_dir> – каталог базы DB1.

4. При помощи утилиты psql_set_lsn обновите LSN у БД2:

   psql_set_lsn -D <DB2_dir>/data -L lsn_1;

   <DB2_dir> – каталог базы DB2.

5. Запустите базы DB2 и DB_REP.

6. Убедитесь, что в DB2 есть необходимый слот репликации, если нет, создайте его при помощи pg_create_logical_replication_slot.

7. Перенаправьте подписку базы DB_REP на базу DB2 при помощи ALTER SUBSCRIPTION.

8. Выполните рестарт DB2 и DB_REP, если в пункте 6 создавался слот репликации или в пункте 7 переподключалась подписка DB_REP. Изменения базы DB2 должны реплицироваться в базу DB_REP:

   

Сценарии использования

Восстановление БД из резервной копии

Восстановление экземпляра СУБД в конфигурации standalone

Обозначения

Здесь и далее в примерах{version} – текущая версия СУБД Pangolin – 06.

1. Остановите СУБД:

   • Если установка была выполнена автоматизированными скриптами Ansible:

     systemctl --user stop postgresql.service

   • Если установка СУБД была выполнена вручную:

     sudo systemctl stop postgresql.service

2. Очистите каталоги data и tablespaces:

   rm -rf /pgdata/{version}/data
   rm -rf /pgdata/{version}/tablespaces

3. Создайте конфигурационный файл recovery.conf:

   recovery_target_timeline = 'latest'
   restore_command = '/opt/pangolin-backup-tools/bin/pg_probackup archive-get -B /pgarclogs/{version} --instance new_clustername --wal-file-path=%p --wal-file-name=%f -j 4 --batch-size=100'

4. Восстановите из резервной копии данные /pgarclogs/{version}, /pgdata/{version}/data, /pgdata/{version}/tablespaces на новый сервер (процесс восстановления зависит от используемого процесса создания РК).

5. Скопируйте файл /pgarclogs/{version}/backups/clustername/pg_probackup.conf в /pgarclogs/{version}/backups/new_clustername/pg_probackup.conf и исправьте в нем system-identifier (clustername и new_clustername замените на действительные имена кластеров):

   # Backup instance information
   pgdata = /pgdata/{version}/data
   system-identifier = 6855546122949875180
   xlog-seg-size = 16777216
   # Connection parameters
   pgdatabase = postgres
   pghost = {IP}
   pgport = {port}
   pguser = backup_user

6. Запустите сервис СУБД, чтобы убедиться что БД запустилась, и загружаются файлы журналов (в логах отсутствуют ошибки применения WAL-файлов):

   • Если установка была выполнена автоматизированными скриптами Ansible:

     systemctl --user start postgresql.service
     less $(cat /pgdata/{version}/data/current_logfiles| cut -d ' ' -f2)

   • Если установка СУБД была выполнена вручную:

     sudo systemctl start postgresql.service
     less $(cat /pgdata/{version}/data/current_logfiles| cut -d ' ' -f2)

Восстановление сервера реплики из резервной копии

Обозначения

Здесь и далее в примерах{version} – текущая версия СУБД Pangolin – 06.

1. Остановите сервис Pangolin Manager на реплике:

   • Если установка была выполнена автоматизированными скриптами Ansible:

     systemctl --user stop pangolin-manager

   • Если установка СУБД была выполнена вручную:

     sudo systemctl stop pangolin-manager

2. Очистите каталоги data и tablespaces на реплике:

   rm -rf /pgdata/{version}/data
   rm -rf /pgdata/{version}/tablespaces

3. Исправьте конфигурационный файл Pangolin Manager (добавьте секцию recovery_conf):

   parameters:
     archive_mode: 'always'
     archive_command: '/opt/pangolin-backup-tools/bin/pg_probackup archive-push -B /pgarclogs/{version} --instance clustername --wal-file-path=%p --wal-file-name=%f --compress --overwrite -j 4 --batch-size=100'
     wal_sync_method: 'fsync'
     work_mem: '16384kB'
     is_tde_on: 'off'
   recovery_conf:
     recovery_target_time: latest
     standby_mode: off
     restore_command: /opt/pangolin-backup-tools/bin/pg_probackup archive-get -B /pgarclogs/{version} --instance clustername --wal-file-path=%p --wal-file-name=%f -j 4 --batch-size=100

   Внимание!

   При повышенной нагрузке восстановление реплики до состояния ведущего сервера может занять продолжительное время. Необходимо или снизить нагрузку на мастер, или произвести дополнительное резервное копирования WAL-файлов ведущего сервера.

4. Восстановите из резервной копии (процесс восстановления зависит от используемого процесса создания РК) данные /pgarclogs/{version}, /pgdata/{version}/data, /pgdata/{version}/tablespaces на новый сервер.

5. Запустите сервис Pangolin Manager и убедитесь, что БД запущена и файлы журналов загружаются. Дождитесь синхронизации и убедитесь, что кластер перешел в синхронный режим (Sync Standby):

   • Если установка была выполнена автоматизированными скриптами Ansible:

     systemctl --user start pangolin-manager
     less $(cat /pgdata/{version}/data/current_logfiles| cut -d ' ' -f2)
     pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml list clustername

   • Если установка СУБД была выполнена вручную:

     sudo systemctl start pangolin-manager
     less $(cat /pgdata/{version}/data/current_logfiles| cut -d ' ' -f2)
     pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml list clustername