Автоматическая миграция на месте из базы данных Azure для MySQL — с отдельного сервера на гибкий сервер

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для MySQL — отдельный сервер

Автомиграция на месте из База данных Azure для MySQL — единый сервер на гибкий сервер — это миграция, инициированная на месте во время планового периода обслуживания для рабочих нагрузок отдельной базы данных с базовым, общим назначением или оптимизированным для памяти SKU и без сложных функций (реплика чтения, виртуальная сеть, двойное инфракрасное шифрование, включенные правила конечной точки или виртуальной сети службы. Подходящие серверы определяются службой и получают предварительное уведомление с подробными инструкциями для просмотра сведений о миграции.

Миграция на месте обеспечивает высокую устойчивость и самовосстановление автономной миграции во время запланированного периода обслуживания с менее чем 5 мин простоя для SKU общего назначения и оптимизированного для памяти номера SKU и до 30 минут для базового SKU. Она использует технологию резервного копирования и восстановления для ускорения миграции. Эта миграция удаляет затраты на перенос сервера вручную и гарантирует, что вы можете воспользоваться преимуществами гибкого сервера, включая более высокую цену и производительность, детализированный контроль над конфигурацией базы данных и пользовательскими окнами обслуживания. Ниже описаны ключевые этапы миграции.

• Целевой гибкий сервер развертывается, наследуя все наборы компонентов и свойства (включая параметры сервера и правила брандмауэра) от исходного отдельного сервера. Исходный отдельный сервер имеет значение только для чтения, а резервное копирование с исходного отдельного сервера копируется на целевой гибкий сервер.
• Переключение DNS и переключение выполняются успешно в течение запланированного периода обслуживания с минимальным временем простоя, что позволяет обслуживать те же строка подключения после миграции. Клиентские приложения легко подключаются к целевому гибкому серверу без каких-либо обновлений, управляемых пользователем вручную. Помимо форматов строка подключения (один и гибкий сервер), поддерживаемых на перенесенном гибком сервере, оба формата имен пользователей — username@server_name и имя пользователя также поддерживаются на перенесенном гибком сервере.
• Перенесенный гибкий сервер находится в сети и теперь можно управлять с помощью портал Azure/CLI. Остановленный отдельный сервер удаляется через семь дней после миграции.

Пригодность

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

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

• Экземпляр одного сервера должен находиться в состоянии готовности и не должен находиться в состоянии остановки во время запланированного периода обслуживания для автоматического автоматического выполнения.
• Если исходный База данных Azure для MySQL отдельный сервер имеет версию подсистемы версии 8.x, убедитесь, что для обновления версии драйвера клиента .NET исходного сервера до версии 8.0.32, чтобы избежать несовместимости кодировки после миграции на гибкий сервер.
• Если исходный База данных Azure для MySQL отдельный сервер имеет версию подсистемы версии 8.x, убедитесь, что до версии TLS версии 1.0 или версии 1.1 до TLS версии 1.2 до миграции, так как старые версии TLS не рекомендуется использовать для гибкого сервера.
• Если на сервере есть реплики чтения, удалите реплики чтения. Вы можете настроить реплики чтения после автоматической миграции.
• Если сервер имеет конечные точки службы (правила виртуальной сети) или виртуальная сеть конфигурацию, попробуйте удалить их или перейти к Приватный канал функции на одном сервере.
• Если у сервера включено двойное шифрование инфраструктуры, рассмотрите возможность перехода на функцию управляемого клиентом ключа (CMK) на экземпляре одного сервера.

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

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

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

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

Просмотр и настройка расписания миграции и сведений

Ниже описаны способы проверки расписания миграции после получения уведомления автомиграции на месте:

• На странице обзора одного сервера для вашего экземпляра отображается баннер портала с информацией о расписании миграции.

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

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

• Если у отдельного сервера есть номер SKU общего назначения, вы можете включить высокий уровень доступности при проверке расписания миграции. Так как высокий уровень доступности можно включить только во время создания гибкого сервера MySQL, настоятельно рекомендуется включить эту функцию при просмотре расписания миграции.

• Если у экземпляра одного сервера есть один или несколько Приватный канал, управляемый клиентом ключ (CMK) и администратор Microsoft Entra, для автоматической миграции на месте требуются обязательные входные данные для частных конечных точек, CMK и администратора Microsoft Entra Admin переносятся с одного экземпляра сервера на целевой экземпляр гибкого сервера. Входные данные пользователя должны быть предоставлены через 2 дня до запланированного окна миграции. Если входные данные пользователя не предоставляются до блокировки сведений о миграции, миграция будет перепланирована на более поздний момент времени. После предоставления всех входных данных убедитесь, что необходимо сохранить конфигурацию в мастере автоматической миграции. Действия для предоставления входных данных пользователей:

  • Перейдите в колонку миграции экземпляра отдельного сервера и выберите изменение запланированной миграции.
  • В разделе "Сведения о автоматической миграции" нажмите кнопку "Аутентификация", чтобы проверить подлинность и сохранить подключение API ARM для переноса сервера.
  • Если на сервере настроен администратор Microsoft Entra, вы можете предоставить входные данные в разделе "Администратор Microsoft Entra" в мастере автоматической миграции:
    • Для миграции администратора Microsoft Entra для целевого сервера требуется добавить удостоверение в База данных Azure для MySQL — гибкий сервер. Удостоверение требует предоставления следующих привилегий— User.Read.All, GroupMember.Read.All и Application.Read.All . Выберите соответствующее управляемое удостоверение, назначаемое пользователем, и предоставьте нужные разрешения, выполнив следующие действия.
  • Если на сервере настроен ключ, управляемый клиентом, можно указать входные данные в разделе "Шифрование данных" в мастере автоматической миграции:
    • Для переноса шифрования управляемых клиентом ключей требуется добавить удостоверение в База данных Azure для MySQL — гибкий сервер. Выберите соответствующее управляемое удостоверение, назначаемое пользователем. Указанный идентификатор ключа или ключ будет перенесен из источника на целевой сервер и должен быть предоставлен следующие привилегии: Get, Wrap Key, Unwrap Key для доступа к хранилищу ключей.
  • Если у отдельного сервера есть частные конечные точки, выполните следующие обязательные действия при просмотре расписания миграции не менее 2 дней до запланированной миграции:
    • Просмотрите перечисленные частные конечные точки, которые необходимо перенести. Убедитесь, что они помечены как готовые к миграции. Если они помечены как недопустимые, выберите соответствующую подписку и частную зону DNS.
      • Пользовательская Частная зона DNS зона не поддерживается автоматическим переносом. Зона Частная зона DNS должна быть privatelink.mysql.database.azure.com.
      • Метод утверждения подключения частных конечных точек должен быть задан как автоматический утверждение, а не ручное утверждение. Частные конечные точки утверждения вручную не поддерживаются автоматической миграцией.
    • Убедитесь, что у вас есть доступ к роли участника уровня подписки или группы ресурсов, чтобы избежать проблем с разрешениями при проверке подлинности.
    • Установите флажок подтверждения после выполнения перечисленных проверок необходимых компонентов для переноса частных конечных точек.

  Примечание.

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

  Примечание.

  Для одного экземпляра сервера с частными конечными точками удалите экземпляр источника одного сервера после проверки миграции. Если операция удаления сервера не выполняется, исходный экземпляр сохраняется до 14 дней после удаления службой.

Проверка готовности к автомиграции на месте

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

• Экземпляр одного сервера должен находиться в состоянии готовности и не должен находиться в состоянии остановки во время запланированного периода обслуживания для автоматического автоматического выполнения.
• Параметры сервера, параметры, настройки и правила брандмауэра отдельного экземпляра не должны обновляться в течение 2-го дня до запланированной автоматической миграции.
• Для одного экземпляра сервера с включенным SSL убедитесь, что у вас есть все три сертификата (БалтиморCyberTrustRoot, DigiCertGlobalRootG2 Root CA и DigiCertGlobalRootCA Root CA) доступны в доверенном корневом хранилище. Кроме того, если у вас есть сертификат, закрепленный на строка подключения создайте объединенный сертификат ЦС со всеми тремя сертификатами до запланированной автоматической миграции, чтобы обеспечить непрерывность бизнес-процессов после миграции.
• Подсистема MySQL не гарантирует порядок сортировки, если в запросах нет предложения SORT. После автомиграции на месте может наблюдаться изменение порядка сортировки. Если сохранение порядка сортировки имеет решающее значение, убедитесь, что запросы обновляются, чтобы включить предложение SORT до запланированной автоматической автомиграции на месте.
• Если исходный База данных Azure для MySQL отдельный сервер имеет версию подсистемы версии 8.x, убедитесь, что для обновления версии драйвера клиента .NET исходного сервера до версии 8.0.32, чтобы избежать несовместимости кодировки после миграции на гибкий сервер.
• Если исходный База данных Azure для MySQL отдельный сервер имеет версию подсистемы версии 8.x, убедитесь, что до версии TLS версии 1.0 или версии 1.1 до TLS версии 1.2 до миграции, так как старые версии TLS не рекомендуется использовать для гибкого сервера.
• Если в исходном База данных Azure для MySQL отдельный сервер имеет имена правил брандмауэра, превышающие 80 символов, переименуйте их, чтобы длина имени была меньше 80 символов. (Длина имени правила брандмауэра, поддерживаемая на гибком сервере, составляет 80 символов, в то время как на одном сервере разрешенная длина составляет 12 8 символов.)
• Если исходный База данных Azure для MySQL отдельный сервер использует недефекционные порты, такие как 3308 3309 и 3310, измените порт подключения на 3306, так как указанные выше порты не поддерживаются на гибком сервере.

Как выполняется автоматическая подготовка целевого гибкого сервера MySQL?

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

• Версия MySQL, регион, *размер хранилища, подписка и группа ресурсов для целевого гибкого сервера совпадает с размером исходного отдельного сервера.
• Для отдельных серверов с хранилищем менее 20 ГиБ размер хранилища равен 20 ГиБ, так как это минимальное ограничение хранилища на База данных Azure для MySQL — гибкий сервер.
• Оба формата имени пользователя — username@server_name (один сервер) и имя пользователя (гибкий сервер) поддерживаются на перенесенном гибком сервере.
• Оба формата строка подключения — один сервер и гибкий сервер поддерживаются на перенесенном гибком сервере.
• Для одного экземпляра сервера с включенным хранилищем запросов параметр сервера "slow_query_log" в целевом экземпляре имеет значение ON, чтобы обеспечить четность компонентов при миграции на гибкий сервер. Для некоторых рабочих нагрузок это может повлиять на производительность и при возникновении какого-либо снижения производительности задайте для этого параметра значение OFF на экземпляре гибкого сервера.

Шаги после миграции

Ниже приведены сведения, которые необходимо знать после миграции на месте:

• Скопируйте следующие свойства из исходного односерверного сервера в целевую операцию гибкого сервера после миграции на месте успешно завершено:
  • Параметры страницы мониторинга (оповещения, метрики и параметры диагностики) и параметры блокировки
  • Все скрипты Terraform/CLI, размещенные для управления экземпляром отдельного сервера, должны быть обновлены с помощью ссылок на гибкий сервер.
• Для одного экземпляра сервера с включенным хранилищем запросов параметр сервера "slow_query_log" в целевом экземпляре имеет значение ON, чтобы обеспечить четность компонентов при миграции на гибкий сервер. Обратите внимание, что для некоторых рабочих нагрузок это может повлиять на производительность, и если вы наблюдаете какое-либо снижение производительности, задайте для этого параметра значение OFF на экземпляре гибкого сервера.
• Для одного экземпляра сервера с частными конечными точками удалите экземпляр источника одного сервера после проверки миграции. Если операция удаления сервера не выполняется, исходный экземпляр сохраняется до 14 дней после удаления службой.
• Для одного экземпляра сервера с включенным Microsoft Defender для облака состояние включения переносится. Чтобы достичь четности в гибком сервере после автоматической автомиграции свойств, которые можно настроить на одном сервере, рассмотрим сведения в следующей таблице:

Часто задаваемые вопросы (FAQ)

В. Почему выполняется автоматическая миграция?

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

В. Как выполняется автоматическая миграция? Что выполняется миграция?

А. Гибкий сервер подготавливается для соответствия тем же виртуальным ядрам и хранилищу, что и ваш отдельный сервер. Затем исходный отдельный сервер переводится в состояние остановки, делается снимок файла данных и копируется на целевой гибкий сервер. Переключение DNS выполняется для маршрутизации всех существующих подключений к целевому серверу, и целевой гибкий сервер подключается к сети. Автоматическая миграция переносит все файлы данных сервера (включая схему, данные, имена входа) в дополнение к параметрам сервера (все измененные параметры сервера в источнике копируются в целевой, неизмененные параметры сервера принимают значение по умолчанию, определенное гибким сервером) и правила брандмауэра. Это автономная миграция, при которой время простоя составляет до 5 минут или меньше.

В. Как настроить или просмотреть оповещения о миграции на месте?

А. Ниже приведены способы настройки оповещений.

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

В. Как отложить запланированную миграцию?

А. Вы можете просмотреть расписание миграции, перейдя к колонке "Миграция" своего экземпляра Single Server. Если вы хотите отложить миграцию, вы можете отложить на месяц больше всего, перейдя в колонку миграции одного экземпляра сервера на портал Azure и перепланируя миграцию, выбрав другое окно миграции в течение месяца. Сведения о миграции блокируются семь дней до запланированного окна миграции, после которого не удается перепланировать. Эту миграцию на месте можно откладывать ежемесячно до 16 сентября 2024 г.

В. Какое имя пользователя и строка подключения будут поддерживаться для перенесенного гибкого сервера? ​​

А. Оба формата имени пользователя — username@server_name (формат одного сервера) и имя пользователя (гибкий формат сервера) поддерживаются для перенесенного гибкого сервера, поэтому их не требуется обновлять для поддержания непрерывности приложений после миграции. Кроме того, для перенесенного гибкого сервера также поддерживаются оба формата строка подключения (одиночный и гибкий формат сервера).

В. Как включить высокий уровень доступности (высокий уровень доступности) для моего автоматически перенесенного сервера??

А. По умолчанию автоматическая миграция настраивает миграцию на экземпляр без HA. Поскольку HA может быть включен только во время создания сервера, вам следует включить высокий уровень доступности перед запланированной автоматической миграцией, используя параметр редактирования расписания автоматической миграции на портале. Высокий уровень доступности можно включить только для SKU общего назначения\Оптимизированные для памяти номера SKU на целевом гибком сервере, так как миграция SKU с поддержкой высокой доступности не поддерживает конфигурацию высокого уровня доступности.

В. Я вижу разницу в ценах на мой потенциальный переход с отдельного сервера MySQL Basic на гибкий сервер MySQL??

А. Несколько серверов могут увидеть небольшое увеличение цен после миграции (предполагаемые затраты можно увидеть, выбрав вариант изменения расписания автоматической миграции на портале), так как минимальный предел хранилища для обоих предложений отличается (5 ГиБ на одном сервере; 20 ГиБ на гибком сервере) и стоимость хранения (0,1$ на одном сервере; 0,115$ на гибком сервере) для гибкого сервера немного выше, чем один сервер. Для затронутых серверов это увеличение цен на гибкий сервер обеспечивает лучшую пропускную способность и производительность по сравнению с одним сервером.

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

• Управление База данных Azure для MySQL — гибким сервером с помощью портал Azure.