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

Azure Backup предлагает встроенную прескрипционную и постскрипционную платформу , чтобы обеспечить согласованность приложений для виртуальных машин Linux во время резервного копирования. Этот фреймворк автоматически запускает предварительный скрипт для приостановки приложений перед моментальными снимками диска и пост-скрипт для восстановления приложений к нормальной работе после снимка.

Управление пользовательскими прескриптелями и постскриптелями часто является сложным и трудоемким. Чтобы упростить этот процесс, Azure Backup предоставляет готовые к использованию скрипты предварительной и постобработки для распространенных баз данных, чтобы создать согласованные с приложениями моментальные снимки с минимальными усилиями и затратами на обслуживание.

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

Основные преимущества расширенного фреймворка предварительного и завершающего скрипта

Новая улучшенная платформа предскрипта и постскрипта имеет следующие ключевые преимущества:

• Эти прескрипты и постскрипты устанавливаются непосредственно на виртуальных машинах Azure вместе с расширением резервного копирования, что помогает избежать авторинга и загрузки их из внешнего местоположения.
• Определение и содержимое предписок и постскрипторов доступны для просмотра на сайте GitHub. Вы можете отправлять предложения и изменения с помощью GitHub, которые рассматриваются и включаются, чтобы приносить пользу более широкому сообществу.
• Новые предварительные инструкции и дополнительные инструкции для других баз данных доступны через GitHub, которые отсортированы и предназначены для того, чтобы приносить пользу широкому сообществу.
• Надежная платформа эффективна для обработки сценариев, таких как сбой выполнения предписи или сбой. В любом случае постскрипт автоматически запускается для отката всех изменений, выполненных в предскрипте.
• Платформа также предоставляет канал обмена сообщениями для внешних средств для получения обновлений и подготовки собственного плана действий по любому сообщению или событию.

Поток процессов в расширенной системе предписаний и постскриптумов

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

Матрица поддержки

Следующие базы данных рассматриваются в расширенной платформе:

• Oracle (общедоступная версия): см. матрицу поддержки для резервных копий виртуальных машин Azure.
• MySQL (предварительная версия).

Предварительные требования

Для предоставления сведений о подключении необходимо изменить только файл конфигурации, workload.conf in /etc/azure. Таким образом, Azure Backup может подключаться к соответствующему приложению и запускать предварительные скрипты и послескрипты. Файл конфигурации имеет следующие параметры:

[workload]
# valid values are mysql, oracle
workload_name =
command_path = 
linux_user =
credString = 
ipc_folder = 
timeout =

В следующей таблице описаны параметры.

Параметр	Обязательно	Описание
workload_name	Да	Содержит имя базы данных, для которой требуется резервное копирование, согласованное с приложением. Текущие поддерживаемые значения: oracle и mysql.
command_path/configuration_path		Содержит путь к двоичному файлу рабочей нагрузки. Это поле не является обязательным, если двоичный файл нагрузки задан в качестве переменной пути.
linux_user	Да	Содержит имя пользователя Linux с доступом к учетной записи пользователя базы данных. Если это значение не задано, root считается пользователем по умолчанию.
credString		Обозначает строку учетных данных для подключения к базе данных. Содержит всю строку входа.
ipc_folder		Рабочая нагрузка может записывать только определенные пути файловой системы. Укажите этот путь к папке, чтобы предстрочный код смог записать состояния в этот путь к папке.
timeout	Да	Максимальное ограничение времени, для которого база данных находится в спокойном состоянии. Значение по умолчанию — 90 секунд. Не устанавливайте значение менее 60 секунд.

Примечание.

Определение JSON — это шаблон, который Azure Backup может изменить в соответствии с определенной базой данных. Чтобы понять файл конфигурации для каждой базы данных, ознакомьтесь с руководством каждой базы данных.

Общее впечатление от использования улучшенной системы прескрипта и постскрипта:

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

Создание стратегии резервного копирования базы данных

Использование моментальных снимков вместо потоковой передачи

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

• Производительность и стоимость: ежедневное полное резервное копирование и журналы являются самыми быстрыми во время восстановления, но включает значительные затраты. Включение разностного или добавочного типа резервного копирования потоковой передачи снижает затраты, но может повлиять на производительность восстановления. Однако наилучшее сочетание производительности и затрат обеспечивают моментальные снимки. Так как моментальные снимки по сути являются добавочными, они имеют наименьшее влияние на производительность во время резервного копирования, восстанавливаются быстро, а также экономят затраты.
• Влияние на базу данных или инфраструктуру: производительность потоковой резервной копии зависит от базовых операций ввода-вывода в секунду хранилища и пропускной способности сети, доступной, когда поток предназначен для удаленного расположения. Моментальные снимки не имеют этой зависимости, и нагрузка на IOPS и пропускная способность сети уменьшена.
• Возможность повторного использования. Команды для активации различных типов резервных копий потоковой передачи отличаются для каждой базы данных, поэтому скрипты не могут быть легко использованы повторно. Кроме того, если вы используете различные типы резервных копий, обязательно оцените цепочку зависимостей для поддержания жизненного цикла. Для моментальных снимков легко писать скрипт, так как нет цепочки зависимостей.
• Долгосрочное хранение: полные резервные копии всегда полезны для долгосрочного хранения, так как вы можете перемещать и восстанавливать их независимо. Для операционных резервных копий с краткосрочным хранением моментальные снимки предпочтительны.

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

Стратегия резервного копирования журналов

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

Сетевая файловая система (NFS) в хранилище BLOB-объектов Azure и NFS в AFS (предварительная версия) обеспечивают легкое подключение томов непосредственно к виртуальным машинам базы данных и использование клиентских приложений баз данных для передачи резервных копий журналов. Окно потери данных, известное как RPO (Целевое Время Восстановления), зависит от частоты резервного копирования журналов. Кроме того, целевые объекты NFS не должны быть высокопроизводительными. Возможно, вам не нужно включать регулярную потоковую передачу (полную и добавочную) для операционных резервных копий после создания согласованных снимков базы данных.

Примечание.

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

Стратегия восстановления

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

• Создайте новые виртуальные машины из точки восстановления, совместимой с базой данных. На виртуальной машине уже должна быть подключена точка монтирования журнала. Используйте клиенты баз данных для выполнения команд восстановления на конкретный момент времени.
• Создайте диски из точки восстановления, согласованной с базой данных, и подключите их к другой целевой виртуальной машине. Затем подключите пункт назначения журнала и используйте клиенты базы данных для выполнения команд восстановления для восстановления на заданный момент времени.
• Используйте параметр восстановления файлов и создайте скрипт. Запустите скрипт на целевой виртуальной машине и подключите точку восстановления как диски iSCSI. Затем проверьте данные резервного копирования с помощью клиентов баз данных, запуская функции проверки для конкретной базы данных на подключенных дисках. Кроме того, используйте клиенты базы данных для экспорта или восстановления нескольких таблиц или файлов вместо восстановления всей базы данных.
• Используйте функцию восстановления данных между регионами для выполнения первоначальных действий из парных вторичных регионов во время регионального сбоя.

Итоги

Благодаря согласованным с базой данных моментальным снимкам и журналам, резервное копирование которых осуществляется с помощью пользовательского решения, можно создать решение для резервного копирования базы данных, которое является производительным и экономичным. Это решение использует преимущества резервного копирования виртуальных машин Azure, а также повторно использует возможности клиентов базы данных.