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

Можно выполнить миграцию экземпляра Базы данных Azure для MySQL в режиме "Отдельный сервер на Базу данных Azure для MySQL и гибкий сервер" с помощью Azure Database Migration Service (DMS), полностью управляемой службы, предназначенной для обеспечения простой миграции из нескольких источников баз данных на платформы данных Azure. В этом руководстве мы будем выполнять автономную миграцию примера базы данных с одного сервера База данных Azure для MySQL на гибкий сервер MySQL (как под управлением версии 5.7), так и с помощью действия миграции DMS.

Примечание.

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

Внимание

Для миграции через Интернет можно использовать функцию включения согласованности транзакций, поддерживаемую DMS, вместе с изменениями в реплика данных или реплика te. Кроме того, вы можете использовать сценарий миграции по сети для миграции, следуя инструкциям в этом руководстве.

Из этого руководства вы узнаете, как выполнять следующие задачи:

  • Реализуйте рекомендации по созданию гибкого сервера для ускорения загрузки данных с помощью DMS.
  • Создание и настройка целевого гибкого сервера.
  • Создайте экземпляр DMS.
  • Создайте проект миграции MySQL в DMS.
  • Перенос схемы MySQL с помощью DMS.
  • выполнение миграции.
  • Мониторинг миграции.
  • Выполните шаги после миграции.
  • Реализуйте рекомендации по выполнению миграции.

Необходимые компоненты

Для работы с этим руководством вам потребуется следующее:

  • Создайте или используйте существующий экземпляр База данных Azure для MySQL — отдельный сервер (исходный сервер).
  • Для успешной миграции схемы на исходном сервере пользователь, выполняющий миграцию, требует следующих привилегий:

Ограничения

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

  • Во время миграции объектов, отличных от табличных, DMS не поддерживает переименование баз данных.
  • При миграции на целевой сервер с включенным bin_log обязательно включите log_bin_trust_function_creators, чтобы разрешить создание подпрограмм и триггеров.
  • Во время миграции схемы DMS не поддерживает создание базы данных на целевом сервере.
  • Сейчас DMS не поддерживает миграцию предложения DEFINER для объектов. Все типы объектов с определителями в источнике будут удалены, и после переноса для определителя по умолчанию для таблиц будет задано имя входа, используемое для выполнения миграции.
  • Сейчас DMS поддерживает миграцию схемы только в рамках перемещения данных. Если для перемещения данных ничего не выбрано, миграция схемы не выполняется. Обратите внимание, что при выборе таблицы для миграции схемы она также выбирается для перемещения данных.

Рекомендации по созданию гибкого сервера для ускорения загрузки данных с использованием DMS

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

  • Выберите объем и уровень вычислительных ресурсов для целевого гибкого сервера с учетом ценовой категории исходного отдельного сервера и виртуальных ядер на основе данных в следующей таблице.

    Отдельный сервер: ценовая Отдельный сервер: виртуальные ядра Гибкий сервер: объем вычислительных ресурсов Гибкий сервер: уровень вычислительных ресурсов
    Базовый* 1 Общего назначения Standard_D16ds_v4
    Базовый* 2 Общего назначения Standard_D16ds_v4
    Общего назначения* 4 Общего назначения Standard_D16ds_v4
    Общего назначения* 8 Общего назначения Standard_D16ds_v4
    Общее назначение 16 Общего назначения Standard_D16ds_v4
    Общее назначение 32 Общего назначения Standard_D32ds_v4
    Общее назначение 64 Общего назначения Standard_D64ds_v4
    С оптимизацией для операций в памяти 4 Критически важный для бизнеса Standard_E4ds_v4
    С оптимизацией для операций в памяти 8 Критически важный для бизнеса Standard_E8ds_v4
    С оптимизацией для операций в памяти 16 Критически важный для бизнеса Standard_E16ds_v4
    С оптимизацией для операций в памяти 32 Критически важный для бизнеса Standard_E32ds_v4

* Для миграции выберите вычислительные ресурсы общего назначения 16 виртуальных ядер для целевого гибкого сервера для ускорения миграции. Вернитесь к желаемому объему вычислительных ресурсов для целевого сервера после завершения миграции, следуя рекомендациям в разделе "Выполнение действий после миграции" далее в этой статье.

  • Версия MySQL для целевого гибкого сервера должна быть больше или равна версии исходного отдельного сервера.
  • Если вам не нужно развертывать целевой гибкий сервер в определенной зоне, задайте для параметра Зона доступности значение "Без предпочтений".
  • Если для сетевого подключения на вкладке Сеть на исходном отдельном сервере настроены частные конечные точки или приватные каналы, выберите Частный доступ. В противном случае выберите Общедоступный доступ.
  • Скопируйте все правила брандмауэра с исходного отдельного сервера на целевой гибкий сервер.
  • Скопируйте все теги имени и значения с отдельного сервера на гибкий сервер во время создания.

