Перенос локальной базы данных MySQL в Базу данных Azure для MySQL: непрерывность бизнес-процессов и аварийное восстановление (BCDR)
Обеспечение непрерывности бизнес-процессов и аварийного восстановления (BCDR) крайне важно для переноса баз данных MySQL из локальных сред в База данных Azure для MySQL. В этой статье рассматриваются стратегии и рекомендации по поддержанию непрерывных операций и защите данных во время и после миграции. С помощью надежных возможностей BCDR Azure можно свести к минимуму время простоя, защититься от потери данных и обеспечить быстрое восстановление во время аварии. В этом руководстве содержатся аналитические сведения, необходимые для разработки комплексного плана BCDR, решения потенциальных рисков и использования расширенных функций Azure для повышения устойчивости и надежности. Независимо от того, стремитесь ли вы улучшить возможности аварийного восстановления или обеспечить непрерывную доступность, эта статья предоставляет вам знания для обеспечения простой и безопасной миграции.
Необходимые компоненты
Перенос локальной среды MySQL в База данных Azure для MySQL: оптимизация
Резервное копирование и восстановление
Для любой критически важной системы стратегия резервного копирования, восстановления и аварийного восстановления является важнейшей составляющей архитектуры всей системы. На случай непредвиденных обстоятельств нужно обеспечить возможность восстанавливать данные по состоянию на определенный момент времени (целевая точка восстановления) за приемлемый период времени (целевое время восстановления).
Резервное копирование
База данных Azure для MySQL поддерживает автоматическое резервное копирование в течение семи дней по умолчанию. Это может быть целесообразно изменить до текущего максимума 35 дней. Важно помнить о том, что при увеличении периода до 35 дней вы будете оплачивать используемое в хранилище резервных копий пространство сверх одного выделенного объема хранилища.
В настоящее время для возможности резервного копирования баз данных существует ряд ограничений, которые описаны в статье документации Резервное копирование и восстановление в службе "База данных Azure для MySQL". Их следует изучить и учитывать при выборе любых дополнительных стратегий.
Вот несколько важных аспектов, которые нужно знать:
к резервным копиям нет прямого доступа;
уровни служб, поддерживающие до 4 ТБ хранилища, создают полную резервную копию один раз в неделю, дифференциальную копию дважды в день и сохраняют журналы каждые пять минут;
уровни служб, поддерживающие до 16 ТБ хранилища, используют резервные копии на основе моментальных снимков.
Примечание.
В некоторых регионах пока не поддерживаются хранилища объемом 16 ТБ.
Восстановление
При создании сервера необходимо выбрать локальный или региональный уровень избыточности. Впрочем, поддерживается восстановление в другой регион, что позволяет внести изменения в выбранный вариант уже в процессе восстановления. Выполнение операции восстановления может ненадолго сделать возможность подключения недоступной и приостановить работу всех приложений.
В процессе восстановления базы данных необходимо отдельно восстановить все ее дополнительные компоненты.
Следите за ходом процесса миграции. Дополнительные сведения см. в разделе Задачи после восстановления.
Реплики чтения
Реплики чтения позволяют повысить пропускную способность для операций чтения в базах данных MySQL, ускорить работу пользователей в разных регионах и реализовать аварийное восстановление. При создании одной или нескольких реплик чтения не забывайте о том, что за их ресурсы вычисления и хранилища взимается дополнительная оплата в том же объеме, что и за главный сервер.
Удаленные серверы
Когда администратор или злоумышленник удаляет сервер через портал Azure или с применением средств автоматизации, вместе с ним удаляются все резервные копии и реплики чтения. Важно, чтобы блокировки ресурсов создавались в группе ресурсов База данных Azure для MySQL, чтобы добавить дополнительный уровень предотвращения удаления в экземпляры.
Сбой в регионе
Если произойдет региональной сбой (хотя это маловероятно), вы сможете вернуть рабочие нагрузки данных в рабочее состояние с помощью геоизбыточных резервных копий или реплик чтения. Лучше всего использовать георепликацию и реплику чтения для оптимальной защиты от непредвиденных региональных сбоев.
Примечание.
Изменение региона для сервера базы данных влечет за собой изменение его конечной точки, а значит требует внести изменения в конфигурацию приложения.
Подсистемы балансировки нагрузки
Если приложение состоит из множества разных экземпляров по всему миру, это может оказаться невозможным для обновления всех клиентов. Azure Load Balancer и Шлюз приложений помогут вам легко выполнять отработку отказа. Это очень помогает и экономит время при сбоях, но для поддержки региональной отработки отказа эти средства не являются обязательными.
Сценарий WWI
Компания WWI решила протестировать возможности отработки отказа с использованием реплик чтения, и для этой цели выполнила описанные ниже шаги.
Создание реплики чтения
Откройте портал Azure.
Перейдите к экземпляру Базы данных Azure MySQL.
В разделе Параметры выберите Репликация.
Выберите Добавить реплику.
Введите имя сервера.
Выберите регион.
Щелкните ОК и дождитесь завершения развертывания экземпляра. В зависимости от размера главного экземпляра репликация может занять некоторое время.
Примечание.
Каждая дополнительная реплика оплачивается в том же объеме, что и главный экземпляр.
Отработка отказа на реплику чтения
После создания реплики чтения, когда завершится процесс репликации, она будет готова к отработке отказа. На период отработки отказа прекращается процесс репликации, а реплика чтения становится новым главным экземпляром.
Процесс отработки отказа
Откройте портал Azure.
Перейдите к экземпляру Базы данных Azure MySQL.
В разделе Параметры выберите Репликация.
Выберите одну из реплик чтения.
Щелкните Остановить репликацию. Эта операция отключает создание реплик чтения.
Внесите изменения в строки подключения всех приложений, чтобы они указывали на новый главный экземпляр.
Контрольный список для BCDR
Измените частоту резервного копирования в соответствии с вашими требованиями.
Настройте реплики чтения для всех рабочих нагрузок с высокой интенсивностью операций чтения и для поддержки региональной отработки отказа.
Создайте блокировки ресурсов для групп ресурсов.
Внедрите стратегию балансировки нагрузки для быстрой отработки отказа в приложениях.