Обзор Arenadata DB Backup Manager
Функции
Arenadata DB Backup Manager (ADBM) — это построенная на основе pgBackRest отказоустойчивая система для управления бинарными бэкапами ADB.
Основные функциональные возможности ADBM перечислены ниже:
-
Гибкая настройка политик формирования бэкапов, включая отдельные расписания для различных их видов.
-
Формирование бэкапов согласно настроенному расписанию и вручную.
-
Ведение списка бэкапов с возможностью их поиска и просмотра деталей, в том числе кластерной топологии.
-
Удаление бэкапов в соответствии с настроенными политиками по расписанию и вручную.
-
Создание точек восстановления (restore points) согласно установленному расписанию и вручную.
-
Восстановление баз данных на момент выбранной restore point.
-
Логирование всех производимых в системе операций с возможностью детального просмотра действий, завершившихся сбоем.
-
Поддержка работы с несколькими кластерами ADB различных типов (с/без Standby и зеркалирования).
-
Поддержка S3- и Posix-совместимых хранилищ для бэкапов.
|
ПРИМЕЧАНИЕ
|
Архитектура
Верхнеуровневая архитектурная схема ADBM приведена ниже.
Основные компоненты архитектуры ADBM:
-
Backup Manager. Осуществляет оркестрацию кластерных действий и выполнение фоновой работы согласно настроенным расписаниям: создание бэкапов и точек восстановления, их очистку и так далее. Взаимодействие Backup Manager и кластера ADB происходит через агентов Backup Agent.
-
Backup Agent. Агенты устанавливаются по одному на каждый хост кластера ADB и отвечают за непосредственную работу с данными сегментов:
-
Запуск необходимых команд pgBackRest.
-
Управление конфигурацией pgBackRest.
-
На Master-хосте — операции по управлению кластером ADB (например, перезапуск).
-
-
etcd. Это согласованное распределенное хранилище данных в формате ключ/значение, которое используется в качестве координационного сервиса в распределенных системах. В ADBM etcd предоставляет две основные функции:
-
Хранение распределенных блокировок на уровне кластера для обеспечения эксклюзивности запускаемых действий.
-
Хранение информации о состоянии текущего активного действия. В случае если Backup Manager останавливается или выходит из строя — метаданные о текущем действии берутся из etcd.
-
-
Service Registry. Отвечает за Service Discovery в ADBM. Обеспечивает обнаружение доступных агентов (преднастроенной карты агентов в системе нет) и поиск необходимых сервисов ADBM со стороны агентов (для отправки ответов). Так как Backup Manager может работать с несколькими кластерами ADB одновременно, при добавлении кластера новые агенты также регистрируются в Service Registry.
-
PostgreSQL. Используется для хранения исторических данных по бэкапам и конфигурациям. По умолчанию поднимается в контейнере. Также существует возможность подключения внешней базы данных PostgreSQL.
|
ПРИМЕЧАНИЕ
Чтобы использовать внешний PostgreSQL, заполните параметры секции External database parameters при конфигурировании сервиса ADBM во время установки кластера ADB (см. Конфигурационные параметры → ADBM → External database parameters). |
Концепции
ADBM реализует Point-in-Time Recovery (PITR) — возможность восстановления баз данных на выбранный момент времени в прошлом. В основе этого подхода используется несколько концепций, кратко описанных ниже.
Бэкап
Бэкап (backup) — это консистентная копия данных кластера ADB, которая может быть использована для восстановления БД в случае аппаратных и других сбоев. ADBM поддерживает следующие типы бэкапов:
-
Полный (full). При формировании полной резервной копии все содержимое базы данных помещается в бэкап. Первый запущенный в рамках текущего timeline бэкап всегда будет иметь тип full в ADBM, даже если согласно расписанию (или выбору пользователя — в случае ручного запуска) первыми следуют дифференциальная либо инкрементная резервные копии. Восстановление полного бэкапа возможно напрямую, так как он не зависит от каких-либо внешних файлов из других бэкапов. Преимуществом полного резервного копирования является быстрое восстановление всех файлов (по сравнению с другими видами). Однако полные копии не рекомендуются для регулярного резервного копирования (ежечасного или ежедневного), поскольку требуют много времени на формирование и занимают значительное место на диске.
-
Дифференциальный (differential). В дифференциальный бэкап помещаются только те файлы базы данных, которые изменились после запуска последнего полного бэкапа. По сравнению с полной копией дифференциальный бэкап формируется быстрее и занимает меньше дискового пространства. Однако для восстановления бэкапа этого типа потребуется копирование не только его содержимого, но и файлов из последнего полного бэкапа.
-
Инкрементный (incremental). В инкрементный бэкап помещаются только файлы, изменившиеся с момента запуска последнего бэкапа любого типа (полного, дифференциального либо инкрементного). Из всех видов резервных копий инкрементные формируются быстрее всего и занимают минимальное место на диске. Однако их восстановление происходит дольше, поскольку необходимо извлечь файлы из последней полной и, при наличии, дифференциальной копии, а затем последовательно применить все последующие инкрементные бэкапы.
WAL
Write-Ahead Log (WAL) — это стандартный механизм, гарантирующий что закоммиченные изменения не будут потеряны. Все изменения файлов с данными (хранящих таблицы, индексы и так далее) записываются последовательно в WAL. По прошествии некоторого времени фоновый процесс записывает изменения в основные файлы с данными. В случае сбоев записи WAL можно воспроизвести для возврата БД в консистентное состояние.
WAL разбивается на индивидуальные файлы по 64 МБ, называемые сегментами (segments). Каждая запись в сегменте имеет 16-значный логический последовательный номер (Logical Sequence Number, LSN), используемый для поиска записи по смещению в текущем сегменте. Название сегмента, в свою очередь, формируется из номера timeline и LSN первой записи сегмента.
Использование WAL существенно сокращает количество операций записи на диск, так как нет необходимости записывать файлы данных после каждого коммита транзакции. Только WAL-файлы должны быть записаны на диск, чтобы гарантировать фиксацию транзакции.
WAL играет важную роль в механизме Point-in-Time Recovery (PITR), используемом в ADBM. Архивируя WAL-файлы, ADBM позволяет восстанавливать БД на момент любой точки, покрываемой имеющимися данными WAL. Фактически процесс восстановления включает два основных шага:
-
Установить один или несколько предыдущих бэкапов.
-
Воспроизвести записи WAL, сделанные после последнего загруженного бэкапа, до нужной именованной точки.
Restore point
Restore point — это именованная точка восстановления, которая является минимальной единицей гранулярности согласования данных в кластере ADB. После добавления restore point (по расписанию или вручную) ADBM позволяет восстановить базы данных кластера на момент создания этой точки. Для каждой созданной restore point ADBM хранит информацию о том, какие бэкапы потребуется восстановить и какие WAL-сегменты воспроизвести, чтобы вернуть БД в состояние на момент создания этой точки.
Для лучшего понимания механизма работы restore points можно обратиться к рисунку ниже.
Приведенная ниже таблица демонстрирует, какие бэкапы и WAL-файлы будут использованы, если выбрать одну из изображенных точек восстановления при выполнении действия Restore.
| Выбранная restore point | Объекты, используемые для восстановления |
|---|---|
rp1 |
full1, WAL1 |
rp2 |
full1, diff1, incr1, incr2, WAL2 |
rp3 |
full1, diff2, incr3, incr4, WAL3 |
Timeline
Timeline — это механизм, используемый в ADBM для того, чтобы отличать серии WAL, сгенерированные после восстановления БД на определенный момент времени, от тех, которые были созданы в исходной истории базы данных (до применения восстановления).
Предположим, что для восстановления БД на момент создания некоторой restore point после загрузки одного или нескольких бэкапов требуется воспроизведение WAL1 (номер использован с целью упрощения). После успешного восстановления архива заполнение WAL продолжится и, если архивы WAL будут помещаться в ту же директорию, последующие записи WAL перезапишут те, что могли существовать в исходной истории БД после выбранной точки восстановления (WAL2, WAL3 и так далее). А это, в свою очередь, приведет к невозможности восстановления БД для других точек, добавленных перед восстановлением.
Чтобы избежать описанных коллизий, в ADBM после каждого восстановления данных инциализируется новый номер timeline для идентификации архивов WAL, созданных после восстановления. Нумерация timeline в системе ведется с 0, при каждом успешном применении Restore номер увеличивается на единицу. Этот номер фиксируется в названиях директорий, хранящих архивы WAL и бэкапы с разбиением по сегментам (так называемые stanza). При каждом восстановлении данных создаются все необходимые директории с новым номером timeline в названии, и все последующие записи WAL помещаются в новые директории, не перезаписывая данные в директориях с предыдущим номером.
|
ВАЖНО
Поскольку вновь создаваемые директории изначально не содержат бэкапов, первый бэкап после каждого восстановления данных будет полным ( |
Следующий рисунок иллюстрирует описанный процесс в упрощенном виде. После восстановления на момент точки rp1 воспроизводится WAL1 и создается timeline1. Последующие записи WAL помещаются в новые директории. При следующем восстановлении создается timeline2 и так далее. Обратите внимание, что после создания timeline1 и timeline2 по-прежнему сохраняется возможность восстановиться на момент точки rp2 — без применения концепции timeline это было бы невозможно.
Начало работы
Типовая последовательность действий при работе с ADBM через web-интерфейс включает следующие шаги:
-
Создание конфигурации, которая будет использоваться для формирования бэкапов и других связанных действий.
-
Запуск бэкапов вручную либо ожидание их автоматического формирования по расписанию. При необходимости — просмотр сведений о сформированных бэкапах.
-
Создание точек восстановления вручную либо ожидание их автоматического формирования по расписанию.
-
Выполнение эксплуатационных действий при необходимости:
-
Восстановление баз данных, если возникнет необходимость вернуться к состоянию на момент одной из созданных restore points.
На каждом из описанных шагов есть возможность просмотра деталей выполняющихся действий, включая причины зафиксированных сбоев (при их наличии).