Перенос приложений

  • 6 мин

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

Исходный локальный сервер и база данных будут содержать роли, определяющие привилегии, связанные с пользователями, операции, которые они могут выполнять, и объекты, которые они выполняют. База данных Azure для MySQL использует те же механизмы проверки подлинности и авторизации, что и PostgreSQL, запущенные локально.

В этом уроке вы изучите обновления, необходимые для подключения приложений к недавно перенесенной базе данных Azure для MySQL.

Создание пользователей вручную

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

При передаче базы данных MySQL в Базу данных Azure для MySQL с помощью Azure Database Migration Service пользователи не копируются. Необходимо вручную создать необходимые учетные записи пользователей для администраторов и пользователей таблиц в целевой базе данных. Для выполнения этих задач вы используете язык SQL или служебную программу, например MySQL Workbench. Выполните команду CREATE USER. Вы используете команду GRANT, чтобы назначить пользователю необходимые привилегии. Рассмотрим пример.

CREATE USER 'myuseraccount'@'%' IDENTIFIED BY 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE [Database Name].* TO myuseraccount;
FLUSH PRIVILEGES;

Чтобы просмотреть существующие гранты в локальной базе данных, выполните следующую инструкцию SQL:

USE [Database Name];

SHOW GRANTS FOR 'myuseraccount'@'%';;

Перенастройка приложений

Перенастройка приложения для подключения к Базе данных Azure для MySQL является простым процессом. Однако важно разработать стратегию миграции приложений.

Рекомендации по перенастройки приложений MySQL

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

При переносе базы данных MySQL в Azure следует учитывать некоторые особенности.

  • Если вы выполняете автономную миграцию, данные в исходной базе данных MySQL и новые базы данных, запущенные в Azure, могут быстро отличаться, если старая база данных по-прежнему используется. Автономная миграция подходит при переходе системы полностью из эксплуатации в течение короткого времени, а затем переключение всех приложений на новую систему перед запуском снова. Такой подход может оказаться невозможным для критически важной для бизнеса системы. При миграции на MySQL на виртуальной машине Azure можно настроить репликацию MySQL между локальной системой и запущенной в Azure. Репликация Native MySQL работает только в одном направлении, но сторонние решения доступны, поддерживающие двунаправленную репликацию между серверами MySQL. Эти решения не будут работать с Базой данных Azure для MySQL.
  • Если вы выполняете миграцию через Интернет, служба Базы данных Azure для MySQL настраивает репликацию из локальной базы данных в базу данных, запущенную в Azure. После первоначальной передачи данных репликация гарантирует, что все изменения, внесенные в локальную базу данных, копируются в базу данных в Azure, но не наоборот.

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

  • Перенос приложений на основе типа рабочей нагрузки. Приложение, которое обращается к данным только для чтения, может безопасно перемещаться в базу данных, запущенную в Базе данных Azure для MySQL, и увидит все изменения, внесенные приложениями, по-прежнему с помощью локальной базы данных. Вы также можете применить стратегию обратного взаимодействия, если приложения только для чтения не требуют полностью up-to-data.
  • Перенос пользователей на основе типа рабочей нагрузки. Эта стратегия аналогична предыдущей, за исключением того, что у вас могут быть пользователи, которые только создают отчеты, а другие изменяют данные. Вы можете иметь то же приложение, настроенное для подключения к соответствующей базе данных в соответствии с требованиями пользователя.
  • Перенос приложений на основе используемых наборов данных. Если разные приложения используют разные подмножества данных, вы можете перенести эти приложения независимо друг от друга.

Перенастройка приложения

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

Сведения о подключении для службы Базы данных Azure для MySQL можно найти на портале Azure на странице строки подключения для службы Базы данных Azure для MySQL. Azure предоставляет сведения для многих распространенных языков программирования и платформ.

изображение со страницей

Открытие сетевых портов

Как упоминалось на занятии 1 этого модуля, База данных Azure для MySQL — это защищенная служба, которая выполняется за брандмауэром. Клиенты не могут подключаться, если его IP-адрес не распознается службой. Необходимо добавить IP-адреса или диапазоны блоков адресов для клиентов под управлением приложений, которые должны подключаться к базам данных.

Тестирование и проверка приложений

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

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

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

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