Share via

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

  • Статья

Примечание.

Эта статья содержит упоминания термина slave (ведомый) . Корпорация Майкрософт больше не использует его. Когда этот термин будет удален из программного обеспечения, мы удалим его из статьи.

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

Примечание.

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

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

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

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

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

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

Ограничения

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

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

Рекомендации по созданию гибкого сервера для ускорения загрузки данных с использованием 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.
  • Настройте новый гибкий целевой сервер следующим образом:
    • Пользователю, выполняющим миграцию, требуются следующие разрешения:
      • Убедитесь, что у пользователя есть разрешение "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, а затем найдите и выберите подписки. Screenshot of a Select subscriptions from Azure Marketplace.

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

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

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

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

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

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

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

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

  6. Справа от ценовой категории выберите "Настройка уровня". Screenshot of a Select Configure Tier.

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

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

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

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

    Важно!

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

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

    Примечание.

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

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

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

  11. Выберите Перейти к ресурсу. Screenshot of a Select Go to resource.

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

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

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

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

    Screenshot of a Locate all instances of Azure Database Migration Service.

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

    Screenshot of a Select a new migration project.

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

    Примечание.

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

    Screenshot of a Create a new migration project.

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

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

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

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

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

    Примечание.

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

Screenshot of a Select database.

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

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

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

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

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

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

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

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

    Примечание.

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

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

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

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

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

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

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

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

    Screenshot of a Monitoring migration.

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

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

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

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

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

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

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

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

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

    Отдельный сервер: ценовая Отдельный сервер: виртуальные ядра Гибкий сервер: объем вычислительных ресурсов Гибкий сервер: уровень вычислительных ресурсов
    Основное 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, проверьте совместимость своего приложения.
    • После завершения тестирования можно приступать к переносу рабочих баз данных. На этом этапе необходимо окончательно определить дату и время миграции в рабочей среде. В идеале интенсивность использования приложений в этот период должна быть низкой. Все заинтересованные лица, которых требуется привлечь к процессу, должны быть доступны и готовы. Для миграции в рабочей среде потребуется тщательный мониторинг. При миграции по сети репликация должна быть завершена перед выполнением прямой миграции, чтобы предотвратить потерю данных.
  • Перенаправьте все зависимые приложения, чтобы получить доступ к новой базе данных и сделайте исходный сервер доступным только для чтения. Затем откройте приложения для использования в рабочей среде.
  • После запуска приложения на целевом гибком сервере внимательно отслеживайте производительность базы данных, чтобы понять, не требуется ли ее скорректировать.

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