Перенос MySQL — гибкий сервер в поддержку зоны доступности
В этом руководстве описывается, как перенести MySQL — гибкий сервер из поддержки зоны доступности в поддержку зоны доступности.
Вы можете настроить гибкий сервер База данных Azure для MySQL для использования одной из двух моделей архитектуры высокого уровня доступности.
Архитектура однозоны высокого уровня доступности (зональная). Этот параметр предпочтителен для избыточности инфраструктуры с меньшей задержкой в сети, поскольку и главный, и резервный серверы будут находиться в одной зоне доступности. Он обеспечивает высокий уровень доступности без настройки избыточности приложений в разных зонах. Высокий уровень доступности в одной зоне предпочтителен, если требуется достичь высокого уровня доступности в пределах одной зоны доступности с наименьшей задержкой в сети. Высокий уровень доступности в одной зоне доступен во всех регионах Azure, где можно использовать гибкий сервер Базы данных Azure для MySQL. Дополнительные сведения об архитектуре с одинаковыми зонами высокого уровня доступности см. в разделе "Архитектура с одинаковым уровнем доступности".
Архитектура высокой доступности, избыточной между зонами. Этот параметр предпочтителен для полной изоляции и избыточности инфраструктуры в нескольких зонах доступности. Он обеспечивает высочайший уровень доступности, но требует настройки избыточности приложений в разных зонах. Высокий уровень доступности с избыточностью между зонами предпочтителен, если требуется достичь наивысшего уровня доступности при любых сбоях инфраструктуры в зоне доступности, и когда допустима задержка в зоне доступности. Он может быть включен только при создании сервера. Высокий уровень доступности, избыточный между зонами, доступен в подмножестве регионов Azure, где регион поддерживает несколько зон доступности и общих папок premium, избыточных между зонами. Дополнительные сведения об архитектуре, избыточной между зонами, см. в статье об архитектуре, избыточной между зонами.
Чтобы перенести существующую рабочую нагрузку из зонального (однозонного высокого уровня доступности) в избыточное между зонами высокого уровня доступности, вам потребуется выполнить следующие действия.
Разверните и настройте новый сервер, настроенный для избыточного между зонами высокого уровня доступности.
Следуйте инструкциям по миграции в этом документе, чтобы переместить ресурсы на новый сервер.
Необходимые компоненты
Чтобы выполнить миграцию в службу поддержки зоны доступности, выполните приведенные действия.
Вам потребуется по крайней мере один из следующих двух серверов:
Исходный сервер, на котором выполняется База данных Azure для MySQL гибкий сервер в регионе, который не поддерживает зоны доступности.
Гибкий сервер База данных Azure для MySQL, который не был включен для высокой доступности во время создания.
Важно!
Если вы изначально подготовили База данных Azure для MySQL гибкий сервер в качестве сервера, отличного от высокого уровня доступности, его можно просто включить для архитектуры высокого уровня доступности в одной зоне. Однако если вы хотите включить его для архитектуры, избыточной между зонами, необходимо реализовать один из доступных вариантов миграции, перечисленных в этой статье.
Вам потребуется создать целевой сервер, на котором выполняется База данных Azure для MySQL гибкий сервер в регионе, поддерживающем зоны доступности. Дополнительные сведения о создании гибкого сервера База данных Azure для MySQL см. в статье "Использование портал Azure для создания гибкого сервера База данных Azure для MySQL". Убедитесь, что созданный сервер настроен для избыточности зоны, включив высокий уровень доступности и выбрав параметр "Избыточность зоны".
Совет
Если вы хотите обеспечить гибкость перемещения между зональными (одинаковыми зонами) и избыточной между зонами высокой доступности в будущем, вы можете подготовить гибкий сервер База данных Azure для MySQL с поддержкой высокой доступности, избыточной между зонами, во время создания сервера. После подготовки сервера можно отключить высокий уровень доступности.
Требования к простою
Миграции можно классифицировать как онлайн или в автономном режиме:
• Автономная миграция. Если ваше приложение может позволить себе некоторое время простоя, автономные миграции всегда предпочтительнее, так как они просты и просты в выполнении. При автономной миграции исходный сервер выполняется в автономном режиме, а на целевом сервере выполняется дампа и восстановление баз данных. Для этого параметра потребуется максимальное время простоя. Длительность простоя определяется временем восстановления на целевом сервере.
• Миграция через Интернет. Этот параметр имеет минимальное время простоя и является лучшим вариантом, если требуется меньше простоя. Исходный сервер разрешает обновления, и решение миграции будет заботиться о реплика текущих изменений между исходным и целевым сервером вместе с начальным дампом и восстановлением целевого объекта.
Вариант миграции 1. Автономная миграция
Вы можете перейти из одной базы данных Azure для гибкого сервера в другую с помощью одного из следующих средств. Для обоих этих параметров потребуется простой.
Data Migration Service (DMS). Сведения о переносе гибкого сервера MySQL на другой с помощью DMS см. в статье "Миграция База данных Azure для MySQL — отдельный сервер в гибкий сервер в автономном режиме с помощью DMS через портал Azure". Хотя в руководстве описаны шаги по миграции с одного сервера Azure MySQL на гибкий сервер, можно использовать ту же процедуру для переноса данных с одного База данных Azure для MySQL гибкого сервера, который не поддерживает зоны доступности в другую, которая поддерживает зоны доступности.
Средства с открытым кодом. Вы можете перенести в автономный режим с помощью средств с открытым исходным кодом, таких как MySQL Workbench, mydumper/myloader или mysqldump для резервного копирования и восстановления базы данных. Сведения об использовании этих средств см. в разделе "Параметры миграции База данных Azure для MySQL — один сервер на гибкий сервер". Хотя в руководстве описаны шаги по миграции с одного сервера Azure MySQL на гибкий сервер, можно использовать ту же процедуру для переноса данных с одного База данных Azure для MySQL гибкого сервера, который не поддерживает зоны доступности в другую, которая поддерживает зоны доступности.
Вариант миграции 2. Миграция через Интернет
Вы можете перенести одну базу данных Azure для гибкого сервера на другой с минимальным временем простоя в приложения с помощью одного из следующих средств:
Data Migration Service (DMS). Сведения о переносе гибкого сервера MySQL на другой с помощью DMS см. в статье "Миграция База данных Azure для MySQL — отдельный сервер в гибкий сервер через интернет с помощью DMS через портал Azure". Хотя в руководстве описаны шаги по миграции с одного сервера Azure MySQL на гибкий сервер, можно использовать ту же процедуру для переноса данных с одного База данных Azure для MySQL гибкого сервера, который не поддерживает зоны доступности в другую, которая поддерживает зоны доступности.
Средства с открытым кодом. Вы можете использовать сочетание средств с открытым кодом, таких как mydumper/myloader, вместе с реплика data-in. Сведения о настройке репликации данных см. в статье "Настройка База данных Azure для MySQL репликации данных".
Важно!
Репликация данных не поддерживается для серверов с поддержкой высокой доступности. Обходной путь — подготовить целевой сервер с избыточной между зонами высокой доступности, а затем отключить высокий уровень доступности перед настройкой репликации данных. После завершения реплика включения избыточной между зонами высокой доступности снова на целевом сервере.
Следующие шаги
См. также: