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

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

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

В этом руководстве вы узнаете, как:

Предварительные требования

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

• Создайте или используйте существующий экземпляр MySQL (исходный сервер).

• Чтобы успешно выполнить миграцию по сети, убедитесь, что выполнены следующие предварительные требования:

  • Используйте средство командной строки MySQL, чтобы убедиться, что log_bin включен на исходном сервере, выполнив команду: SHOW VARIABLES LIKE 'log_bin' Если log_bin не включен, обязательно включите его перед началом миграции.

  • Убедитесь, что у пользователя есть REPLICATION CLIENT и REPLICATION REPLICA разрешения на исходном сервере для чтения и применения журнала bin.

  • Если вы нацелены на миграцию через Интернет, необходимо настроить срок действия binlog на исходном сервере, чтобы убедиться, что файлы binlog не очищаются, прежде чем реплика фиксирует изменения. Мы рекомендуем отвести на начало как минимум два дня. Параметр зависит от версии сервера MySQL. Для MySQL 5.7 параметр имеет значение expire_logs_days (по умолчанию он имеет значение 0, что не является автоматической очисткой). Для MySQL 8.0 он имеет значение binlog_expire_logs_seconds (по умолчанию он имеет значение 30 дней). После успешного переключения можно сбросить его значение.

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

  • Привилегия SELECT на уровне сервера источника.

  • При переносе представлений пользователь должен иметь права SHOW VIEW на исходном сервере и привилегию CREATE VIEW на целевом сервере.

  • При переносе триггеров пользователь должен иметь привилегию TRIGGER на исходном и целевом сервере.

  • При переносе подпрограмм (процедур и/или функций) пользователь должен иметь права CREATE ROUTINE и ALTER ROUTINE , предоставленные на уровне сервера на целевом уровне.

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

  • При переносе пользователей и имен входа пользователь должен иметь права CREATE USER на целевом сервере.

  • Привилегии DROP на уровне сервера на целевом объекте, чтобы удалить таблицы, которые уже могут существовать. Например, при повторной попытке миграции.

  • Привилегии REFERENCES на уровне сервера на целевом объекте для создания таблиц с внешними ключами.

  • При миграции на MySQL 8.0 пользователь должен иметь права SESSION_VARIABLES_ADMIN на целевом сервере.

  • СОЗДАНИЕ привилегий на уровне сервера на целевом объекте.

  • Привилегии INSERT на уровне сервера на целевом объекте.

  • Привилегии UPDATE на уровне сервера на целевом объекте.

  • Права DELETE на уровне сервера на целевом объекте.

Ограничения

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

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

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

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

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

• Поддержка миграции по сети ограничена форматом ROW binlog.

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

• Теперь миграция по сети поддерживает репликацию инструкции DDL при миграции на целевой гибкий сервер "База данных Azure для MySQL" версий 8.0 или 5.7.

  • Репликация инструкций поддерживается для баз данных, таблиц и объектов схемы (представлений, подпрограмм, триггеров), выбранных для миграции схемы при настройке миграции Azure DMS. Инструкции определения и администрирования данных для баз данных, таблиц и объектов схемы, которые не выбраны, не реплицируются. Выбор всего сервера для миграции реплицирует инструкции для всех таблиц, баз данных и объектов схемы, созданных на исходном сервере после завершения начальной загрузки.

  • Репликация инструкций Azure DMS поддерживает все инструкции определения данных, за исключением следующих команд:

    • Инструкции LOGFILE GROUP
    • Инструкции SERVER
    • Операторы системы пространственных координат
    • Инструкции TABLESPACE

  • Репликация инструкций Azure DMS поддерживает все инструкции администрирования данных — управление учетными записями, за исключением следующих команд:

    • УСТАНОВИТЬ РОЛЬ ПО УМОЛЧАНИЮ
    • УСТАНОВИТЕ ПАРОЛЬ

  • Репликация инструкций Azure DMS поддерживает все инструкции администрирования данных — обслуживания таблиц, за исключением следующих команд:

    • ИСПРАВЛЕНИЕ ТАБЛИЦЫ
    • АНАЛИЗ ТАБЛИЦЫ
    • ТАБЛИЦА КОНТРОЛЬНЫХ СУММ

  • Инструкция Azure DMS или репликация binlog не поддерживают следующий синтаксис: CREATE TABLE 'b' as SELECT * FROM 'a'; Репликация этого DDL приводит к следующей ошибке: "Только инструкции BINLOG INSERT, COMMIT и ROLLBACK разрешены после инструкции CREATE TABLE с инструкцией START TRANSACTION".

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

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

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

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

  ¹ Для ускорения миграции рекомендуется выбрать вычислительные ресурсы общего назначения 16 виртуальных ядер или больше для целевого гибкого сервера. Выполните горизонтальное масштабирование до требуемого размера вычислительных ресурсов целевого сервера после завершения миграции.

