Расширенные скрипты prepost для согласованного моментального снимка базы данных
Служба Архивации 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 =
В следующей таблице описаны параметры.
| Параметр | Обязательно | Описание |
|---|---|---|
| workload_name | Да | Этот параметр будет содержать имя базы данных, для которой необходимо получить моментальный снимок с согласованием приложений. Текущие поддерживаемые значения: oracle и mysql. |
| command_path/configuration_path | Этот параметр будет содержать путь к бинарному файлу рабочей нагрузки. Это не обязательное поле, если двоичный файл рабочей нагрузки задан как переменная пути. | |
| linux_user | Да | Этот параметр будет содержать имя пользователя Linux, у которого есть доступ на вход в базу данных. Если это значение не за установлено, то пользователем по умолчанию является root. |
| credString | Это строка учетных данных для подключения к базе данных. Она будет содержать всю строку входа. | |
| ipc_folder | Рабочая нагрузка может записывать данные только в определенных путях в файловой системе. Необходимо указать здесь соответствующий путь к папке, чтобы скрипт предварительной обработки мог записывать состояния по этому пути. | |
| timeout | Да | Это максимальное время, в течение которого база данных будет находиться в состоянии заморозки. Значение по умолчанию — 90 секунд. Не рекомендуется устанавливать значение менее 60 секунд. |
Примечание.
Определение JSON — это шаблон, который служба Azure Backup может изменить в соответствии с конкретной базой данных. Чтобы проанализировать файл конфигурации для определенной базы данных, обратитесь к руководству по этой базе данных.
Общая процедура использования улучшенной платформы скриптов предварительной и последующей обработки описана ниже.
- Подготовка среды базы данных
- Изменение файла конфигурации
- Запуск резервного копирования виртуальной машины
- Восстановление виртуальных машин или дисков/файлов из точки восстановления с согласованием приложений (при необходимости).
Создание стратегии резервного копирования базы данных
Использование моментальных снимков вместо потоковой передачи
Как правило, потоковая передача резервных копий (например, полных, разностных или добавочных) и журналов используется администраторами баз данных в своих стратегиях резервного копирования. Ниже описаны некоторые основные моменты, связанные с архитектурой.
- Производительность и затраты: ежедневное полное резервное копирование и резервное копирование журналов обеспечит самое быстрое восстановление, но приведет к значительным затратам. Включение потоковой передачи разностных/добавочных резервных копий позволит снизить стоимость, но может отрицательно сказаться на производительности восстановления. Однако наилучшее сочетание производительности и затрат обеспечивают моментальные снимки. Так как моментальные снимки по существу являются добавочными, они оказывают наименьшее влияние на производительность во время резервного копирования, быстро восстанавливаются и позволяют сократить затраты.
- Влияние на базу данных и инфраструктуру: производительность потоковой передачи резервных копий зависит от числа операций ввода-вывода в секунду базового хранилища и доступной пропускной способности сети при передаче резервных копий в удаленное расположение. У моментальных снимков нет такой зависимости, и потребность в числе операций ввода-вывода в секунду и пропускной способности сети значительно снижается.
- Повторное использование: команды для запуска различных типов потоковой передачи резервных копий отличаются для каждой базы данных. Поэтому скрипты нельзя легко использовать повторно. Кроме того, если вы используете разные типы резервных копий, обязательно оцените цепочку зависимостей, чтобы сохранить жизненный цикл. Для моментальных снимков можно легко написать скрипты, так как в них нет цепочки зависимостей.
- Долгосрочное хранение: полные резервные копии всегда удобны для долгосрочного хранения, так как их можно перемещать и восстанавливать независимо друг от друга. Но для оперативного резервного копирования с кратковременным хранением более предпочтительны моментальные снимки.
Поэтому ежедневные моментальные снимки и резервное копирование журналов с периодическим полным резервным копированием для долгосрочного хранения являются оптимальной политикой резервного копирования для баз данных.
Стратегия резервного копирования журналов
В основе улучшенной платформы скриптов предварительной и последующей обработки лежит запланированное резервное копирование виртуальных машин Azure один раз в день. Таким образом, окно потери данных с целевой точкой восстановления (RPO), так как 24 часа не подходит для рабочих баз данных. Это решение дополняется стратегией резервного копирования журналов, при которой резервные копии журналов передаются явным образом.
NFS для BLOB-объектов и NFS для AFS (предварительная версия) помогают легко подключать тома напрямую к виртуальным машинам базы данных и использовать клиентов базы данных для передачи резервных копий журналов. Окно потери данных, которое является RPO, переходит к частоте резервного копирования журналов. Кроме того, целевые ресурсы NFS не должны иметь высокую производительность, так как после создания моментальных снимков с согласованием базы данных вам может не понадобиться запускать обычную потоковую передачу (полную и добавочную) для оперативных резервных копий.
Примечание.
Улучшенный скрипт предварительной обработки обычно очищает все транзакции журналов, передаваемые в место назначения резервных копий журналов, перед заморозкой базы данных для создания моментального снимка. Поэтому моментальные снимки являются согласованными с базой данных и надежными во время восстановления.
Стратегия восстановления
После создания моментальных снимков с согласованием базы данных и потоковой передачи резервных копий журналов в том NFS стратегия восстановления базы данных может использовать функции восстановления резервных копий виртуальных машин Azure. Дополнительно применяется возможность резервного копирования журналов с помощью клиента базы данных. Ниже описаны несколько вариантов стратегии восстановления:
- Создавайте новые виртуальные машины из точки восстановления с согласованием базы данных. На виртуальной машине уже должна быть подключена точка подключения журнала. Используйте клиенты баз данных, чтобы запускать команды восстановления до точки во времени.
- Создавайте диски из точки восстановления с согласованием базы данных и подключайте их к другой целевой виртуальной машине. Затем подключайте каталог назначения журнала и используйте клиентов базы данных для запуска команд восстановления до точки во времени.
- Используйте параметр восстановления файлов и создайте скрипт. Запустите скрипт на целевой виртуальной машине и подключите точку восстановления как диски iSCSI. Затем проверьте данные резервного копирования с помощью клиентов баз данных, запуская функции проверки для конкретной базы данных на подключенных дисках. Также используйте клиенты базы данных для экспорта или восстановления нескольких таблиц или файлов вместо восстановления всей базы данных.
- Используйте функцию восстановления между регионами для выполнения указанных выше действий из дополнительного связанного региона во время регионального аварийного восстановления.
Итоги
Используя моментальные снимки с согласованием базы данных и журналы, копируемые с помощью настраиваемого решения, вы сможете создать эффективное и доступное решение для резервного копирования баз данных. В рамках этого решения вы будете использовать преимущества резервного копирования виртуальных машин Azure, а также повторно использовать возможности клиентов баз данных.