Уровень 2.0

Предусловие:

• Изучен материал лекции 4 «Протокол репликации и архив WAL» курса DBA3

В этом задании:

• Общие сведения о физическом резервном копировании
• Холодное и горячее резервное копирование
• Утилита pg_probackup

Физическое резервное копирование

Понятие физического резервного копирования и восстановления

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

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

Высокая скорость создания копий позволяет выполнять физическое резервирование на регулярной основе, сокращая период времени, за который могут быть потеряны данные (Recovery Point Objective, RPO).

Высокая скорость восстановления данных позволяет сократить время простоя системы после сбоя (Recovery Time Objective, RTO). При этом не требуется выполнение сбора статистики для планировщика (например, командой ANALYZE), поскольку она содержится в копии.

Однако ценой этого является наличие некоторых ограничений, основным из которых является возможность восстановления только на совместимой платформе (разрядность, ОС и т. д.) и на той же основной версии Pangolin.

Помимо этого, физическое резервирование позволяет сделать копию только всего кластера баз данных. Копирование отдельных объектов или баз данных невозможно.

Возможности средств резервного копирования и восстановления

Эффективность выполнения резервного копирования и восстановления в первую очередь зависит от предоставляемых функциональных возможностей соответствующих средств, среди которых можно выделить следующие:

• Создание копий без остановки экземпляра сервера
• Поддержка централизованного хранилища и политик хранения копий
• Создание инкрементальных копий
• Параллельное копирование и восстановление
• Поддержка алгоритмов сжатия
• Автоматическая проверка целостности созданных копий
• Восстановление на определенный момент времени

Создание копий без остановки экземпляра сервера позволяет не прерывать обслуживание клиентов.

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

Инкрементальное копирование позволяет уменьшить размер и время создания копий. Под инкрементальным копированием понимается метод, при котором в копию попадают только изменения с момента последнего резервного копирования.

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

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

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

Холодное и горячее резервные копирования

Как было упомянуто выше, создание копии может выполняться как при остановленном экземпляре сервера, так и при работающем.

Холодное резервное копирование

Холодное резервное копирование предполагает копирование файлов каталога данных PGDATA (и табличных пространств, если используются) после остановки экземпляра сервера.

При этом необязательно, чтобы экземпляр был остановлен аккуратно (с выполнением контрольной точки). Важно, чтобы все копируемые файлы имели состояние на один и тот же момент времени.

Восстановление данных в таком случае происходит просто — при запуске экземпляра в качестве каталога данных указывается скопированный каталог.

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

Холодное резервное копирование требует останова экземпляра и, следовательно, связано с простоем системы.

С ростом объема кластера баз данных также растет время простоя, необходимое для создания резервной копии. Рано или поздно оно становится неприемлемым, поэтому требуется какой-либо способ создания физической копии без останова экземпляра при постоянно меняющихся данных.

Такой способ, конечно, есть, его называют горячим резервным копированием.

Горячее резервное копирование

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

Общий алгоритм создания горячей физической копии представлен на рисунке ниже.

Перед началом создания копии с использованием параметра full_page_writes включается сохранение в журнальных записях полного образа страниц (Full Page Image, FPI). Вспомним, что в этом случае FPI сохраняется в WAL при первом изменении страницы после выполнения контрольной точки.

Это необходимо для решения проблемы неатомарности записи страниц операционной системой. При восстановлении записи WAL будут применяться именно к FPI, а не страницам в файле, которые могут оказаться «испорченными».

Далее запрашивается выполнение контрольной точки, чтобы сбросить в файлы данных страницы из кеша буферов и гарантировать наличие FPI в записях WAL для измененных страниц.

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

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

Указанный алгоритм реализован в базовой утилите создания физических резервных копий pg_basebackup, которая входит в состав оригинальной версии PostgreSQL.

К сожалению, pg_basebackup имеет ограниченную функциональность, которая, в частности, не предусматривает поддержку централизованного хранилища копий, возможности создания инкрементальных копий, проверки целостности созданных копий и восстановления данных на произвольный момент времени (PITR).

Однако в ядре PostgreSQL предусмотрено низкоуровневое API, реализующее приведенный алгоритм. Указанное API можно использовать для создания более развитых средств резервного копирования.

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