• Версия MySQL для целевого гибкого сервера должна быть больше или равна исходному серверу MySQL.

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

• Для сетевого подключения на вкладке "Сеть" выберите закрытый доступ; В противном случае выберите "Общедоступный доступ" настройте правила брандмауэра, чтобы разрешить доступ к целевому гибкому серверу.

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

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

• Создайте целевой гибкий сервер. Пошаговые инструкции см. в кратком руководстве Краткое руководство. Создание экземпляра База данных Azure для MySQL на портале Azure.

• Настройте новый гибкий целевой сервер следующим образом:

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

    • Убедитесь, что у пользователя есть REPLICATION_APPLIER или BINLOG_ADMIN разрешение на целевом сервере для применения журнала bin.

    • Убедитесь, что у пользователя есть REPLICATION REPLICA разрешение на целевой сервер.

    • Убедитесь, что у пользователя есть REPLICATION CLIENT и REPLICATION REPLICA разрешения на исходном сервере для чтения и применения журнала bin.

    • Чтобы создать таблицы в целевом объекте, пользователь должен иметь привилегию CREATE .

    • При переносе таблицы с DATA DIRECTORYINDEX DIRECTORY параметрами секции пользователь должен иметь FILE права.

    • При миграции в таблицу с параметром UNION пользователь должен иметь права SELECT, UPDATE и привилегии DELETE для таблиц, которые сопоставляются с таблицей MERGE.

    • При переносе представлений необходимо иметь привилегию CREATE VIEW .

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

    • При переносе событий пользователь должен иметь привилегию EVENT .
    • При переносе триггеров пользователь должен иметь привилегию TRIGGER .
    • При переносе подпрограмм пользователь должен иметь привилегии CREATE ROUTINE .

  • Настройте параметры сервера на целевом гибком сервере следующим образом:

    • Задайте версию TLS и параметр сервера require_secure_transport, чтобы соответствовать значениям на исходном сервере.

    • Задайте параметр сервера sql_mode для сопоставления значений на исходном сервере.

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

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

      • max_allowed_packet — установите значение 1073741824 (т. е. 1 ГБ), чтобы предотвратить проблемы с подключением из-за больших строк.

      • slow_query_log — установите значение OFF для отключения журнала медленных запросов. Это устраняет издержки, вызванные медленным ведением журнала запросов во время загрузки данных.

      • innodb_buffer_pool_size — можно увеличить только масштабированием вычислений для сервера База данных Azure для MySQL. Увеличьте размер SKU общего назначения виртуальных ядер на сервере до 64 виртуальных ядер с ценовой категории портала во время миграции, чтобы увеличить размер innodb_buffer_pool_size.

      • innodb_io_capacity и innodb_io_capacity_max — измените параметры сервера на портале Azure, установив значение 9000, чтобы улучшить эффективность использования операций ввода-вывода и оптимизировать скорость миграции.

      • innodb_write_io_threads — Измените значение на 4 в параметрах сервера на портале Azure, чтобы повысить скорость миграции.

  • Настройте реплики на целевом сервере для сопоставления реплик на исходном сервере.

