Расширенные сценарии пред- и пост- обработки для создания целостного моментального снимка базы данных.
Служба резервного копирования Azure уже предоставляет платформу предварительных и пост-скриптов для обеспечения согласованности приложений на виртуальных машинах Linux с помощью Azure Backup. Этот процесс включает вызов предварительного скрипта (чтобы заморозить приложения) перед моментальным снимком дисков и вызовом пост-скрипта (команды для отмены замораживания приложений) после завершения моментального снимка, чтобы вернуть приложения в обычный режим.
Создание, отладка и обслуживание скриптов предварительной и последующей работы может быть сложной задачей. Чтобы устранить эту сложность, служба Azure Backup предлагает упрощённое использование скриптов предварительной и постобработки для ключевых баз данных, чтобы обеспечить согласованность приложений и минимальные накладные расходы.
Новая улучшенная платформа скриптов предварительной и последующей обработки имеет следующие основные преимущества:
- Эти предварительные скрипты устанавливаются непосредственно на виртуальных машинах Azure вместе с расширением резервного копирования, что позволяет избежать необходимости их создания и загрузки из внешних источников.
- Определение и содержимое скриптов предварительной и последующей обработки можно просмотреть в GitHub. Можно даже отправить свои предложения и изменения. Вы можете даже отправлять собственные предложения и изменения через GitHub. Они будут рассмотрены и реализованы на пользу более широкого сообщества.
- Вы можете даже добавлять новые скрипты предварительной и последующей обработки для других баз данных через GitHub. Они будут рассмотрены и реализованы на пользу более широкого сообщества.
- Надежная платформа эффективно обрабатывает различные сценарии, например, сбой выполнения или непредвиденное завершение скрипта предварительной обработки. В любом случае скрипт последующей обработки будет запущен автоматически для отката всех изменений, внесенных скриптом предварительной обработки.
- Платформа также предоставляет канал обмена сообщениями, с помощью которого внешние инструменты могут получать обновления и подготавливать собственные планы действий для любых сообщений или событий.
Процесс решения
Матрица поддержки
Улучшенная платформа охватывает следующий список баз данных:
- Oracle (общедоступная версия) - Ссылка на матрицу поддержки
- MySQL (предварительная версия)
Предварительные требования
Вам необходимо только изменить файл конфигурации workload.conf в папке /etc/azure, указав в нем сведения о подключении. Это позволит Azure Backup подключиться к соответствующему приложению и выполнить скрипты предварительной и последующей обработки. В файле конфигурации содержатся следующие параметры.
[workload]
# valid values are mysql, oracle
workload_name =
command_path =
linux_user =
credString =
ipc_folder =
timeout =
В следующей таблице описаны параметры.
| Параметр | Обязательно | Описание |
|---|---|---|
| имя нагрузки | Да | Это будет содержать имя базы данных, для которой необходимо резервное копирование с учетом согласованности приложений. Текущие поддерживаемые значения: oracle и mysql. |
| command_path/configuration_path | Этот параметр будет содержать путь к бинарному файлу рабочей нагрузки. Это не обязательное поле, если двоичный файл рабочей нагрузки задан как переменная пути. | |
| linux_user | Да | Этот параметр будет содержать имя пользователя Linux, у которого есть доступ на вход в базу данных. Если это значение не за установлено, то пользователем по умолчанию является root. |
| credString | Это строка учетных данных для подключения к базе данных. Она будет содержать всю строку входа. | |
| папка_IPC | Рабочая нагрузка может записывать данные только в определенных путях в файловой системе. Необходимо указать здесь соответствующий путь к папке, чтобы скрипт предварительной обработки мог записывать состояния по этому пути. | |
| время ожидания | Да | Это максимальное время, в течение которого база данных будет находиться в состоянии заморозки. Значение по умолчанию — 90 секунд. Не рекомендуется устанавливать значение менее 60 секунд. |
Примечание.
Определение JSON — это шаблон, который служба Azure Backup может изменить в соответствии с конкретной базой данных. Чтобы проанализировать файл конфигурации для определенной базы данных, обратитесь к руководству по этой базе данных.
Общая процедура использования улучшенной платформы скриптов предварительной и последующей обработки описана ниже.
- Подготовка среды базы данных
- Изменение файла конфигурации
- Запуск резервного копирования виртуальной машины
- Восстановление виртуальных машин или дисков/файлов из точки восстановления, отвечающей требованиям приложений (при необходимости).
Создание стратегии резервного копирования базы данных
Использование моментальных снимков вместо потоковой передачи
Как правило, потоковая передача резервных копий (например, полных, разностных или добавочных) и журналов используется администраторами баз данных в своих стратегиях резервного копирования. Ниже описаны некоторые основные моменты, связанные с архитектурой.
- Производительность и затраты: ежедневное полное создавание резервной копии и копирование журналов обеспечит наиболее быстрое восстановление, но приведет к значительным затратам. Включение потокового резервного копирования с разностным/добавочным методом позволит снизить стоимость, но может отрицательно сказаться на производительности восстановления. Однако наилучшее сочетание производительности и затрат обеспечивают моментальные снимки. Так как моментальные снимки по существу являются добавочными, они оказывают наименьшее влияние на производительность во время резервного копирования, быстро восстанавливаются и позволяют сократить затраты.
- Влияние на базу данных и инфраструктуру: производительность потокового резервного копирования зависит от IOPS (операций ввода-вывода в секунду) базового хранилища и доступной пропускной способности сети, когда резервная копия направляется в удаленное место. У моментальных снимков нет этой зависимости, и значительно снижается потребность в числе операций ввода-вывода в секунду и пропускной способности сети.
- Повторное использование: команды для запуска различных типов потоковой передачи резервных копий отличаются для каждой базы данных. Поэтому скрипты нельзя легко использовать повторно. Кроме того, если вы используете разные типы резервных копий, обязательно оцените цепочку зависимостей, чтобы сохранить жизненный цикл. Для моментальных снимков можно легко написать скрипты, так как в них нет цепочки зависимостей.
- Долгосрочное хранение: полные резервные копии всегда удобны для долгосрочного хранения, так как их можно перемещать и восстанавливать независимо друг от друга. Но для оперативного резервного копирования с кратковременным хранением более предпочтительны моментальные снимки.
Поэтому ежедневные моментальные снимки и журналы с периодическим полным резервным копированием для долгосрочного хранения являются оптимальной политикой резервного копирования для баз данных.
Стратегия резервного копирования журналов
В основе улучшенной платформы скриптов предварительной и последующей обработки лежит запланированное резервное копирование виртуальных машин Azure один раз в день. Таким образом, окно потери данных с целевой точкой восстановления (RPO), равное 24 часам, не подходит для продуктивных баз данных. Это решение дополняется стратегией резервного копирования журналов, где резервные копии журналов транслируются непосредственно.
NFS для BLOB-объектов и NFS для AFS (предварительная версия) помогают легко монтировать тома напрямую на виртуальные машины базы данных и использовать клиентов базы данных для передачи резервных копий логов. Окно потери данных, которое означает RPO, соответствует частоте резервного копирования журналов. Кроме того, целевые хранилища NFS не обязательно должны быть высокопроизводительными, так как после создания согласованных моментальных снимков базы данных вам может не понадобиться запускать регулярную потоковую передачу (полную и инкрементную) для оперативных резервных копий.
Примечание.
Улучшенный скрипт предварительной обработки обычно очищает все транзакции журналов, передаваемые в место назначения резервных копий журналов, перед заморозкой базы данных для создания моментального снимка. Поэтому моментальные снимки являются согласованными с базой данных и надежными во время восстановления.
Стратегия восстановления
После создания согласованных моментальных снимков базы данных и передачи резервных копий журналов в томе NFS стратегия восстановления базы данных может использовать функции восстановления резервных копий виртуальных машин Azure. Дополнительно применяется возможность резервного копирования журналов с помощью клиента базы данных. Ниже описаны несколько вариантов стратегии восстановления:
- Создавайте новые виртуальные машины из точки восстановления с согласованной базой данных. На виртуальной машине уже должна быть подключена точка монтирования журнала. Используйте клиенты баз данных, чтобы запускать команды восстановления до точки во времени.
- Создавайте диски из точки восстановления с согласованием базы данных и подключайте их к другой целевой виртуальной машине. Затем подключайте место назначения журналов и используйте клиентов базы данных для запуска команд восстановления до определенного момента времени.
- Используйте параметр восстановления файлов и создайте скрипт. Запустите скрипт на целевой виртуальной машине и подключите точку восстановления как диски iSCSI. Затем проверьте данные резервного копирования с помощью клиентов баз данных, запуская функции проверки для конкретной базы данных на подключенных дисках. Также используйте клиенты базы данных для экспорта или восстановления нескольких таблиц или файлов вместо восстановления всей базы данных.
- Используйте функцию межрегионального восстановления для выполнения указанных выше действий из вторичного связанного региона в случае регионального сбоя.
Итоги
Используя согласованные моментальные снимки базы данных и журналы, копируемые с помощью настраиваемого решения, вы сможете создать производительное и экономичное решение для резервного копирования баз данных. Это решение позволит вам воспользоваться преимуществами резервного копирования виртуальных машин Azure и повторно использовать возможности клиентов баз данных.