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

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

В этом руководстве описано следующее:

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

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

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

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

  • Используйте средство командной строки MySQL, чтобы убедиться, что log_bin включен на исходном сервере, выполнив команду: SHOW VARIABLES LIKE "log_bin". Если log_bin не включена, создайте реплику чтения для экземпляра одного сервера и удалите ее. Эта операция установит параметр, log_bin значение ON, и затем можно активировать операцию миграции.
  • Убедитесь, что у пользователя есть разрешения "REPLICATION CLIENT" и "REPLICATION SLAVE" на исходном сервере для чтения и применения журнала bin.
  • Если вы нацелены на миграцию через Интернет, настройте параметр binlog_expire_logs_seconds на исходном сервере, чтобы убедиться, что файлы binlog не очищаются до фиксации реплики изменений. Мы рекомендуем начать по крайней мере два дня. После успешного переключения можно сбросить значение.

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

  • Привилегия SELECT на уровне сервера в источнике.
  • При переносе представлений пользователь должен иметь привилегии SHOW VIEW на исходном сервере и привилегии CREATE VIEW на целевом сервере.
  • При переносе триггеров пользователь должен иметь привилегию "TRIGGER" на исходном и целевом сервере. Кроме того, триггеры переносятся только во время переключений, поэтому вы сможете увидеть, что созданные триггеры успешно завершены.
  • При переносе подпрограмм (процедур и/или функций) пользователь должен иметь привилегии CREATE ROUTINE и ALTER ROUTINE, предоставленные на уровне сервера на целевом объекте.
  • При переносе событий пользователь должен иметь привилегию EVENT на исходном и целевом сервере.
  • При переносе пользователей и имен входа пользователь должен иметь привилегию CREATE USER на целевом сервере.
  • Привилегии DROP на уровне сервера на целевом объекте, чтобы удалить таблицы, которые уже могут существовать. Например, при повторной попытке миграции.
  • Привилегии "REFERENCES" на уровне сервера на целевом объекте для создания таблиц с внешними ключами.
  • При миграции на MySQL 8.0 пользователь должен иметь привилегию "SESSION_VARIABLES_ADMIN" на целевом сервере.
  • Привилегия CREATE на уровне сервера на целевом объекте.
  • Привилегия INSERT на уровне сервера на целевом объекте.
  • Привилегия UPDATE на уровне сервера на целевом объекте.
  • Привилегия DELETE на уровне сервера на целевом объекте.

Ограничения

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

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

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

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

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

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

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

  • Репликация инструкций поддерживается для баз данных, таблиц и объектов схемы (представлений, подпрограмм, триггеров), выбранных для миграции схемы при настройке миграции Azure DMS. Инструкции определения и администрирования данных для баз данных, таблиц и объектов схемы, которые не выбраны, не будут реплицироваться. Выбор всего сервера для миграции проведет репликацию операторов для всех таблиц, баз данных и объектов схемы, созданных на исходном сервере после завершения начальной загрузки.
  • Репликация инструкций Azure DMS поддерживает все инструкции определения данных, перечисленные здесь, за исключением следующих команд:
    • Инструкции LOGFILE GROUP
    • Инструкции SERVER
    • Операторы SPATIAL REFERENCE SYSTEM
    • Инструкции TABLESPACE
  • Репликация инструкций Azure DMS поддерживает все инструкции администрирования данных — инструкции управления учетными записями, перечисленные здесь, за исключением следующих команд:
    • УСТАНОВКА РОЛИ ПО УМОЛЧАНИЮ
    • УСТАНОВКА ПАРОЛЯ
  • Репликация инструкций Azure DMS поддерживает все инструкции администрирования данных — обслуживания таблиц, перечисленные здесь, за исключением следующих команд:
    • REPAIR TABLE
    • ANALYZE TABLE
    • ТАБЛИЦА КОНТРОЛЬНЫХ СУММ

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

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

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

  Отдельный сервер: ценовая	Отдельный сервер: виртуальные ядра	Гибкий сервер: объем вычислительных ресурсов	Гибкий сервер: уровень вычислительных ресурсов
  Базовый 1	1	Общего назначения	Standard_D16ds_v4
  Базовый 1	2	Общего назначения	Standard_D16ds_v4
  Общего назначения 1	4	Общего назначения	Standard_D16ds_v4
  Общего назначения 1	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 с помощью портал Azure.

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

  • Пользователю, выполняющим миграцию, требуются следующие разрешения:
    • Убедитесь, что у пользователя есть разрешение "REPLICATION_APPLIER" или "BINLOG_ADMIN" на целевом сервере для применения журнала bin.
    • Убедитесь, что у пользователя есть разрешение REPLICATION SLAVE на целевом сервере.
    • Убедитесь, что у пользователя есть разрешение "REPLICATION CLIENT" и "REPLICATION SLAVE" на исходном сервере для чтения и применения журнала bin.
    • Чтобы создать таблицы в целевом объекте, пользователь должен иметь привилегию CREATE.
    • При переносе таблицы с параметрами секции DATA DIRECTORY или INDEX DIRECTORY пользователь должен иметь права "FILE".
    • При миграции в таблицу с параметром UNION пользователь должен иметь привилегии SELECT, UPDATE и DELETE для таблиц, сопоставленных с таблицей MERGE.
    • При переносе представлений необходимо иметь привилегию CREATE VIEW. Помните, что некоторые привилегии могут потребоваться в зависимости от содержимого представлений. Дополнительные сведения см. в документах MySQL, относящихся к версии инструкции CREATE VIEW.
    • При переносе событий пользователь должен иметь привилегию 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. В разделе "Ценовая категория общего назначения" на портале увеличьте категорию сервера до 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, а затем найдите и выберите подписки.

   

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

   

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

   

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

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

   

2. На экране 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. Выберите Перейти к ресурсу.

    

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

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

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

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

   

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

   

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

   Примечание.

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

   

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

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

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

   

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

   

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

   Примечание.

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

   

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

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

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

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

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

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

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

   

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

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

   Примечание.

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

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

   

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

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

   

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

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

   

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

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

   

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

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

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

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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