Что происходит с Отдельным сервером Базы данных Azure для MySQL?

  • Статья

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

Внимание

База данных Azure для MySQL — отдельный сервер находится на пути выхода на пенсию и вышел на пенсию 16 сентября 2024 года.

После многих лет развития База данных Azure для MySQL — односерверная служба больше не может обрабатывать все новые функции, функции и потребности в безопасности. Мы рекомендуем выполнить обновление до База данных Azure для MySQL — гибкий сервер до 16 сентября 2024 г., чтобы избежать непреднамерельной принудительной миграции и недоступности сервера.

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

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

В рамках этого выхода на пенсию мы больше не поддерживаем создание новых экземпляров одного сервера с портал Azure начала 16 января 2023 г. и Azure CLI с 19 марта 2024 г. Вы по-прежнему сможете создавать реплики чтения и выполнять восстановление (PITR и геовосстановление) для существующего экземпляра одного сервера, и это будет поддерживаться до даты заката 16 сентября 2024 года.

Миграция с отдельного сервера на гибкий сервер

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

Сценарий Инструменты Сведения
Автономный или онлайн База данных Azure для MySQL импорт и Azure CLI Руководство по База данных Azure для MySQL импорта с помощью Azure CLI
Offline Database Migration Service (классическая версия) и портал Azure Руководство. DMS (классическая версия) с порталом Azure (в автономном режиме)
Миграция по сети Database Migration Service (классическая версия) и портал Azure Руководство: DMS (классическая версия) с помощью портала Azure (онлайн)
Offline Запрос автомиграции на месте (запрос в службу поддержки Azure) Автоматическая автоматизация База данных Azure для MySQL на гибкий сервер на месте

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

Примечание.

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

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

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

Что происходит после даты заката (16 сентября 2024 г.)?

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

Начиная с 17 сентября, неотключаемые серверы, которые еще не перенесены, будут периодически остановлены. Вам потребуется прийти к портал Azure, подтвердить действия миграции и запустить сервер. После запуска сервера перейдите к использованию интерфейса командной строки База данных Azure для MySQL или Службы миграции данных Azure для миграции на База данных Azure для MySQL гибкий сервер. С другой стороны, если вы хотите продолжить автоматическую миграцию, отправьте запрос в службу поддержки Azure, чтобы получить расписание автоматической миграции. Убедитесь, что сервер запускается и переносится на гибкий сервер, чтобы избежать принудительной принудительной миграции позже, что приведет к недоступности сервера, так как можно перенести только ограниченные функции.

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

Примечание.

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

Дата окончания принудительной миграции

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

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

  • Приватный канал
  • Шифрование данных (CMK)
  • Проверка подлинности Microsoft Entra (ersttime Microsoft Entra ID)
  • Конечные точки служб
  • Двойное шифрование инфраструктуры
  • Реплики чтения

Действие, необходимое после принудительной миграции

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

После принудительной миграции необходимо перенастроить функции, перечисленные выше на перенесенном экземпляре гибкого сервера, чтобы обеспечить непрерывность бизнес-процессов:

  • Приватный канал . Вы можете включить общедоступный доступ для подключения к серверу немедленно или удалить экземпляр одного сервера и удалить связанную частную конечную точку, чтобы иметь возможность настроить ту же частную конечную точку для перенесенного гибкого экземпляра сервера. Дополнительные сведения о настройке частных конечных точек для гибкого сервера см. здесь
  • Шифрование данных (CMK) — узнайте больше о настройке здесь
  • Проверка подлинности Microsoft Entra (ersttime Microsoft Entra ID) — дополнительные сведения о настройке здесь
  • Конечные точки службы — конечная точка службы (правило виртуальной сети) не поддерживается на гибком сервере База данных Azure для MySQL. Рекомендуется настроить Приватный канал для соответствия четности функций. Дополнительные сведения о настройке Приватный канал см. здесь
  • Двойное шифрование инфраструктуры — двойное шифрование инфраструктуры не поддерживается на гибком сервере База данных Azure для MySQL. Рекомендуется настроить шифрование данных для соответствия четности компонентов. Дополнительные сведения о настройке шифрования данных (CMK) см. здесь
  • Реплики чтения — реплики чтения будут перенесены как отдельные автономные серверы. Настройте реплики чтения для основного сервера, ссылаясь на перенесенный дополнительный автономный сервер, который можно удалить после настройки. Дополнительные сведения о настройке здесь