Создание и настройка целевого гибкого сервера

Учитывая эти рекомендации, создайте целевой гибкий сервер и настройте его.

  • Создайте целевой гибкий сервер. Инструкции см. в кратком руководстве по созданию гибкого сервера База данных Azure для MySQL.
  • Рядом с настройкой только что созданного целевого гибкого сервера выполните следующие действия:
    • Пользователю, выполняющим миграцию, требуются следующие разрешения:
      • Чтобы создать таблицы в целевом объекте, пользователь должен иметь привилегию CREATE.
      • При миграции в таблицу с параметром UNION пользователь должен иметь привилегии SELECT, UPDATE и DELETE для таблиц, сопоставленных с таблицей MERGE.
      • При переносе представлений необходимо иметь привилегию CREATE VIEW. Помните, что некоторые привилегии могут потребоваться в зависимости от содержимого представлений. Дополнительные сведения см. в документации MySQL, относящиеся к версии инструкции CREATE VIEW.
      • При переносе событий пользователь должен иметь привилегию EVENT.
      • При переносе триггеров пользователь должен иметь привилегию "TRIGGER".
      • При переносе подпрограмм пользователь должен иметь привилегию CREATE ROUTINE.
    • Создайте целевую базу данных, хотя она не должна быть заполнена таблицами и представлениями и т. д.
      • Задайте соответствующий символ, параметры сортировки и любые другие применимые параметры схемы перед началом миграции, так как это может повлиять на набор DEFAULT в некоторых определениях объектов.
      • Кроме того, при переносе объектов, отличных от таблиц, обязательно используйте то же имя для целевой схемы, что и в источнике.
    • Настройте параметры сервера на целевом гибком сервере следующим образом:
      • Задайте версию TLS и параметр сервера require_secure_transport, чтобы соответствовать значениям на исходном сервере.
      • Задайте параметр сервера sql_mode для сопоставления значений на исходном сервере.
      • Настройте параметры сервера на целевом сервере, чтобы соответствовать любым значениям, не используемым по умолчанию на исходном сервере.
      • Чтобы ускорить загрузку данных при использовании DMS, настройте следующие параметры сервера, как описано ниже.
        • max_allowed_packet — установите значение 1073741824 (т. е. 1 ГБ), чтобы предотвратить проблемы с подключением из-за больших строк.
        • slow_query_log — установите значение OFF, чтобы отключить журнал запросов с задержкой. Это позволит избежать накладных расходов, вызванных ведением журнала запросов с задержкой при загрузке данных.
        • innodb_buffer_pool_size — можно увеличить только путем масштабирования вычислений для сервера База данных Azure для MySQL. В разделе "Ценовая категория общего назначения" на портале увеличьте категорию сервера до 64 виртуальных ядер общего назначения на время миграции, чтобы увеличить значение innodb_buffer_pool_size.
        • innodb_io_capacity и innodb_io_capacity_max — измените значение на 9000 в параметрах сервера на портале Azure, чтобы улучшить использование операций ввода-вывода для оптимизации скорости миграции.
        • innodb_write_io_threads. Измените значение на 4 из параметров сервера в портал Azure, чтобы повысить скорость миграции.
    • Настройте реплика на целевом сервере для сопоставления этих реплика на исходном сервере.
    • Реплицируйте следующие функции управления серверами с исходного одного сервера на целевой гибкий сервер:
      • Назначения ролей, роли, запрет назначения, классические администраторы, контроль доступа (IAM)
      • Блокировки (только для чтения и удаления)
      • видны узлы
      • Задачи
      • Оповещения Работоспособность ресурсов

Настройка DMS

После развертывания и настройки целевого гибкого сервера необходимо настроить DMS для переноса одного сервера на гибкий сервер.

Регистрация поставщика ресурсов

Чтобы зарегистрировать поставщика ресурсов Microsoft.DataMigration, выполните следующие действия.

  1. Перед созданием первого экземпляра DMS войдите в портал Azure, а затем найдите и выберите подписки. Снимок экрана: Azure Marketplace.

  2. Выберите подписку, которую вы хотите использовать для создания экземпляра DMS, а затем выберите поставщиков ресурсов. Снимок экрана: поставщик ресурсов Select.

  3. Найдите термин "Миграция", а затем для Microsoft.DataMigration выберите "Зарегистрировать". Снимок экрана: выбор регистрации.