Утилита pg_probackup

Утилита pg_probackup является мощным средством регулярного физического резервирования, обладающим следующими основными возможностями:

• Поддержка централизованного хранилища (каталога) и политики хранения копий
• Локальное или удаленное резервное копирование
• Инкрементальное копирование и восстановление (в трех режимах: DELTA, PAGE и PTRACK)
• Автоматическая проверка целостности созданных копий
• Параллельное резервное копирование и восстановление
• Архивирование сегментов WAL
• Восстановление на момент времени (PITR)
• Поддержка сжатия данных

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

Полный список возможностей pg_probackup приведен в документации.

Каталог копий

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

Для его инициализации применяется команда pg_probackup init, например:

[postgres@ServerName ~]$ pg_probackup init -B /pangolin_backups

Каталог резервных копий указывается с помощью ключа -B. Его владельцем должен быть тот пользователь, от имени которого запускается pg_probackup.

При инициализации в каталоге копий создается два каталога:

[postgres@ServerName ~]$ ls -1 /pangolin_backups
backups
wal

Каталог backups предназначен непосредственно для резервных копий кластеров баз данных, каталог wal — для архивов WAL.

Экземпляры сервера, для которых планируется выполнение резервного копирования кластеров баз данных, необходимо зарегистрировать в каталоге копий.

Для этого предназначена команда pg_probackup add-instance, например:

[postgres@ServerName ~]$ pg_probackup add-instance -B /pangolin_backups -D /pgdata/\{major-minor\}.0/data/ --instance=pangolin_6_6

В данной команде указывается каталог копий (ключ -B), каталог данных экземпляра (ключ -D) и условное имя экземпляра (ключ --instance), которым будут названы подкаталоги данных копий и архивов WAL.

Помимо этого, в случае удаленного расположения экземпляра сервера необходимо указать параметры удаленного режима.

Стоит отметить, что при удаленном расположении экземпляра сервера pg_probackup подключается к нему не напрямую, а посредством своего агента, который устанавливается с pg_probackup в месте расположения экземпляра. Взаимодействие pg_probackup и агента pg_probackup обычно осуществляется посредством протокола SSH.

После регистрации экземпляра содержимое каталога копий выглядит следующим образом:

[postgres@ServerName ~]$ tree /pangolin_backups
pangolin_backups/
├── backups
│   └── pangolin_6_6
│       └── pg_probackup.conf
└── wal
    └── pangolin_6_6

В каталогах backups и wal созданы подкаталоги, названные заданным именем экземпляра. Помимо этого, создан конфигурационный файл pg_probackup.conf для зарегистрированного экземпляра, содержимое которого представлено ниже:

# Backup instance information
pgdata = /pgdata/\{major-minor\}.0/data
system-identifier = 7561519366850455694
xlog-seg-size = 16777216

Экземпляру был присвоен идентификатор, сгенерированный утилитой pg_probackup и сохраненный в поле system-identifier.

Каждый раз перед созданием копии pg_probackup вычисляет указанный идентификатор заново и сверяет его со значением, записанным в поле system-identifier. Это необходимо для исключения ошибок, связанных с созданием копий разных кластеров баз данных в каталоге одного экземпляра.

Настройка параметров резервного копирования

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

Они могут задаваться либо с использованием ключей в командах pg_probackup, либо в конфигурационном файле pg_probackup.conf.

Для сохранения значений параметров в конфигурационном файле предусмотрена команда pg_probackup set-config.

Например, политика хранения копий может быть настроена следующим образом:

[postgres@ServerName ~]$ pg_probackup set-config -B /pangolin_backups --instance=pangolin_6_6 --retention-window=30 --retention-redundancy=2

Параметр retention-window задает количество дней, за которое должно быть возможно восстановление данных, в то время как retention-redundancy задает количество полных копий.

В этом случае должны храниться по крайней мере две полные копии и все необходимые копии (инкрементальные или полные) для возможности восстановления данных за последние 30 дней. Остальные копии могут быть удалены командой pg_probackup delete.

Текущие значения конфигурационных параметров могут быть получены не только из файла pg_probackup.conf. Для этой цели также может использоваться команда pg_probackup show-config, например:

[postgres@ServerName ~]$ pg_probackup show-config -B /pangolin_backups --instance=pangolin_6_6 | grep retention
retention-redundancy = 2
retention-window = 30