Примечание.

Если сервер находится в регионе, где База данных Azure для MySQL — гибкий сервер не поддерживается, то после даты заката экземпляр одного сервера будет доступен с ограниченными операциями для доступа к данным и возможность миграции на гибкий сервер до 15 ноября 2024 года. Экземпляр не будет принудительно перенесен на гибкий сервер до 15 ноября 2024 г. Серверы будут остановлены в первой неделе декабря 2024 года. Сервер можно перезапустить с помощью портала Azure или ИНТЕРФЕЙСА командной строки и перенести в течение 7 дней. Если сервер не переносится в указанный выше льготный период, он будет принудительно перенесен во второй неделе декабря 2024 года. После 31 декабря серверы будут удалены для удаления платформы. Настоятельно рекомендуется использовать один из следующих вариантов миграции до 22 ноября 2024 г., чтобы избежать сбоев в непрерывности бизнес-процессов.

  • Используйте Azure DMS, чтобы выполнить миграцию между регионами на гибкий сервер в подходящем регионе Azure.
  • Миграция на сервер MySQL, размещенный на виртуальной машине в регионе, если вы не сможете изменить регионы из-за проблем с соответствием требованиям.

Настройка свойств Microsoft Defender для облака в гибком сервере

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

Свойство Конфигурация
Подавление определенных типов оповещений Отключите определенные типы оповещений с помощью платформы Microsoft Defender для облака. Дополнительные сведения см. в руководстве по подавлению оповещений из Microsoft Defender для облака.

Пользователи одного сервера могут использовать свойство API:
properties.disabledAlerts
Уведомления по электронной почте Определите уведомление по электронной почте для оповещений Microsoft Defender для облака для всех ресурсов в подписке. Дополнительные сведения см. в статье "Настройка Уведомления по электронной почте для оповещений системы безопасности".

Пользователи одного сервера могут использовать свойства API:
properties.emailAccountAdmins,
properties.emailAddresses
Экспорт оповещений для дальнейшей обработки и/или архивации Оповещения хранятся на платформе Microsoft Defender для облака и предоставляются с помощью Azure Resource Graph.
Вы можете экспортировать оповещения в другое хранилище и управлять хранением отдельно. Дополнительные сведения см. в статье о настройке непрерывного экспорта в портал Azure — Microsoft Defender для облака.

Пользователи одного сервера могут использовать свойства API:
properties.retentionDays,
properties.storageAccountAccessKey,
properties.storageEndpoint

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

В. Почему База данных Azure для MySQL-один сервер отменяется?

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

В. Почему мне предлагается выполнить миграцию на База данных Azure для MySQL — гибкий сервер?

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

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

В. Как скоро необходимо перенести один сервер на гибкий сервер?

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

В. Что происходит с существующими База данных Azure для MySQL экземплярами одного сервера?

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

В. Можно ли продолжить работу одного сервера за пределами даты заката?

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

В. Одиночный сервер развертывается в регионе, который не поддерживает гибкий сервер. Что произойдет с датой заката сервера после заката?

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

  • Используйте Azure DMS, чтобы выполнить миграцию между регионами на гибкий сервер в подходящем регионе Azure.
  • Миграция на сервер MySQL, размещенный на виртуальной машине в регионе, если вы не сможете изменить регионы из-за проблем с соответствием требованиям.

В. Дата заката после потери данных на одном сервере?

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

В. Что делать после объявления о прекращении поддержки отдельного сервера, если мне по-прежнему нужно создать новый отдельный сервер для удовлетворения бизнес-потребностей?

А. В рамках этого выхода на пенсию мы больше не будем поддерживать создание новых экземпляров одного сервера с портал Azure начала 16 января 2023 года. Кроме того, начиная с 19 марта 2024 г. вы больше не сможете создавать новые экземпляры одного сервера База данных Azure для MySQL с помощью Azure CLI. Если вам по-прежнему нужно создать экземпляры одного сервера для удовлетворения потребностей непрерывности бизнес-процессов, создайте запрос поддержка Azure.

В. Что делать после объявления о прекращении поддержки отдельного сервера, если мне по-прежнему нужно создать новую реплику чтения для одного экземпляра сервера?

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

В. Существуют ли дополнительные затраты, связанные с выполнением миграции?

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

В. Влияет ли выставление счетов на гибкий сервер по сравнению с одним сервером?

А. Если выбрать ту же зону или избыточность зоны для целевого гибкого сервера, счет выше, чем на одном сервере. Чтобы обеспечивать высокий уровень доступности, избыточный между зонами или в одной зоне, требуется развернуть сервер горячей замены с хранением избыточной резервной копии и, следовательно, это создаст дополнительные затраты. Эта архитектура позволяет сократить время простоя во время незапланированных прекращений работы и планового обслуживания. Кроме того, в зависимости от рабочей нагрузки гибкие серверы могут обеспечить более высокую производительность по сравнению с одними серверами, благодаря чему вы можете выполнять рабочую нагрузку с более низким номером SKU на гибких серверах, и, следовательно, общая стоимость может быть похожа на общую производительность одного сервера.

В. Требуется ли время простоя для переноса одного сервера на гибкий сервер?

А. Чтобы ограничить возможное время простоя, выполните миграцию на Гибкий сервер по сети. Это обеспечивает минимальное время простоя.

В. Будут ли будущие обновления на одном сервере для поддержки последних версий MySQL?

А. Для версии 8.0 Отдельного сервера последним дополнительным номером версии обновления будет 8.0.15. Рассмотрите возможность миграции на Гибкий сервер, чтобы использовать преимущества, которые предоставляют обновления последних версий.

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

А. Развертывание, избыточное между зонами гибкого сервера, обеспечивает доступность 99,99 % с устойчивостью зонального уровня, а отдельный сервер обеспечивает устойчивость в одной зоне доступности. Архитектура высокой доступности гибкого сервера развертывает теплый резервный режим с избыточными вычислительными ресурсами и хранилищем (с данными каждого сайта, хранящимися в 3x копиях), по сравнению с архитектурой высокого уровня доступности одного сервера, которая не имеет пассивного горячего резерва, чтобы помочь восстановиться после зональных сбоев. Архитектура высокого уровня доступности гибкого сервера позволяет сократить время простоя во время незапланированных сбоев и планового обслуживания.

В. Какие варианты миграции доступны для миграции одного сервера на гибкий сервер?

А. Для миграции можно использовать База данных Azure для MySQL Импорт (рекомендуется). Кроме того, можно использовать Database Migration Service (классическую) для запуска в сети или автономной миграции.

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

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

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

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

В. У меня есть конечная точка службы (правила виртуальной сети), настроенная для одного сервера, и эта функция не поддерживается на гибком сервере. Как выполнить миграцию

А. Конечная точка службы (правило виртуальной сети) не поддерживается на гибком сервере База данных Azure для MySQL. Рекомендуется настроить Приватный канал на перенесенном экземпляре гибкого сервера для соответствия четности компонентов. Дополнительные сведения о настройке Приватный канал см. здесь.

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

А. Двойное шифрование инфраструктуры не поддерживается на гибком сервере База данных Azure для MySQL. Мы рекомендуем настроить шифрование данных на перенесенном гибком сервере для соответствия четности функций. Дополнительные сведения о настройке шифрования данных (CMK) см. здесь.

