Что происходит с Отдельным сервером Базы данных Azure для MySQL?
ОБЛАСТЬ ПРИМЕНЕНИЯ:
База данных Azure для MySQL — отдельный сервер
База данных Azure для MySQL — отдельный сервер находится на пути выхода на пенсию и планируется выйти на пенсию к 16 сентября 2024 года.
В рамках этого выхода на пенсию мы больше не будем поддерживать создание новых экземпляров одного сервера с портал Azure начала 16 января 2023 г. и Azure CLI с 19 марта 2024 г. Если вам по-прежнему нужно создать экземпляры одного сервера для удовлетворения потребностей непрерывности бизнес-процессов, создайте запрос поддержка Azure. Вы по-прежнему сможете создавать реплика чтения и выполнять восстановление (PITR и геовосстановление) для существующего экземпляра одного сервера, и это будет по-прежнему поддерживаться до даты заката 16 сентября 2024 года.
После многих лет развития База данных Azure для MySQL — односерверная служба больше не может обрабатывать все новые функции, функции и потребности в безопасности. Рекомендуется обновить до База данных Azure для MySQL — гибкий сервер.
База данных Azure для MySQL . Гибкий сервер — это полностью управляемая служба базы данных, готовая к работе с рабочей средой, предназначенная для более детального управления и гибкости функций управления базами данных и параметров конфигурации. Дополнительные сведения о гибком сервере см. в База данных Azure для MySQL — гибкий сервер.
Если у вас в настоящее время есть База данных Azure для MySQL — односерверная служба размещения рабочих серверов, мы рады сообщить вам, что вы можете перенести База данных Azure для MySQL - отдельные серверы на База данных Azure для MySQL — гибкая служба сервера бесплатной стоимости. с помощью База данных Azure для MySQL импорта, автомиграции на месте или Azure Database Migration Service (классическая модель). Ознакомьтесь с различными способами миграции в следующем разделе.
Миграция с отдельного сервера на гибкий сервер
Узнайте, как перейти с База данных 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 для MySQL на гибкий сервер на месте |
Дополнительные сведения о миграции с одного сервера на гибкий сервер с помощью других средств миграции см. в разделе "Выбор нужных средств для миграции в База данных Azure для MySQL".
Примечание.
Автоматическая миграция на месте с База данных Azure для MySQL — один сервер на гибкий сервер — это миграция, инициированная на месте во время планового периода обслуживания для выбора рабочих нагрузок базы данных с одним сервером. Подходящие серверы определяются службой и получают предварительное уведомление с подробными инструкциями для просмотра сведений о миграции. Если вы владеете одной рабочей нагрузкой сервера с используемым <хранилищем данных = 100 ГиБ и без сложных функций (CMK, Идентификатор Microsoft Entra, реплика чтения, Приватный канал), теперь вы можете назначить себя (если она еще не запланирована службой) для автоматической миграции, отправив сведения о сервере с помощью этой формы. Все остальные рабочие нагрузки с одним сервером рекомендуется использовать средства миграции, инициированные пользователем, предлагаемые Azure — Azure DMS, База данных Azure для MySQL Импорт для миграции. Дополнительные сведения об автоматической миграции см. здесь.
Что происходит после даты заката (16 сентября 2024 г.)?
Запуск односерверного экземпляра после окончания срока действия будет угрозой безопасности, так как на устаревшей платформе одного сервера не будет исправлена безопасность и исправление ошибок. Чтобы обеспечить выполнение управляемых экземпляров на доверенной и безопасной платформе после даты заката, экземпляр одного сервера вместе с файлами данных будет принудительно перенесен в соответствующий экземпляр гибкого сервера поэтапно. Настоятельно рекомендуется использовать интерфейс командной строки импорта База данных Azure для MySQL или Azure Data Migration Service для миграции на База данных Azure для MySQL — гибкий сервер до 16 сентября 2024 г. (ознакомьтесь с часто задаваемыми вопросами), чтобы избежать сбоев, вызванных принудительной миграцией, и обеспечить непрерывность бизнес-процессов.
Примечание.
Соглашения об уровне обслуживания, исправления ошибок, исправления безопасности или динамическую поддержку не будут учитываться для экземпляра отдельного сервера после даты заката.
Дата окончания принудительной миграции
Поместите дату заката, экземпляр отдельного сервера вместе с файлами данных будет принудительно перенесен в соответствующий гибкий экземпляр сервера поэтапно. Это может привести к ограниченной доступности функций, так как некоторые расширенные функциональные возможности не могут быть принудительно перенесены без ввода клиентов в экземпляр гибкого сервера. Узнайте больше о шагах по перенастройке таких функций после принудительной миграции, чтобы свести к минимуму возможный эффект ниже.
Следующие функции не могут быть принудительно перенесены, так как они требуют ввода клиентов для настройки и не будут включены в перенесенном экземпляре гибкого сервера:
- Приватный канал
- Шифрование данных (CMK)
- Проверка подлинности Microsoft Entra (ersttime Microsoft Entra ID)
- Конечные точки служб
- Двойное шифрование инфраструктуры
- Реплики чтения
- Microsoft Defender для облака
Действие, необходимое после принудительной миграции
После принудительной миграции необходимо перенастроить функции, перечисленные выше на перенесенном экземпляре гибкого сервера, чтобы обеспечить непрерывность бизнес-процессов:
- Приватный канал. Узнайте больше о настройке здесь
- Шифрование данных (CMK) — узнайте больше о настройке здесь
- Проверка подлинности Microsoft Entra (ersttime Microsoft Entra ID) — дополнительные сведения о настройке здесь
- Конечные точки службы — конечная точка службы (правило виртуальной сети) не поддерживается на гибком сервере База данных Azure для MySQL. Рекомендуется настроить Приватный канал для соответствия четности функций. Дополнительные сведения о настройке Приватный канал см. здесь
- Двойное шифрование инфраструктуры — двойное шифрование инфраструктуры не поддерживается на гибком сервере База данных Azure для MySQL. Рекомендуется настроить шифрование данных для соответствия четности компонентов. Дополнительные сведения о настройке шифрования данных (CMK) см. здесь
- Чтение реплик . Узнайте больше о настройке здесь
Важно. Односерверные серверы с включенными сетевыми функциями и функциями безопасности будут принудительно перенесены в гибкий экземпляр сервера с общедоступным доступом в отключенном состоянии для защиты данных клиентов. Необходимо включить соответствующий доступ после принудительной миграции, чтобы обеспечить непрерывность бизнес-процессов.
Примечание.
Если сервер находится в регионе, где База данных Azure для MySQL — гибкий сервер не поддерживается, то после даты заката экземпляр одного сервера будет доступен с ограниченными операциями для доступа к данным и возможности миграции на гибкий сервер. Экземпляр не будет принудительно перенесен на гибкий сервер. Настоятельно рекомендуется использовать один из следующих вариантов миграции до даты заката, чтобы избежать сбоев в непрерывности бизнес-процессов.
- Используйте Azure DMS, чтобы выполнить миграцию между регионами на гибкий сервер в подходящем регионе Azure.
- Миграция на сервер MySQL, размещенный на виртуальной машине в регионе, если вы не сможете изменить регионы из-за проблем с соответствием требованиям.
Настройка свойств Microsoft Defender для облака в гибком сервере
При переходе с База данных Azure для MySQL — отдельный сервер на гибкий сервер с включенным Defender для облака состояние включения сохраняется. Чтобы достичь четности в гибком сервере для свойств, которые можно настроить на одном сервере, рассмотрим сведения в следующей таблице.
| Свойство | Настройка |
|---|---|
| properties.disabledAlerts | Вы можете отключить определенные типы оповещений с помощью платформы Microsoft Defender для облака. Дополнительные сведения см. в статье "Подавление оповещений" из руководства по Microsoft Defender для облака. |
| properties.emailAccount Администратор s properties.emailAddresses |
Вы можете централизованно определить уведомление по электронной почте для оповещений Microsoft Defender для облака для всех ресурсов в подписке. Дополнительные сведения см. в статье "Настройка Уведомления по электронной почте для оповещений системы безопасности". |
| properties.retentionDays properties.storageAccountAccessKey properties.storageEndpoint |
Платформа Microsoft Defender для облака предоставляет оповещения через Azure Resource Graph. Вы можете экспортировать оповещения в другое хранилище и управлять хранением отдельно. Дополнительные сведения о непрерывном экспорте см. в статье "Настройка непрерывного экспорта" в портал Azure - Microsoft Defender для облака. |
Часто задаваемые вопросы (FAQ)
В. Почему База данных Azure для MySQL-один сервер отменяется?
А. Это предложение стало общедоступным в 2018 г. Тем не менее, учитывая отзывы клиентов и новые улучшения в вычислительных ресурсах, доступности, масштабируемости и производительности в ландшафте базы данных Azure, предложение с одним сервером должно быть отставлено и обновлено с помощью новой архитектуры — База данных Azure для MySQL гибкий сервер, чтобы повысить эффективность платформы базы данных с открытым исходным кодом Azure.
В. Почему мне предлагается выполнить миграцию на База данных Azure для MySQL — гибкий сервер?
А.База данных Azure для MySQL. Гибкий сервер — это оптимальная платформа для выполнения всех рабочих нагрузок MySQL в Azure. Экономичное предложение также обеспечивает лучшую производительность на всех уровнях служб и больше способов управления затратами, что делает аварийное восстановление более дешевым и быстрым:
- способов оптимизировать затраты стало больше, что также включает в себя поддержку параметров вычислительных ресурсов с увеличивающейся производительностью.
- Повышена производительность критически важных для бизнеса рабочих нагрузок, требующих низкой задержки, высокого параллелизма, быстрой отработки отказа и высокой масштабируемости.
- Время доступности оптимизировано за счет возможности настроить сервер горячей замены в той же или в другой зоне, а также пользоваться периодом времени для планового обслуживания сервера, который составляет один час.
В. Как скоро необходимо перенести один сервер на гибкий сервер?
А. База данных Azure для MySQL — отдельный сервер запланирован на выход на пенсию 16 сентября 2024 г., поэтому настоятельно рекомендуется перенести один сервер на гибкий сервер в самые ранние возможности, чтобы обеспечить достаточное время для выполнения жизненного цикла миграции, применить преимущества, предлагаемые гибким сервером, и обеспечить непрерывность вашего бизнеса.
В. Что происходит с существующими База данных Azure для MySQL экземплярами одного сервера?
А. Существующие База данных Azure для MySQL рабочие нагрузки одного сервера продолжают функционировать как раньше и будут официально поддерживаться до даты заката. Однако новые обновления не выпускаются для одного сервера и настоятельно советуем начать миграцию на База данных Azure для MySQL гибкий сервер. Поместите дату заката, экземпляр отдельного сервера вместе с файлами данных будет принудительно перенесен в соответствующий гибкий экземпляр сервера поэтапно.
В. Можно ли продолжить работу одного сервера за пределами даты заката?
А. К сожалению, мы не планируем поддерживать единый сервер за пределами даты заката 16 сентября 2024 г. и поэтому настоятельно рекомендуем начать планирование миграции как можно скорее. Поместите дату заката, экземпляр отдельного сервера вместе с файлами данных будет принудительно перенесен в соответствующий гибкий экземпляр сервера поэтапно. Это может привести к ограниченной доступности функций, так как некоторые расширенные функциональные возможности не могут быть принудительно перенесены без ввода клиентов в экземпляр гибкого сервера. Узнайте больше о шагах по перенастройке таких функций после принудительной миграции, чтобы свести к минимуму потенциальное влияние здесь. Если сервер находится в регионе, где База данных Azure для MySQL — гибкий сервер не поддерживается, то после даты заката экземпляр одного сервера будет доступен с ограниченными операциями для доступа к данным и возможности миграции на гибкий сервер.
В. Одиночный сервер развертывается в регионе, который не поддерживает гибкий сервер. Что произойдет с датой заката сервера после заката? А. Если сервер находится в регионе, где База данных Azure для MySQL — гибкий сервер не поддерживается, то после даты заката экземпляр одного сервера будет доступен с ограниченными операциями для доступа к данным и возможности миграции на гибкий сервер. Настоятельно рекомендуется использовать один из следующих вариантов миграции до даты заката, чтобы избежать сбоев в непрерывности бизнес-процессов.
- Используйте Azure DMS, чтобы выполнить миграцию между регионами на гибкий сервер в подходящем регионе Azure.
- Миграция на сервер MySQL, размещенный на виртуальной машине в регионе, если вы не сможете изменить регионы из-за проблем с соответствием требованиям.
В. Дата заката после потери данных на одном сервере? А. Нет, для экземпляра одного сервера не возникает никаких потерь данных. После окончания срока действия экземпляр одного сервера вместе с файлами данных будет принудительно перенесен в соответствующий экземпляр гибкого сервера. Если сервер находится в регионе, где База данных Azure для MySQL — гибкий сервер не поддерживается, то после даты заката экземпляр одного сервера будет доступен с ограниченными операциями для доступа к данным и возможности миграции на гибкий сервер в соответствующем регионе.
В. Что делать после объявления о прекращении поддержки отдельного сервера, если мне по-прежнему нужно создать новый отдельный сервер для удовлетворения бизнес-потребностей?
А. В рамках этого выхода на пенсию мы больше не будем поддерживать создание новых экземпляров одного сервера с портал 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. Если у вас есть план поддержки и вам нужна техническая помощь, создайте запрос на поддержку:
- В поле "Сводка" введите описание проблемы.
- В качестве типа проблемы укажите Техническая.
- В качестве подписки выберите свою подписку.
- В качестве службы выберите Мои приложения.
- Для типа службы выберите База данных Azure для MySQL один сервер.
- Для ресурса выберите ресурс.
- Для типа проблемы выберите "Миграция".
- Для подтипа проблемы выберите "Миграция с одного на гибкий сервер"
Ознакомьтесь с часто задаваемыми вопросами об использовании Azure Database Migration Service (классической) для База данных Azure для MySQL — миграции с одним сервером на гибкий сервер.
Мы знаем, что миграция служб может быть разочарованием, и мы заранее извиняемся за любые неудобства, которые могут привести к вам. Вы можете выбрать оптимальный сценарий для вас и вашей среды.