Способы доставки сегментов WAL

Создание копии в pg_probackup выполняется командой pg_probackup backup.

При этом доставка сегментов WAL возможна двумя способами, определяемыми следующими ключами указанной команды:

• --archive — непрерывное архивирование (используется по умолчанию)
• --stream — с использованием протокола репликации

По умолчанию копия создается в предположении, что настроено непрерывное архивирование сегментов WAL.

Вспомним, что для настройки непрерывного архивирования необходимо его включить с использованием параметра экземпляра archive_mode (on или always) и задать команду копирования в параметре archive_command.

При использовании pg_probackup в archive_command должна быть указана команда pg_probackup archive-push.

Например, настройка непрерывного архивирования может быть выполнена следующим образом:

postgres=# ALTER SYSTEM SET archive_mode = on;
ALTER SYSTEM

postgres=# ALTER SYSTEM SET archive_command = 'pg_probackup archive-push -B /pangolin_backups --instance=pangolin_6_6 --wal-file-path=%p --wal-file-name=%f';
ALTER SYSTEM

На самом деле использование команды pg_probackup archive-push в параметре archive_command не обязательно. Можно использовать любую другую команду, при условии, что она будет копировать сегменты WAL в каталог_копий/wal/имя_экземпляра.

В данном случае архивирование WAL настроено локально, поэтому необходимо, чтобы каталог копий принадлежал пользователю postgres, так как от его имени выполняется команда archive_command.

Режим непрерывного архивирования используется по умолчанию, поскольку архив WAL также применяется при инкрементальном копировании в режиме PAGE и при восстановлении на момент времени (PITR).

При использовании режима --stream доставка журнальных записей осуществляется по протоколу репликации непосредственно в создаваемую копию (вне зависимости от того, выполняется ли непрерывное архивирование).

В этом случае в копии содержатся все необходимые для восстановления согласованности данных файлы. Поэтому такую копию называют автономной.

При создании копии в режиме --stream для гарантии сохранности необходимых записей WAL может использоваться временный слот репликации (ключ --temp-slot).

Полная копия

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

Создание полной копии выполняется командой pg_probackup backup -b FULL.

Например, команда создания полной резервной копии в потоковом режиме может выглядеть следующим образом:

[postgres@ServerName ~]$ pg_probackup backup -b FULL -B /pangolin_backups --instance pangolin_6_6 --stream --temp-slot

Информацию о созданных копиях можно получить командой pg_probackup show:

[postgres@ServerName ~]$ pg_probackup show -B /pangolin_backups --instance pangolin_6_6====================================================================================================================================
 Instance      Version  ID      Recovery Time           Mode  WAL Mode  TLI  Time  Data   WAL  Zratio  Start LSN  Stop LSN   Status
====================================================================================================================================
 pangolin_6_6  15       T4A8HX  2025-10-17 15:32:23+00  FULL  STREAM    1/0   10s  27MB  16MB    1.00  0/4000028  0/40001E0  OK

Каждой копии присваивается уникальный идентификатор (поле ID). Копия сохраняется в каталоге, названном указанным идентификатором. Содержимое каталога представлено ниже:

[postgres@ServerName ~]$ ls -1 ~/pangolin_backups/backups/pangolin_major.minor/T4A8HX/
backup_content.control
backup.control
database
page_header_map

В нем имеется каталог database, который является каталогом данных кластера баз данных (PGDATA), а также следующие файлы:

• backup.control — метаданные копии, необходимые для восстановления данных из нее
• backup_content.control — информация обо всех файлах в составе копии
• page_header_map — карта заголовков страниц с контрольными суммами

В файле backup.control среди прочего хранятся параметры start-lsn и stop-lsn, определяющие диапазон записей WAL, необходимых для восстановления согласованности.

В этом файле также имеется параметр timelineid, определяющий номер линии времени, который необходим для возможности восстановления на момент времени в прошлом (PITR). Указанная процедура будет рассмотрена ниже.

Для восстановления кластера из созданной копии применяется команда pg_probackup restore.

По умолчанию восстановление выполняется с использованием последней подходящей копии заданного экземпляра. Однако идентификатор необходимой копии может быть указан явно с использованием ключа -i, например:

[postgres@ServerName ~]$ pg_probackup restore -B /pangolin_backups --instance -i T4A8HX

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

Однако это может быть выполнено отдельно — с использованием команды pg_probackup validate.

Инкрементальная копия

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

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

Инкрементальное копирование в pg_probackup может выполняться в трех режимах:

• DELTA — разностное копирование
• PAGE — страничное копирование
• PTRACK — копирование изменений

В режиме DELTA поиск измененных страниц выполняется путем полного сканирования файлов данных. При разностном копировании объем ввода/вывода может быть сопоставим с соответствующим объемом при создании полной резервной копии. Тем не менее размер разностной копии обычно существенно меньше размера полной копии.

Основным преимуществом режима DELTA является отсутствие необходимости наличия архива WAL и использования каких-либо дополнительных средств.

В режиме PAGE поиск информации об измененных страницах осуществляется в сегментах WAL. Для этого должно быть настроено непрерывное архивирование. Данный метод эффективен, когда размер сегментов WAL существенно меньше размера файлов данных кластера. Иначе объем ввода/вывода также будет сопоставим с соответствующим объемом при создании полной резервной копии.

В режиме PTRACK происходящие изменения в страницах данных сразу фиксируются в специальной битовой карте. Отслеживанием изменений в экземпляре занимается расширение ptrack, которое должно быть заранее установлено и добавлено в загружаемые разделяемые библиотеки (shared_preload_libraries).

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

Стоит отметить, что при инкрементальном создании копии также необходимо обеспечить наличие записей WAL за период создания копии. Сделать это можно так же, как и при полном копировании, то есть в двух режимах: --archive и --stream.

Восстановление на момент времени (PITR)

При настроенном непрерывном архивировании возможно восстановление на заданный момент времени.

Реализуется это путем остановки применения записей WAL при восстановлении данных.

Момент времени, до которого необходимо применять записи WAL, задается в команде pg_probackup restore с использованием одного из следующих ключей:

• --recovery-target-time — до определенного момента времени
• --recovery-target-xid — до транзакции с заданным номером
• --recovery-targer-lsn — до заданного LSN
• --recovery-target-name — до точки с заданным именем (имя точки должно быть заранее задано функцией pg_create_restore_point('имя_точки'))
• --recovery-target=latest — до последнего согласованного состояния
• --recovery-target=immediate — до самого раннего согласованного состояния

При восстановлении на момент времени копия для восстановления может быть указана явно с использованием ключа -i или автоматически — ближайшая к заданной цели восстановления.

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

Номер линии времени используется при формировании названия сегмента (первые 8 шестнадцатеричных знаков).

Итоги

• Физическое резервное копирование — основной вид регулярного резервирования данных, подразумевающий копирование файлов каталога данных
• Горячее резервирование требует принятия некоторых мер для гарантии возможности восстановления данных из копии
• Утилита pg_probackup — функциональное средство горячего резервирования
• Утилита pg_probackup в том числе обеспечивает инкрементальное копирование, параллельную работу, сжатие, восстановление на определенный момент времени

Самопроверка

Вопрос 1

Какие ограничения имеются у метода физического резервного копирования? Выберите все верные варианты ответа:

Возможность восстановления данных из копии только на совместимой платформе

Возможность восстановления данных из копии только на той же основной версии Pangolin

Отсутствие возможности создания копии с использованием нескольких потоков

Отсутствие возможности создания копии отдельной базы данных

Вопрос 2

Какие меры предпринимаются средствами горячего резервирования для гарантии возможности восстановления данных из копии? Выберите все верные варианты ответа:

Остановка экземпляра сервера с выполнением контрольной точки

Обеспечение наличия записей WAL, сгенерированных за время резервного копирования

Включение подсчета контрольных сумм для страниц данных

Сохранение полных образов страниц в записях WAL

Вопрос 3

Для каких режимов инкрементального копирования в pg_probackup должно быть настроено непрерывное архивирование сегментов WAL?

PAGE

DELTA

PTRACK

Вопрос 4

Что необходимо настроить в pg_probackup для возможности выполнения восстановления данных на определенный момент времени (PITR)?

Политику хранения копий

Инкрементальное копирование

Непрерывное архивирование сегментов WAL