Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
Grâce à Azure Database pour MySQL serveur flexible, vous pouvez configurer la haute disponibilité avec le basculement automatique. Cette solution garantit que les défaillances ne provoquent jamais de perte de données validées et que la base de données n’est pas un point de défaillance unique dans votre architecture logicielle. Lorsque vous configurez la haute disponibilité, le serveur flexible provisionne et gère automatiquement un réplica Hyper-V de secours. Vous payez le calcul et le stockage provisionnés pour les réplicas principaux et secondaires. Deux modèles architecturaux à haute disponibilité sont disponibles :
Haute disponibilité avec redondance entre zones. Cette option fournit une isolation complète et une redondance de l’infrastructure sur plusieurs zones de disponibilité. Il offre le niveau de disponibilité le plus élevé, mais il vous oblige à configurer la redondance des applications entre les zones. Choisissez une haute disponibilité redondante interzone lorsque vous souhaitez vous protéger contre toute défaillance de l’infrastructure dans la zone de disponibilité et lorsque la latence entre la zone de disponibilité est acceptable. Vous pouvez activer la haute disponibilité redondante interzone uniquement lorsque vous créez le serveur. La haute disponibilité redondante interzone est disponible dans un sous-ensemble de régions Azure où la région prend en charge plusieurs zones de disponibilité et où des partages de fichiers Premium redondants interzone sont disponibles.
Haute disponibilité redondante locale. Cette option fournit une redondance d’infrastructure avec une latence réseau inférieure, car les serveurs principaux et de secours se trouvent dans la même zone de disponibilité. Il offre une haute disponibilité sans avoir à configurer la redondance des applications entre les zones. Choisissez une haute disponibilité locale redondante lorsque vous souhaitez atteindre le niveau de disponibilité le plus élevé au sein d’une seule zone de disponibilité avec la latence réseau la plus faible. La haute disponibilité à redondance locale est disponible dans toutes les régions Azure où l'on peut utiliser le serveur flexible Azure Database for MySQL.
Architecture haute disponibilité redondante interzone
Lorsque vous déployez un serveur avec une haute disponibilité redondante interzone, Azure crée deux serveurs :
- Un serveur principal dans une zone de disponibilité.
- Un serveur réplica de secours dans une autre zone de disponibilité de la même région Azure. Le serveur réplica de secours a la même configuration que le serveur principal, notamment le niveau de calcul, la taille de calcul, la taille de storage et la configuration réseau.
Vous pouvez choisir la zone de disponibilité pour le serveur principal et le réplica de secours. Le placement du serveur principal et du serveur de secours dans la même zone réduit la latence, tandis que le placement dans différentes zones vous permet de préparer les situations de récupération d’urgence et les scénarios de mise hors zone.
Les fichiers de données et les fichiers journaux sont hébergés dans un stockage redondant interzone (ZRS). Le serveur de secours lit et relit en continu les fichiers journaux à partir du compte de stockage du serveur principal, qui protège la réplication au niveau du stockage.
Si un basculement se produit :
- Le réplica de secours s’active.
- Les fichiers journaux binaires du serveur principal continuent à s’appliquer au serveur de secours pour le mettre en ligne à la dernière transaction validée sur le serveur principal.
Les journaux dans le stockage redondant interzone sont accessibles même lorsque le serveur principal n’est pas disponible. Cette disponibilité permet de garantir qu’il n’y a aucune perte de données. Une fois le réplica de secours activé et les journaux binaires appliqués, le serveur de réplica de secours actuel prend le rôle du serveur principal. Mises à jour DNS afin que les connexions clientes soient directes vers le nouveau serveur principal lorsque le client se reconnecte. Le basculement est entièrement transparent depuis l’application cliente et ne nécessite aucune action de votre part. La solution haute disponibilité rétablit ensuite l’ancien serveur principal dès que possible et en fait le serveur de secours.
Vous utilisez le nom du serveur de base de données pour connecter des applications au serveur principal. La solution n’expose pas les informations de réplica de secours pour un accès direct. Les validations et les écritures sont acceptées après que les fichiers journaux ont été vidés sur le stockage redondant interzone du serveur principal. En raison de la technologie de réplication de synchronisation utilisée dans ZRS storage, vous pouvez vous attendre à une latence accrue de 5 à 10 % pour les écritures et validations d’applications.
Le serveur de base de données principal sauvegarde automatiquement les captures instantanées et les sauvegardes de journaux sur un stockage redondant entre zones.
Architecture de redondance locale à haute disponibilité
Lorsque vous déployez un serveur avec haute disponibilité redondante locale, vous créez deux serveurs dans la même zone :
- Un serveur principal
- Un serveur réplica de secours qui a la même configuration que le serveur principal (niveau de calcul, taille de calcul, taille de storage et configuration réseau)
Le serveur de secours fournit une redondance d’infrastructure à l’aide d’une machine virtuelle distincte (calcul). Cette redondance réduit le temps de basculement et la latence du réseau entre l’application et le serveur de base de données en raison de la colocalisation.
Les fichiers de données et les fichiers journaux sont hébergés dans un stockage localement redondant (LRS). Le serveur de secours lit et relit en continu les fichiers journaux à partir du compte de stockage du serveur principal, qui est protégé par la réplication au niveau du stockage.
Si un basculement se produit :
- Le réplica de secours s’active.
- Les fichiers journaux binaires du serveur principal continuent à s’appliquer au serveur de secours pour le mettre en ligne à la dernière transaction validée sur le serveur principal.
Les journaux dans le stockage localement redondant sont accessibles même lorsque le serveur principal n’est pas disponible. Cette disponibilité permet de garantir qu’il n’y a aucune perte de données. Une fois le réplica de secours activé et les journaux binaires appliqués, le réplica de secours actif prend les rôles du serveur principal. Le DNS est mis à jour pour rediriger les connexions vers le nouveau serveur principal lorsque le client se reconnecte. Le basculement est entièrement transparent depuis l’application cliente et ne nécessite aucune action de votre part. La solution haute disponibilité rétablit ensuite l’ancien serveur principal dès que possible et en fait le serveur de secours.
Le nom du serveur de base de données connecte les applications au serveur principal. Les informations du réplica de secours ne sont pas exposées à un accès direct. Les validations et les écritures sont acceptées après que les fichiers journaux ont été vidés sur le stockage localement redondant du serveur principal. Étant donné que les réplicas primaire et de secours se trouvent dans la même zone, il y a moins de décalage de réplication et une latence plus faible entre le serveur d’application et le serveur de base de données. La configuration localement redondante ne fournit pas de haute disponibilité lorsque les infrastructures dépendantes sont en panne pour la zone de disponibilité spécifique. Il y a un temps d’arrêt jusqu’à ce que tous les services dépendants soient de nouveau en ligne pour cette zone de disponibilité.
Le serveur de base de données principal sauvegarde automatiquement les captures instantanées et les sauvegardes de journal dans des storage localement redondantes.
Remarque
Pour la haute disponibilité redondante interzone et redondante locale :
- Si une défaillance se produit, le temps nécessaire pour que le réplica de secours prenne le rôle du réplica principal dépend du temps nécessaire à la relecture du journal binaire du compte de stockage principal vers le serveur de secours. Pour réduire le temps de basculement, utilisez des clés primaires sur toutes les tables. Les temps de basculement prennent généralement entre 60 et 120 secondes.
- Le serveur de secours n’est pas disponible pour les opérations de lecture ou d’écriture. Il s’agit d’un remplacement passif pour permettre un basculement rapide.
- Utilisez toujours un nom de domaine complet (FQDN) pour vous connecter à votre serveur primaire. Évitez d’utiliser une adresse IP pour vous connecter. Si un basculement se produit, une fois les rôles de serveur principal et de secours basculés, un enregistrement DNS A peut changer. Cette modification empêche l’application de se connecter au nouveau serveur principal si une adresse IP est utilisée dans le connection string.
Migrer d’un serveur existant vers un serveur redondant interzone
Si vous avez initialement approvisionné votre serveur Azure Database for MySQL en tant que serveur non haute disponibilité, vous pouvez l’activer pour l’architecture haute disponibilité localement redondante. Toutefois, si vous souhaitez l’activer pour l’architecture haute disponibilité redondante interzone, vous devez créer un serveur avec votre configuration souhaitée et la migrer en procédant comme suit :
Créez un serveur avec une haute disponibilité redondante interzone activée en suivant les instructions de votre outil de déploiement préféré :
Migrez votre charge de travail vers le nouveau serveur en suivant l’une de ces approches. Selon l’approche de migration, un temps d’arrêt peut être nécessaire.
Approches de migration hors connexion : Si votre application peut se permettre un temps d’arrêt, les migrations hors connexion sont toujours le choix préféré, car elles sont simples et faciles à exécuter. Avec une migration hors connexion, le serveur source est mis hors connexion et un vidage et une restauration des bases de données sont effectuées sur le serveur cible. Cette option nécessite le plus de temps d’arrêt. 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.
Service de Migration de Données (DMS) : Pour savoir comment utiliser DMS, consultez Migrer de MySQL vers Azure Database for MySQL hors connexion avec DMS via le portail Azure.
Bien que le tutoriel décrit les étapes de migration d'un serveur MySQL local vers Azure Database for MySQL, vous pouvez utiliser la même procédure pour migrer des données d'un serveur Azure Database for MySQL qui ne prend pas en charge les zones de disponibilité vers une autre qui prend en charge les zones de disponibilité.
Outils open source : Vous pouvez migrer hors connexion à l’aide d’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 pour migrer Azure Database for MySQL - Serveur unique vers un serveur flexible. Bien que le didacticiel décrit les étapes de migration de Azure serveur unique MySQL vers un serveur flexible, vous pouvez utiliser la même procédure pour migrer des données d'un serveur flexible Azure Database for MySQL qui ne prend pas en charge les zones de disponibilité vers une autre qui prend en charge les zones de disponibilité.
Approches de migration en ligne : Les migrations en ligne réduisent le temps d’arrêt de l’application. Le serveur source autorise les mises à jour et la solution de migration réplique les modifications en cours entre le serveur source et le serveur cible, ainsi que le vidage initial et la restauration sur la cible. Toutefois, ces approches sont plus complexes à implémenter qu’une migration hors connexion.
Data Migration Service (DMS) : Pour savoir comment utiliser DMS, consultez Migrate de MySQL à Azure Database for MySQL en ligne à l’aide de DMS via le portail Azure.
Bien que le tutoriel décrit les étapes de migration d'un serveur MySQL local vers Azure Database for MySQL, vous pouvez utiliser la même procédure pour migrer des données d'un serveur Azure Database for MySQL qui ne prend pas en charge les zones de disponibilité vers une autre qui prend en charge les zones de disponibilité.
Outils open source : Vous pouvez utiliser une combinaison d’outils open source tels que mydumper/myloader avec la réplication de données entrantes.
Processus de basculement
Pendant le processus de basculement dans Azure Database pour MySQL, le système passe automatiquement du serveur principal au réplica de secours. Ce commutateur garantit la continuité et réduit les temps d’arrêt. Lorsque le système détecte un échec, il promeut le réplica de secours pour devenir le nouveau serveur principal. Le système applique les fichiers journaux binaires du serveur principal d’origine au réplica de secours. Ce processus synchronise le réplica de secours avec la dernière transaction validée et garantit aucune perte de données. Cette transition transparente permet de maintenir une haute disponibilité et une fiabilité élevée pour le service de base de données.
Remarque
Pour réduire la dépendance du temps de basculement sur la mise en cache DNS, à compter d'octobre 2025, tous les nouveaux serveurs à haute disponibilité créés avec accès public ou lien privé adopteront la nouvelle architecture avec un SLB dédié pour chaque serveur à haute disponibilité. En gérant le chemin du trafic de données MySQL, SLB élimine le besoin de modifications DNS pendant le basculement et améliore considérablement les performances de basculement. Il redirige le trafic vers l’instance principale actuelle pendant le basculement à l’aide de règles d’équilibrage de charge. Les serveurs existants avec des access publics ou des private link migrent progressivement pour réduire l’impact. Les clients qui préfèrent la migration anticipée peuvent désactiver et réactiver la haute disponibilité. Cette fonctionnalité n'est pas prise en charge pour les serveurs utilisant des accès privés avec l'intégration au réseau virtuel.
Planifié : Basculement forcé
Le basculement forcé d’Azure Database pour MySQL serveur flexible vous permet de forcer manuellement un basculement. Cette fonctionnalité vous permet de tester les fonctionnalités avec vos scénarios d’application et de vous aider à vous préparer aux pannes.
Le basculement forcé déclenche un basculement qui active le réplica en attente pour devenir le serveur primaire utilisant le même nom de serveur de base de données et mettant à jour l’enregistrement DNS. Le serveur principal d’origine redémarre et bascule vers le réplica de secours. Les connexions clientes se déconnectent et doivent se reconnecter pour reprendre leurs opérations.
Le temps de basculement global dépend de la charge de travail actuelle et du dernier point de contrôle. En général, il faut entre 60 et 120 secondes.
Remarque
Un événement Azure Resource Health est généré pendant un basculement planifié. L’événement représente l’heure de basculement pendant laquelle le serveur n’est pas disponible. Vous pouvez voir les événements déclenchés lorsqu’ils sont sélectionnés sur Resource Health dans le volet gauche. The status represents user-initiated or manual failover as Indisponible et marqué comme Planifié. Par exemple, Une opération de basculement a été déclenchée par un utilisateur autorisé (Planifié). Si votre ressource reste dans cet état pendant une période prolongée, ouvrez un ticket support et nous vous aidons.
Non planifié : Basculement automatique
Un temps d’arrêt de service non planifié peut se produire en raison de bogues logiciels ou d’erreurs d’infrastructure, telles que le calcul, le réseau ou les défaillances de storage. Les pannes de courant peuvent également affecter la disponibilité de la base de données. Si la base de données devient indisponible, la réplication vers le réplica de secours s’arrête et le réplica de secours devient la base de données principale. Les mises à jour DNS se produisent et les clients se reconnectent au serveur de base de données, ce qui reprend leurs opérations.
Le temps de basculement global est généralement compris entre 60 et 120 secondes. Toutefois, selon l’activité du serveur de base de données principal au moment du basculement (par exemple, les transactions volumineuses et le temps de récupération), le basculement peut prendre plus de temps.
Remarque
Un basculement non planifié génère un événement Resource Health. L’événement représente l’heure de basculement lorsque le serveur n’est pas disponible. Vous pouvez voir les événements déclenchés lorsque vous sélectionnez Resource Health dans le volet gauche. Le basculement automatique affiche un statut Indisponible et est marqué commeNon planifié.
Par exemple, Non disponible : une opération de basculement a été déclenchée automatiquement (non planifiée). Si votre ressource reste dans cet état pendant longtemps, ouvrez un ticket support et nous vous aidons.
Fonctionnement de la détection du basculement automatique dans les serveurs activés pour la haute disponibilité
Le serveur principal et le serveur secondaire ont chacun deux points de terminaison réseau :
- Point de terminaison client : les clients connectent et exécutent des requêtes sur l’instance à l’aide de ce point de terminaison.
- Point de terminaison de gestion : utilisé en interne pour les communications de service aux composants de gestion et pour se connecter au serveur principal storage.
Le composant moniteur d’intégrité effectue en permanence les vérifications suivantes :
- Le moniteur envoie des requêtes ping au point de terminaison du réseau de gestion du nœud. Si cette vérification échoue deux fois dans une ligne, elle déclenche une opération de basculement automatique. Ce contrôle d’intégrité traite des scénarios tels que l’indisponibilité de nœud ou la non-réponse en raison de problèmes de système d’exploitation, de problèmes de mise en réseau entre les composants de gestion et les nœuds, et de problèmes similaires.
- Le moniteur exécute une requête simple sur l’instance. Si les requêtes ne parviennent pas à s’exécuter, le basculement automatique se déclenche. Ce contrôle d’intégrité traite des scénarios tels que les plantages, arrêts ou blocages du démon MySQL, ainsi que les problèmes de stockage de back-end et les problèmes similaires.
Remarque
Le contrôle d'intégrité ne surveille pas les problèmes de mise en réseau entre l'application et le point de terminaison de mise en réseau du client (access privé/public). Ces problèmes peuvent se produire dans le chemin de mise en réseau, sur le point de terminaison ou dans les problèmes DNS côté client. Si vous utilisez l’accès privé, assurez-vous que les règles de groupe de sécurité réseau pour le réseau virtuel ne bloquent pas la communication avec le point de terminaison réseau du client d’instance sur le port 3306. Pour les access publiques, assurez-vous que les règles de pare-feu sont définies et que le trafic réseau est autorisé sur le port 3306 (si le chemin d’accès réseau comporte d’autres pare-feu). Vous devez également prendre en charge la résolution DNS côté application cliente.
Superviser la haute disponibilité
Pour vérifier l’état de la configuration de haute disponibilité du serveur, utilisez l’état de haute disponibilité dans le volet haute disponibilité du serveur dans le portail.
| État | Description |
|---|---|
| NotEnabled | La haute disponibilité n’est pas activée. |
| RéplicationDesDonnées | Le serveur de secours se synchronise avec le serveur principal pendant l’approvisionnement de serveurs à haute disponibilité ou lorsque vous activez l’option haute disponibilité. |
| FailingOver | Le serveur de base de données bascule du serveur principal vers le serveur de secours. |
| sain | L’option haute disponibilité est activée. |
| Suppression de Standby | Le processus de suppression est en cours lorsque vous désactivez l’option haute disponibilité. |
Pour surveiller l’intégrité du serveur de haute disponibilité, utilisez les métriques suivantes.
| Nom d’affichage de la métrique | Métrique | Unité | Description |
|---|---|---|---|
État de la haute disponibilité IO |
ha_io_running | État | L’état de la haute disponibilité IO indique l’état de la réplication haute disponibilité. La valeur de la mesure est 1 si le thread d’E/S est en cours d’exécution et 0 si ce n’est pas le cas. |
| État SQL de la haute disponibilité | ha_sql_running | État | L’état SQL haute disponibilité indique l’état de la réplication haute disponibilité. La valeur de mesure est 1 si le thread SQL est en cours d’exécution et 0 si ce n’est pas le cas. |
| Décalage de la réplication à haute disponibilité | délai_de_réplication | Secondes | Le délai de réplication représente le nombre de secondes de retard du serveur de secours par rapport à la relecture des transactions reçues par le serveur primaire. |
Limites
Gardez à l’esprit les considérations suivantes lorsque vous utilisez la haute disponibilité :
Vous pouvez configurer la haute disponibilité redondante interzone uniquement lors de la création du serveur.
Le niveau de calcul burstable ne prend pas en charge la haute disponibilité.
Le redémarrage du serveur de base de données principal pour appliquer des modifications de paramètres statiques redémarre également le réplica de secours.
La solution active le mode GTID, car elle utilise GTID. Vérifiez si votre charge de travail présente des restrictions ou des limitations en lien avec la réplication avec GTID.
Remarque
Storage croissance automatique est activée par défaut pour un serveur configuré à haute disponibilité et ne peut pas être désactivé.
Problèmes connus
Azure Database pour MySQL serveur flexible utilise la réplication native de MySQL en arrière-plan. Un problème connu existe dans MySQL Community Edition 8.0 et ultérieur qui peut interrompre la réplication lors de l’exécution d’une opération DELETE multitable qui s’appuie sur des contraintes de clé étrangère avec ON DELETE CASCADE. Ce problème est suivi en tant que bogue MySQL 102586. Par conséquent, lorsque vous activez la haute disponibilité sur Azure Database for MySQL serveur flexible, évitez d’utiliser des suppressions en cascade avec des clés étrangères, car ce modèle peut entraîner des défaillances de réplication et affecter la disponibilité du serveur.
Contrôle d’intégrité
Lorsque vous configurez la haute disponibilité pour Azure Database for MySQL, health Check joue un rôle crucial dans la maintenance de la fiabilité et des performances de votre base de données. Ces vérifications surveillent en permanence l’état et l’intégrité des réplicas principaux et de secours, ce qui permet de détecter rapidement les problèmes. En effectuant le suivi de différentes métriques telles que la réactivité du serveur, le décalage de réplication et l’utilisation des ressources, Health Check permet de s’assurer que les processus de basculement peuvent être exécutés en toute transparence, en réduisant les temps d’arrêt et en empêchant la perte de données. Le contrôle d’intégrité correctement configuré est essentiel pour atteindre le niveau de disponibilité et de résilience souhaité dans la configuration de votre base de données.
Surveiller l’intégrité
Vous pouvez surveiller l’intégrité de votre configuration de haute disponibilité via le portail Azure. Les métriques clés à observer sont les suivantes :
- Réactivité du serveur : indique si le serveur primaire est joignable.
- Délai de réplication : mesure le délai entre les réplicas principal et de secours, pour garantir la cohérence des données.
- Utilisation des ressources : Surveille l’utilisation du processeur, de la mémoire et du stockage pour éviter les goulots d’étranglement.
Fiabilité et résilience
Pour obtenir une vue d’ensemble complète de la fiabilité dans Azure Database pour MySQL, notamment la gestion des pannes temporaires, la résilience des zones de disponibilité, la récupération d’urgence interrégion avec des réplicas en lecture, la sauvegarde et la restauration et la maintenance du service, consultez Fiabilité dans Azure Database pour MySQL.