Migrer MySQL – Serveur flexible vers la prise en charge des zones de disponibilité
Ce guide explique comment migrer MySQL – Serveur flexible de la non-prise en charge des zones de disponibilité vers la prise en charge des zones de disponibilité.
Vous pouvez configurer une instance Azure Database pour MySQL Flexible Server pour utiliser l’un des deux modèles architecturaux haute disponibilité (HA) :
Architecture haute disponibilité de zone identique (zonale). Cette option est préférable pour la redondance de l’infrastructure avec une latence réseau inférieure, car le serveur principal et le serveur de secours se trouveront dans la même zone de disponibilité. Elle offre une haute disponibilité sans qu’il soit nécessaire de configurer la redondance des applications entre les zones. La haute disponibilité dans la même zone est préférable quand vous voulez obtenir le niveau de disponibilité le plus élevé au sein d’une même zone de disponibilité avec la latence réseau la plus faible. La haute disponibilité dans la même zone est disponible dans toutes les régions Azure où il est possible d’utiliser un serveur flexible Azure Database pour MySQL. Pour en savoir plus sur l’architecture haute disponibilité de zone identique, consultez Architecture haute disponibilité de zone identique.
Architecture à haute disponibilité redondante interzone. Cette option est recommandée pour une isolation et une redondance complètes de l’infrastructure sur plusieurs zones de disponibilité. Elle offre le niveau de disponibilité le plus élevé, mais vous oblige à configurer la redondance des applications entre zones. La haute disponibilité redondante interzone est préférable quand vous voulez obtenir le niveau de disponibilité le plus élevé en cas de défaillance de l’infrastructure dans la zone de disponibilité et où la latence dans la zone de disponibilité est acceptable. Elle ne peut être activée que lors de la création du serveur. La haute disponibilité redondante interzone est disponible dans un sous-ensemble de régions Azure, où chaque région prend en charge plusieurs zones de disponibilité et où des partages de fichiers Premium redondants interzone sont disponibles. Pour en savoir plus sur l’architecture haute disponibilité redondante interzone, consultez Architecture haute disponibilité redondante interzone.
Pour migrer votre charge de travail existante de la haute disponibilité zonale (haute disponibilité interzone) vers la haute disponibilité redondante interzone, vous devez effectuer les opérations suivantes :
Déployez et configurez un nouveau serveur configuré pour la haute disponibilité redondante interzone.
Suivez les instructions de migration de ce document pour migrer vos ressources vers votre nouveau serveur.
Prérequis
Pour migrer vers une prise en charge des zones de disponibilité :
Vous aurez besoin d’au moins l’un des deux serveurs suivants :
Un serveur source exécutant Azure Database pour MySQL Serveur flexible dans une région qui ne prend pas en charge les zones de disponibilité.
Un serveur flexible Azure Database pour MySQL qui n’a pas été activé pour la haute disponibilité au moment de la création.
Important
Si vous avez initialement approvisionné votre instance Azure Database pour MySQL Serveur flexible en tant que serveur non haute disponibilité, vous pouvez simplement l’activer pour une architecture haute disponibilité de même zone. Toutefois, si vous souhaitez l’activer pour l’architecture haute disponibilité redondante interzone, vous devez implémenter l’une des options de migration disponibles répertoriées dans cet article.
Vous devez créer un serveur cible exécutant Azure Database pour MySQL Serveur flexible dans une région qui prend en charge les zones de disponibilité. Pour plus d’informations sur la création d’une instance Azure Database pour MySQL Serveur flexible, consultez Utiliser le Portail Azure pour créer un serveur flexible Azure Database pour MySQL. Assurez-vous que le serveur créé est configuré pour la redondance de zone en activant la haute disponibilité et en sélectionnant l’option Redondant interzone.
Conseil
Si vous souhaitez avoir la flexibilité de basculer entre une haute disponibilité zonale (de même zone) et une haute disponibilité redondante interzone à l’avenir, vous pouvez approvisionner votre instance Azure Database pour MySQL Serveur flexible avec une haute disponibilité redondante interzone activée pendant la création du serveur. Une fois le serveur approvisionné, vous pouvez désactiver la haute disponibilité.
Exigences en matière de temps d’arrêt
Les migrations peuvent être classées en deux catégories : en ligne et hors connexion :
• Migration hors connexion. Si votre application peut se permettre un certain temps d’arrêt, les migrations hors connexion sont toujours recommandées car elles sont simples et faciles à exécuter. Dans le cas d’une migration hors connexion, le serveur source est mis hors connexion, puis une copie de sauvegarde et une restauration des bases de données sont effectuées sur le serveur cible. Cette option nécessite le temps d’arrêt le plus long. La durée du temps d’arrêt est déterminée par le temps nécessaire pour effectuer la restauration sur le serveur cible.
• Migration en ligne. Cette option a un temps d’arrêt minimal et est le meilleur choix si vous souhaitez moins de temps d’arrêt. Le serveur source permet les mises à jour et la solution de migration se charge de la réplication des modifications en cours entre le serveur source et le serveur cible, ainsi que des opérations initiales de copie de sauvegarde et de restauration sur la cible.
Option de migration 1 : migration hors connexion
Vous pouvez migrer d’une instance Azure Database pour serveur flexible vers une autre à l’aide de l’un des outils suivants. Ces deux options nécessitent un temps d’arrêt.
Data Migration Service (DMS). Pour savoir comment migrer un serveur flexible MySQL vers un autre avec DMS, consultez Migrer Azure Database pour MySQL – Serveur unique vers un serveur flexible hors connexion à l’aide de DMS via le Portail Azure. Bien que le tutoriel décrit les étapes de migration d’un serveur unique Azure MySQL vers un serveur flexible, vous pouvez utiliser la même procédure pour migrer des données d’un serveur flexible Azure Database pour MySQL qui ne prend pas en charge les zones de disponibilité vers un autre qui les prend en charge.
Outils open source. Vous pouvez migrer hors connexion avec des outils open source, tels que MySQL Workbench, mydumper/myloader ou mysqldump pour sauvegarder et restaurer la base de données. Pour plus d’informations sur l’utilisation de ces outils, consultez Options de migration d’Azure Database pour MySQL – Serveur unique vers Serveur flexible. Bien que le tutoriel décrit les étapes de migration d’un serveur unique Azure MySQL vers un serveur flexible, vous pouvez utiliser la même procédure pour migrer des données d’un serveur flexible Azure Database pour MySQL qui ne prend pas en charge les zones de disponibilité vers un autre qui les prend en charge.
Option de migration 2 : migration en ligne
Vous pouvez migrer d’une instance Azure Database pour serveur flexible vers une autre avec un temps d’arrêt minimal de vos applications à l’aide de l’un des outils suivants :
Data Migration Service (DMS). Pour savoir comment migrer un serveur flexible MySQL vers un autre avec DMS, consultez Migrer Azure Database pour MySQL – Serveur unique vers Serveur flexible en ligne à l’aide de DMS via le Portail Azure. Bien que le tutoriel décrit les étapes de migration d’un serveur unique Azure MySQL vers un serveur flexible, vous pouvez utiliser la même procédure pour migrer des données d’un serveur flexible Azure Database pour MySQL qui ne prend pas en charge les zones de disponibilité vers un autre qui les prend en charge.
Outils open source. Vous pouvez utiliser une combinaison d’outils open source tels que mydumper/myloader avec la réplication des données entrantes. Pour savoir comment configurer la réplication des données entrantes, consultez Comment configurer la réplication de données entrantes Azure Database pour MySQL.
Important
La réplication des données entrantes n’est pas prise en charge pour les serveurs haute disponibilité. La solution de contournement consiste à approvisionner le serveur cible avec la haute disponibilité redondante interzone, puis à désactiver la haute disponibilité avant de configurer la réplication des données entrantes. Une fois la réplication terminée, activez à nouveau la haute disponibilité redondante interzone sur le serveur cible.
Étapes suivantes
Pour en savoir plus :