Настройка DMS

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

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

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

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

   

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

   

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

   

Создайте экземпляр службы миграции баз данных (DMS)

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

   

2. На экране Azure Database Migration Service выберите Создать.

   

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

   

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

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

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

   

7. На странице "Настройка" выберите ценовую категорию "Премиум" с 4 виртуальными ядрами для экземпляра DMS и нажмите кнопку "Применить".

   DMS Premium 4-vCore предоставляется бесплатно в течение шести месяцев (183 дней) с даты создания службы DMS, после чего начинают применяться платежи. Дополнительные сведения о затратах и ценовых категориях DMS см. на странице цен.

   

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

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

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

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

   

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

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

   Примечание.

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

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

    

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

11. Выберите Перейти к ресурсу.

    

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

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

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

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

   

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

   

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

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

   

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

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

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

   

2. Нажмите кнопку "Далее": выберите целевой >>объект, а затем на экране "Выбор целевого" найдите сервер на основе подписки, расположения и группы ресурсов. Имя пользователя заполняется автоматически, а затем укажите пароль для целевого гибкого сервера.

   

3. Нажмите кнопку "Далее": выберите базы данных >>, а затем на вкладке "Выбор баз данных " в разделе "Параметры миграции сервера" выберите " Перенести все применимые базы данных " или в разделе "Выбор баз данных " выберите объекты сервера, которые требуется перенести.

   Теперь есть параметр "Миграция всех применимых баз данных". При выборе этот параметр переносит все созданные пользователем базы данных и таблицы. Так как гибкий сервер Azure Database для MySQL не поддерживает базы данных смешанного регистра, базы данных смешанного регистра в источнике данных не включаются для онлайн миграции.

   

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

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

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

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

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

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

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

   

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

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

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

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

   

9. Выберите Начать миграцию.

   Появится окно действия миграции и в поле Состояние будет указано Инициализация. Состояние изменяется на Running, когда начинается миграция таблиц.

   

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

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

   

   После завершения действия Начальная загрузка вы автоматически перейдете на вкладку Репликация изменений данных. Ход миграции можно отслеживать при автоматическом обновлении экрана каждые 30 секунд.

2. При необходимости выберите "Обновить" , чтобы обновить отображение и просмотреть секунды за источником.

   

3. Отслеживайте количество секунд отставания от источника и, как только значение приблизится к 0, перейдите на вкладку меню Начать переключение в верхней части экрана хода миграции.

4. Следуйте инструкциям в окне переключения, прежде чем вы будете готовы выполнить переключение.

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

   

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

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

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

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

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

  • Чтобы осуществить очистку ресурсов DMS выполните следующие действия:

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

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

    3. В диалоговом окне подтверждения в текстовом поле ВВЕДИТЕ ИМЯ СЛУЖБЫ МИГРАЦИИ БАЗ ДАННЫХ укажите имя экземпляра, а затем выберите Удалить.

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

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

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

• Выполните тестовые миграции перед миграцией в рабочую среду:

  • Тестовые миграции важны для обеспечения охвата всех аспектов миграции базы данных, включая тестирование приложений. Рекомендуется начать с миграции исключительно для тестирования. После того как недавно запущенная миграция переходит в фазу «Репликация изменений данных» с минимальной задержкой, используйте целевой сервер Flexible Server только для выполнения тестовых нагрузок. Используйте этот целевой сервер для тестирования приложения, чтобы обеспечить ожидаемую производительность и результаты. Если вы выполняете миграцию на более высокую версию MySQL, проверьте совместимость своего приложения.

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

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

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

Связанный контент

• Что такое База данных Azure для MySQL — гибкий сервер?
• Что такое служба Azure Database Migration Service?
• Известные проблемы с миграцией в База данных Azure для MySQL
• Устранение распространенных проблем и ошибок Azure Database Migration Service (классическая версия)
• Troubleshoot DMS errors when connecting to source databases (Устранение ошибок DMS при подключении к базам данных-источникам)