В. У меня есть протокол TLS версии 1.0/1.1, настроенный для одного сервера версии 8.0, и эта функция в настоящее время не поддерживается в гибком сервере. Как выполнить миграцию

А. Для поддержки современных стандартов безопасности выпуск сообщества MySQL прекратил поддержку обмена данными по протоколам TLS 1.0 и 1.1, начиная с версии 8.0.28. Мы рекомендуем обновить клиентские драйверы, чтобы поддерживать TLSv1.2, чтобы безопасно подключаться к База данных Azure для MySQL — одиночный сервер, а затем перейти к миграции на гибкий сервер.

В. Можно ли откатить миграцию с отдельного сервера на гибкий сервер?

А. Вы можете выполнить любое количество тестовых миграций, а когда добьетесь доверительного уровня результатов тестирования, — окончательно перенести сервер. Тестовая миграция не влияет на исходный отдельный сервер, который остается рабочим и продолжает реплицироваться, пока не будет выполняться фактическая миграция. Если во время тестовой миграции возникнут ошибки, можно отложить окончательный перенос, при этом сохранив работу исходного сервера. После устранения ошибок можно повторить попытку окончательной миграции. После окончательного переноса на Гибкий сервер и завершения работы исходного отдельного сервера вы не сможете выполнить откат с Гибкого сервера на Отдельный.

В. Размер моей базы данных превышает 1 ТБ, поэтому как продолжить миграцию?

А. Вы можете использовать База данных Azure для MySQL Импорт (рекомендуется) для миграции, которая является высокопроизводительной для более тяжелых рабочих нагрузок.

В. Поддерживается ли миграция между регионами?

А. Azure Database Migration Service поддерживает миграцию между регионами, поэтому с помощью службы вы можете перенести отдельный сервер на гибкий сервер, развернутый в другом регионе.

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

А. Azure Database Migration Service поддерживает миграцию на другие подписки, поэтому с помощью службы вы можете перенести отдельный сервер на гибкий сервер, развернутый с использованием другой подписки.

В. Поддерживается ли подписка для разных групп ресурсов?

А. Azure Database Migration Service поддерживает миграцию между группами ресурсов, поэтому с помощью службы вы можете перенести отдельный сервер на гибкий сервер, развернутый в другой группе ресурсов.

В. Поддерживаются ли разные версии?

А. Да, миграция с помощью Azure Database Migration Service предусматривает миграцию с серверов MySQL более ранней версии (5.6 и более поздних) на серверы более поздних версий.

В. Мой База данных Azure для MySQL отдельный сервер использует порты, не используемые по умолчанию, такие как 3308 3309 и 3310, которые не поддерживаются на гибком сервере. Что делать, чтобы обеспечить подключение при миграции на гибкий сервер?

А. Если исходный База данных Azure для MySQL отдельный сервер использует недефекционные порты, такие как 3308 3309 и 3310, измените порт подключения на 3306, так как указанные выше порты не поддерживаются на гибком сервере.

В. У меня есть дополнительные вопросы о выходе на пенсию. Как получить помощь в нем?

А. Если у вас есть вопросы, получите ответы от экспертов сообщества в Microsoft Q&A. Если у вас есть план поддержки и вам нужна техническая помощь, создайте запрос на поддержку:

  1. В поле "Сводка" введите описание проблемы.
  2. В качестве типа проблемы укажите Техническая.
  3. В качестве подписки выберите свою подписку.
  4. В качестве службы выберите Мои приложения.
  5. Для типа службы выберите База данных Azure для MySQL один сервер.
  6. Для ресурса выберите ресурс.
  7. Для типа проблемы выберите "Миграция".
  8. Для подтипа проблемы выберите "Миграция с одного на гибкий сервер"

Ознакомьтесь с часто задаваемыми вопросами об использовании Azure Database Migration Service (классической) для База данных Azure для MySQL — миграции с одним сервером на гибкий сервер.

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

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