Создание экземпляра Database Migration Service (DMS)

  1. В портал Azure выберите +Создать ресурс, найдите термин "Azure Database Migration Service", а затем выберите Azure Database Migration Service в раскрывающемся списке. Снимок экрана: служба поиска Azure Database Migration Service.

  2. На экране Azure Database Migration Service выберите Создать. Снимок экрана: создание экземпляра Azure Database Migration Service.

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

  4. На странице "Создание службы миграции" на вкладке "Основные сведения" в разделе "Сведения о проекте" выберите соответствующую подписку, а затем выберите существующую группу ресурсов или создайте новую.

  5. В разделе "Сведения об экземпляре" укажите имя службы, выберите регион и убедитесь, что Azure выбран в качестве режима обслуживания.

  6. Справа от ценовой категории выберите "Настройка уровня". Снимок экрана: выбор уровня настройки.

  7. На странице "Настройка" выберите ценовую категорию "Премиум" с 4 виртуальными ядрами для экземпляра DMS и нажмите кнопку "Применить". Служба DMS ценовой категории "Премиум" с четырьмя виртуальными ядрами предоставляется бесплатно (без начисления оплаты) в течение 6 месяцев (183 дня) с момента создания службы. Дополнительные сведения о затратах и ценовых категориях DMS см. на странице цен. Снимок экрана: ценовая категория

    Затем необходимо указать виртуальную сеть, которая предоставит экземпляр DMS с доступом к исходному одному серверу и целевому гибкому серверу.

  8. На странице "Создание службы миграции" нажмите кнопку "Далее: сеть>>".

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

    Дополнительные сведения см. в статье "Создание виртуальной сети с помощью портал Azure". Снимок экрана: выбор сети.

    Внимание

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

    • Создайте правило брандмауэра на уровне сервера или настройте конечные точки службы виртуальной сети для исходных и целевых серверов База данных Azure для MySQL, чтобы разрешить виртуальной сети для Azure Database Migration Service доступ к исходным и целевым базам данных.
    • Убедитесь, что правила группы безопасности сети виртуальной сети (NSG) не блокируют исходящий порт 443 serviceTag для ServiceBus, служба хранилища и Azure Monitor. Дополнительные сведения о фильтрации трафика NSG виртуальной сети см. в разделе "Фильтрация сетевого трафика с группами безопасности сети".

    Примечание.

    Если вы хотите добавить теги в службу, сначала нажмите кнопку "Далее: теги" для перехода на вкладку "Теги". Добавление тегов в службу является необязательным.

  10. Перейдите на вкладку "Просмотр и создание ", просмотрите конфигурации, просмотрите условия и нажмите кнопку "Создать". Снимок экрана: выбор проверки и создания.

    Развертывание экземпляра DMS начинается. Развертывание сообщений выполняется в течение нескольких минут, а затем сообщение об изменении развертывания завершено.

  11. Выберите Перейти к ресурсу. Снимок экрана: ресурс Select Go to resource.

  12. Определите IP-адрес экземпляра DMS на странице обзора ресурсов и создайте правило брандмауэра для исходного отдельного сервера и гибкого сервера, разрешающего перечисление IP-адреса экземпляра DMS.

Создание проекта миграции

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

  1. На портале Azure щелкните Все службы, выполните поиск по запросу "Azure Database Migration Service" и выберите Azure Database Migration Services (Службы Azure Database Migration Service).

    Снимок экрана: поиск всех экземпляров Azure Database Migration Service.

  2. В результатах поиска выберите созданный экземпляр DMS, а затем нажмите кнопку + Создать проект миграции.

    Снимок экрана: CSelect a new migration project.

  3. На странице "Новый проект миграции" укажите имя проекта, в поле выбора типа исходного сервера выберите базу данных Azure для MySQL — отдельный сервер, в поле выбора типа целевого сервера выберите "База данных Azure для MySQL", в поле выбора типа действия миграции выберите "Онлайн", а затем нажмите кнопку "Создать и запустить".

    Примечание.

    При выборе параметра "Создать проект только в качестве типа действия миграции" будет создан только проект миграции; Затем можно запустить проект миграции позже.

    Снимок экрана: создание проекта миграции.

Настройка проекта миграции

Чтобы настроить проект миграции DMS, выполните следующие действия.

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

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

    Примечание.

    Кроме того, если вы выполнили миграцию по сети, на экране выбора источника выберите поле "Включить согласованност проверка ь транзакций". Дополнительные сведения о согласованном резервном копировании см. в разделе "Согласованное резервное копирование MySQL".

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

  3. Нажмите кнопку Далее: выберите целевой>> объект, а затем на экране выбора целевого сервера укажите сведения о подключении для целевого гибкого сервера. Снимок экрана: целевой объект Select.

  4. Нажмите кнопку "Далее". Выберите базы данных>>, а затем на вкладке "Выбор баз данных" в разделе "Выбор объектов сервера" в разделе "Выбор объектов сервера" выберите объекты сервера, которые требуется перенести. Снимок экрана: база данных Select.

  5. В разделе "Выбор баз данных" в разделе "Исходная база данных" выберите базы данных для переноса.

    Указанные объекты, не относящиеся к таблицам, будут перенесены, а элементы, которые вы не выбрали, будут пропущены.

  6. Нажмите кнопку "Далее". Выберите базы данных>> , чтобы перейти на вкладку "Выбор таблиц ".

    Перед заполнением вкладки DMS извлекает таблицы из выбранных баз данных в исходном и целевом объекте, а затем определяет, существует ли таблица и содержит данные.

  7. Выберите таблицы, которые требуется перенести.

    Если выбрать таблицу в исходной базе данных, которая не существует в целевой базе данных, поле в разделе "Миграция схемы " выбрано по умолчанию. Для таблиц, которые существуют в целевой базе данных, обратите внимание, что выбранная таблица уже содержит данные и будет усечена. Кроме того, если схема таблицы на целевом сервере не соответствует схеме источника, таблица будет удалена до продолжения миграции. Снимок экрана: выбор таблиц.

    DMS проверяет входные данные и, если проверка проходит, вы сможете начать миграцию.

  8. После настройки миграции схемы выберите "Проверка и запуск миграции".

    Примечание.

    Если вы пытаетесь устранить сбой миграции, перейдите только на вкладку "Настройка параметров миграции".

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

  10. Выберите Начать миграцию. Появится окно действия миграции и в поле Состояние будет указано Инициализация. Состояние изменится на Выполняется, когда начнется перенос таблиц.

Отслеживайте ход миграции.

  1. На экране действия миграции выберите "Обновить" , чтобы обновить отображение и просмотреть ход выполнения и количество завершенных таблиц.

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

  3. Выберите "Обновить", чтобы обновить отображение до тех пор, пока состояние миграции не отображается как завершено. Снимок экрана: состояние миграции.

Выполните действия после миграции

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

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

  • Обновите строка подключения, чтобы указать на новый целевой гибкий сервер.

  • Удалите исходный отдельный сервер после того, как обеспечите непрерывность приложений.

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

    Отдельный сервер: ценовая Отдельный сервер: виртуальные ядра Гибкий сервер: объем вычислительных ресурсов Гибкий сервер: уровень вычислительных ресурсов
    Основное 1 С увеличивающейся производительностью Standard_B1s
    Основное 2 С увеличивающейся производительностью Standard_B2s
    Общего назначения 4 Общего назначения Standard_D4ds_v4
    Общего назначения 8 Общего назначения Standard_D8ds_v4
  • Очистка ресурсов Службы миграции данных:

    1. На портале Azure щелкните Все службы, выполните поиск по запросу "Azure Database Migration Service" и выберите Azure Database Migration Services (Службы Azure Database Migration Service).
    2. Выберите экземпляр службы миграции из результатов поиска и выберите "Удалить службу".
    3. В диалоговом окне подтверждения в текстовом поле TYPE THE DATABASE MIGRATION SERVICE NAME укажите имя службы и нажмите кнопку "Удалить".

Рекомендации по миграции

При выполнении миграции следует учитывать следующие рекомендации.

  • В рамках обнаружения и оценки используйте SKU сервера, загрузку ЦП, параметры хранилища, размеры баз данных и сведения об использовании расширений в качестве критически важных атрибутов миграции.
  • Спланируйте режим миграции для каждой базы данных. Для менее сложных операций миграции и небольших баз данных можно использовать автономный режим.
  • Выполните тестовые миграции перед миграцией для рабочей среды:
    • Тестовые миграции важны для обеспечения охвата всех аспектов миграции базы данных, включая тестирование приложений. Если вы выполняете миграцию на более высокую версию MySQL, проверьте совместимость своего приложения.
    • После завершения тестирования можно приступать к переносу рабочих баз данных. На этом этапе необходимо окончательно определить дату и время миграции в рабочей среде. В идеале интенсивность использования приложений в этот период должна быть низкой. Все заинтересованные лица, которых требуется привлечь к процессу, должны быть доступны и готовы. Для миграции в рабочей среде потребуется тщательный мониторинг.
  • Перенаправьте все зависимые приложения, чтобы получить доступ к новой базе данных-источнику и открыть приложения для использования в рабочей среде.
  • После запуска приложения на целевом гибком целевом сервере отслеживайте производительность базы данных, чтобы узнать, требуется ли настройка производительности.

Следующие шаги