Concepts de haute disponibilité dans le serveur flexible Azure Database pour MySQL

S’APPLIQUE À : Azure Database pour MySQL - Serveur flexible

Le serveur flexible Azure Database pour MySQL permet de configurer la haute disponibilité avec le basculement automatique. La solution haute disponibilité est conçue pour éviter toute perte de données en raison de défaillances, et que la base de données devienne un point de défaillance unique dans votre architecture logicielle. Quand la haute disponibilité est configurée, le serveur flexible provisionne et gère automatiquement un réplica de secours. Le calcul et le stockage provisionnés sont facturés pour le réplica principal et le réplica secondaire. Deux modèles d'architecture à haute disponibilité sont disponibles :

• 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.

• Haute disponibilité dans la même zone. 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.

Architecture à haute disponibilité redondante interzone

Lorsque vous déployez un serveur avec une haute disponibilité redondante interzone, deux serveurs sont créés :

• Un serveur principal dans une zone de disponibilité.
• Un serveur réplica de secours ayant la même configuration que le serveur primaire (niveau de calcul, taille du calcul, taille du stockage et configuration du réseau) dans une autre zone de disponibilité de la même région Azure.

Vous pouvez choisir la zone de disponibilité pour le réplica principal et le réplica de secours. Le fait de placer les serveurs de base de données de secours et les applications de secours dans la même zone réduit la latence. Cela vous permet également de mieux vous préparer à des situations de récupération d’urgence et des scénarios de « zone indisponible ».

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 les fichiers journaux en continu à partir du compte de stockage du serveur primaire, qui est protégé par la réplication au niveau du stockage.

En cas de basculement :

• Le réplica de secours est activé.
• Les fichiers journaux binaires du serveur primaire continuent de s’appliquer au serveur de secours pour le mettre en ligne à la dernière transaction validée sur le serveur primaire.

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 réplica de secours actif prend les rôles du serveur principal. Le DNS est mis à jour afin que les connexions client soient dirigées vers le nouveau serveur principal quand 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 est utilisé pour connecter les applications au serveur primaire. 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 redondant interzone du serveur principal. En raison de la technologie de réplication synchrone utilisée pour le stockage redondant interzone, vous pouvez vous attendre à une latence accrue de 5 à 10 % pour les écritures et les validations d’application.

Les sauvegardes automatiques, qu’il s’agisse d’instantanés ou de sauvegardes de fichiers journaux, sont effectuées sur un stockage redondant interzone depuis le serveur de base de données principal.

Architecture de haute disponibilité de zone identique

Lorsque vous déployez un serveur avec la haute disponibilité dans la même zone, deux serveurs sont créés dans la même zone :

• Un serveur principal
• Un serveur réplica de secours ayant la même configuration que le serveur primaire (niveau de calcul, taille du calcul, taille du stockage et configuration du réseau)

Le serveur de secours offre une redondance de l’infrastructure avec 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 les fichiers journaux en continu à partir du compte de stockage du serveur primaire, qui est protégé par la réplication au niveau du stockage.

En cas de basculement :

• Le réplica de secours est activé.
• Les fichiers journaux binaires du serveur primaire continuent de s’appliquer au serveur de secours pour le mettre en ligne à la dernière transaction validée sur le serveur primaire.

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 est utilisé pour connecter les applications au serveur primaire. 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 de haute disponibilité dans la même zone n’offre pas de haute disponibilité quand des infrastructures dépendantes sont défaillantes pour la zone de disponibilité concernée. Il y aura un temps d’arrêt jusqu’à ce que tous les services dépendants reviennent en ligne pour cette zone de disponibilité.

Les sauvegardes automatiques, qu’il s’agisse d’instantanés ou de sauvegardes de fichiers journaux, sont effectuées sur un stockage localement redondant à partir du serveur de base de données principal.

Notes

Tant pour la haute disponibilité redondante interzone que pour la haute disponibilité dans la même zone :

• En cas de défaillance, le temps nécessaire pour que le réplica de secours prenne le rôle de serveur primaire dépend du délai de relecture du journal binaire depuis le compte de stockage principal et vers le serveur de secours. Nous vous recommandons donc d’utiliser des clés primaires sur toutes les tables pour réduire le temps de basculement. Les temps de basculement sont généralement compris 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. En cas de basculement, une fois que les rôles de serveur primaire et de secours sont inversés, un enregistrement DNS A peut changer. Cette modification empêcherait l’application de se connecter au nouveau serveur primaire si une adresse IP est utilisée dans la chaîne de connexion.

Processus de basculement

Planifié : Basculement forcé

Le basculement forcé du serveur flexible Azure Database pour MySQL vous permet de forcer manuellement un basculement. Cette capacité vous permet de tester la fonctionnalité avec les scénarios de votre application et vous permet de vous préparer à des pannes.

Le basculement forcé déclenche un basculement qui active le réplica en attente pour devenir le serveur primaire avec le même nom de serveur de base de données en mettant à jour l’enregistrement DNS. Le serveur principal d’origine est redémarré et devient le réplica de secours. Les connexions des clients sont déconnectées et doivent être reconnectées 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 est supposé que le basculement prend entre 60 et 120 secondes.

Notes

Un événement Azure Resource Health est généré en cas de basculement planifié, représentant le temps de basculement pendant lequel le serveur n’était pas disponible. Les événements déclenchés sont accessibles lorsque vous cliquez sur « Resource Health » dans le volet gauche. Le basculement manuel/initié par l’utilisateur est représenté par l’état « Indisponible » et marqué comme « Planifié ». 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 de support et nous vous allons vous apporter assistance.

Non planifié : Basculement automatique

Les interruptions de service non planifiées peuvent être provoquées par des bogues logiciels ou des erreurs d’infrastructure, comme des défaillances de calcul, de réseau ou de stockage, ou des pannes de courant qui affectent la disponibilité de la base de données. En cas d’indisponibilité de la base de données, la réplication sur le réplica de secours est interrompue, et le réplica de secours est activé pour devenir la base de données primaire. Le système DNS est mis à jour et les clients se reconnectent au serveur de base de données pour reprendre leurs opérations.

Le temps de basculement global doit être compris entre 60 et 120 secondes. Mais, en fonction de l’activité sur le serveur de base de données primaire au moment du basculement, par exemple si des transactions sont volumineuses et que le temps de récupération est long, le basculement peut prendre plus de temps.

Notes

Un événement Azure Resource Health est généré en cas de basculement non planifié, représentant le temps de basculement pendant lequel le serveur n’était pas disponible. Les événements déclenchés sont accessibles lorsque vous cliquez sur « Resource Health » dans le volet gauche. Le basculement automatique est représenté par l’état « Indisponible » et marqué comme « Non planifié ». Exemple : « Indisponible : une opération de basculement a été déclenchée automatiquement (non planifiée) ». Si votre ressource reste dans cet état pendant une période prolongée, ouvrez un ticket de support et nous vous allons vous apporter assistance.

Fonctionnement de la détection du basculement automatique dans les serveurs activés pour la haute disponibilité

Le serveur principal et le serveur secondaire disposent de deux points de terminaison réseau.

• Point de terminaison client : le client se connecte et exécute une requête sur l’instance à l’aide de ce point de terminaison.
• Point de terminaison de gestion : utilisé en interne pour permettre au service de communiquer avec les composants de gestion et se connecter au stockage back-end.

Le composant moniteur d’intégrité effectue continuellement les vérifications suivantes

• Le moniteur effectue des tests ping sur le point de terminaison réseau de gestion des nœuds. Si cette vérification échoue deux fois en continu, l’opération de basculement automatique est déclenchée. Le scénario comme le nœud n’est pas disponible/ne répond pas en raison d’un problème de système d’exploitation, le problème réseau entre les composants de gestion et les nœuds, etc. sera traité par ce contrôle d’intégrité.
• Le moniteur exécute également une requête simple sur l’instance. Si les requêtes ne parviennent pas à s’exécuter, le basculement automatique est déclenché. Les scénarios de type démon MySQL bloqué/arrêté/suspendu, problème de stockage back-end, etc. sont traités par ce contrôle d’intégrité.

Notes

S’il existe un problème de mise en réseau entre l’application et le point de terminaison de mise en réseau client (accès privé/public), dans le chemin de mise en réseau, sur le point de terminaison, ou des problèmes DNS côté client, la vérification d’intégrité ne surveille pas ce scénario. Si vous utilisez l’accès privé, assurez-vous que les règles de groupe de sécurité réseau correspondant au réseau virtuel ne bloquent pas la communication avec le point de terminaison de mise en réseau client de l’instance sur le port 3306. Pour l’accès public, 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). La résolution DNS côté application cliente doit également être prise en charge.

Surveillance de la haute disponibilité

L’état de haute disponibilité, situé dans le volet haute disponibilité du serveur dans le portail, peut être utilisé pour déterminer l’état de configuration de la haute disponibilité du serveur.

État	Description
NotEnabled	La haute disponibilité n’est pas activée.
ReplicatingData	Le serveur de secours est en cours de synchronisation automatique avec le serveur primaire lors de l’approvisionnement du serveur haute disponibilité ou quand l'option de haute disponibilité est activée.
FailingOver	Le serveur de base de données est en cours de basculement, du serveur principal vers le réplica de secours.
Healthy	La haute disponibilité est activée.
RemovingStandby	L’option haute disponibilité est désactivée et le processus de suppression est en cours.

Vous pouvez également utiliser les métriques ci-dessous pour surveiller l’intégrité du serveur haute disponibilité.

Nom d’affichage de la métrique	Métrique	Unité	Description
État des E/S de la haute disponibilité	ha_io_running	State	L’état des E/S de la haute disponibilité indique l’état de la réplication de la haute disponibilité. La valeur de métrique 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	State	L’état SQL de la haute disponibilité indique l’état de la réplication de la haute disponibilité. La valeur de métrique 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é	replication_lag	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

Voici quelques réflexions à prendre en compte lorsque vous utilisez la haute disponibilité :

• La haute disponibilité redondante interzone peut être définie uniquement lors de la création du serveur flexible.
• La haute disponibilité n’est pas prise en charge au niveau du calcul expansible.
• Un redémarrage du serveur de base de données primaire pour récupérer les modifications de paramètres statiques a également pour effet de redémarrer le réplica de secours.
• Le mode GTID est activé parce que la solution HA utilise un identificateur de transaction global (Global Transaction Identifier, GTID). Vérifiez si votre charge de travail présente des restrictions ou des limitations en lien avec la réplication avec GTID.

Notes

Si vous activez la haute disponibilité dans la même zone après la création du serveur, vous devez vous assurer que les paramètres de serveur enforce_gtid_consistency et gtid_mode sont activés avant d’activer la haute disponibilité.

Remarque

La croissance automatique du stockage est activée par défaut pour un serveur configuré à haute disponibilité. Cela ne peut pas être désactivée.

Forum aux questions (FAQ)

• Quels sont les contrats SLA pour le serveur flexible avec la même zone et le serveur flexible redondant interzone ?

  Vous trouverez des informations sur le contrat de niveau de service pour Azure Database pour le serveur flexible MySQL dans la page SLA pour Azure Database pour MySQL.

• Comment les serveurs haute disponibilité (HA) sont-ils facturés ? Les serveurs offrant une haute disponibilité ont un réplica principal et un réplica secondaire. Le réplica secondaire peut être dans la même zone ou dans une zone redondante. Le calcul et le stockage provisionnés sont facturés pour le réplica principal et le réplica secondaire. Par exemple, si vous avez un réplica principal avec 4 vCores de calcul et 512 Go de stockage provisionné, votre réplica secondaire aura également 4 vCores et 512 Go de stockage provisionné. Votre serveur haute disponibilité redondant interzone est facturé pour 8 vCores et 1 024 Go de stockage. En fonction du volume de stockage de sauvegarde, vous pouvez également être facturé pour le stockage de sauvegarde.

• Puis-je utiliser le réplica de secours pour des opérations de lecture ou d’écriture ?
  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.

• Le basculement entraîne-t-il une perte de données ?
  Les journaux du 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 réplica prend les rôles du serveur principal.
  

• Dois-je effectuer une action après un basculement ?
  Les basculements sont entièrement transparents à partir de l’application cliente. Aucune action de votre part n’est nécessaire. L’application doit simplement utiliser la logique de nouvelle tentative pour ses connexions.
  

• Que se passe-t-il si je ne choisis pas une zone spécifique pour mon réplica de secours ? Puis-je modifier la zone par la suite ?
  Si vous ne choisissez pas de zone, l’une d’elles sera sélectionnée au hasard. Cela va être celle utilisée pour le serveur principal. Pour modifier la zone ultérieurement, vous pouvez définir Haute disponibilité sur Désactivé dans le volet Haute disponibilité, puis la redéfinir sur Redondant interzone et choisir une zone.
  

• La réplication entre le serveur principal et le serveur réplica de secours est-elle synchrone ?
  La réplication entre le réplica primaire et celui de secours est similaire au mode semisynchrone de MySQL. Lorsqu’une transaction est validée, elle n’est pas nécessairement validée dans le réplica de remplacement. Toutefois, lorsque le serveur principal n’est pas disponible, celui de secours réplique toutes les modifications de données à partir du serveur principal pour s’assurer qu’il n’y a aucune perte de données.
  

• Un basculement est-il opéré vers le réplica de secours dans tous les cas de défaillance non planifiée ?
  En cas de plantage d’une base de données ou de défaillance d’un nœud, la machine virtuelle du serveur flexible est redémarrée sur le même nœud. En même temps, un basculement automatique est déclenché. Si le redémarrage de la machine virtuelle du serveur flexible réussit avant la fin du basculement, l’opération de basculement est annulée. La détermination du serveur à utiliser comme réplica principal dépend du processus qui se termine en premier.
  

• L’utilisation de la haute disponibilité a-t-elle un impact sur les performances ?
  Pour la haute disponibilité redondante interzone, bien qu’il n’y ait pas d’impact majeur sur les performances des charges de travail de lecture entre les zones de disponibilité, il peut y avoir une baisse de 40 % de la latence des requêtes d’écriture. L’augmentation de la latence d’écriture est due à la réplication synchrone dans la zone de disponibilité. L’impact sur la latence d’écriture est généralement deux fois plus important dans une zone HA redondante par rapport à la même zone HA. Pour la haute disponibilité dans la même zone, étant donné que le réplica principal et que le réplica de secours se trouvent dans la même zone, la latence de réplication et par conséquent la latence d’écriture synchrone sont plus faibles. En résumé, si la latence d’écriture est un élément plus stratégique pour vous par rapport à la disponibilité, vous pouvez choisir la haute disponibilité de même zone, mais si la disponibilité et la résilience de vos données sont plus essentielles pour vous au détriment de la baisse de la latence d’écriture, vous devez choisir la haute disponibilité redondante interzone. Pour mesurer l’impact précis de la baisse de latence dans la configuration de haute disponibilité, nous vous recommandons d’effectuer des tests de performance pour votre charge de travail afin de prendre une décision éclairée.
  

• Comment la maintenance de mon serveur haute disponibilité se produit-elle ?
  Les événements planifiés tels que la mise à l’échelle des mises à niveau des versions mineures et de calcul se produisent d’abord sur l’instance de secours d’origine, puis en déclenchant une opération de basculement planifiée, puis fonctionnent sur l’instance principale d’origine. Vous pouvez définir la fenêtre de maintenance planifiée pour un serveur haute disponibilité de la même façon que pour un serveur flexible. Le temps d’arrêt sera le même que celui de l’instance du serveur flexible Azure Database pour MySQL quand la haute disponibilité est désactivée.
  

• Puis-je effectuer une restauration à un instant dans le passé (PITR) de mon serveur haute disponibilité ?
  Vous pouvez effectuer une restauration à un instant dans le passé d’une instance de serveur flexible Azure Database pour MySQL pour lequel la haute disponibilité est activée vers une nouvelle instance de serveur flexible Azure Database pour MySQL pour lequel la haute disponibilité est désactivée. Si le serveur source a été créé avec une haute disponibilité redondante interzone, vous pouvez par la suite activer la haute disponibilité redondante interzone ou la haute disponibilité dans la même zone sur le serveur restauré. Si le serveur source a été créé avec une haute disponibilité dans la même zone, vous pouvez uniquement activer la haute disponibilité dans la même zone sur le serveur restauré.
  

• Puis-je activer la haute disponibilité sur un serveur après avoir créé le serveur ?
  La haute disponibilité redondante interzone doit être activée lors de la création du serveur. Vous pouvez activer la haute disponibilité dans la même zone après avoir créé le serveur. Avant d’activer la haute disponibilité dans la même zone, vérifiez que les paramètres de serveur « enforce_gtid_consistency » et « gtid_mode » sont activés
  

• Puis-je désactiver la haute disponibilité pour un serveur après sa création ?
  Vous pouvez désactiver la haute disponibilité sur un serveur après l’avoir créé. La facturation s’arrête immédiatement.
  

• Comment puis-je réduire le temps d’arrêt ?
  Vous devez être en mesure de réduire les temps d’arrêt de votre application, même si vous n’utilisez pas la haute disponibilité. Les interruptions de service, comme les correctifs planifiés, les mises à niveau de version mineures ou les opérations initiées par le client, comme la mise à l’échelle du calcul, peuvent être effectuées dans des fenêtres de maintenance planifiées. Pour limiter l’impact sur l’application pour les tâches de maintenance lancées par Azure, vous pouvez les planifier le jour de la semaine et à l’heure souhaités pour réduire l’impact sur l’application.
  

• Puis-je utiliser un réplica en lecture pour un serveur à haute disponibilité ?
  Oui, les réplicas de lecture sont pas pris en charge pour les serveurs haute disponibilité.
  

• Puis-je utiliser la réplication des données entrantes pour des serveurs haute disponibilité ?
  La prise en charge de la réplication des données entrantes pour un serveur à haute disponibilité est disponible uniquement via une réplication basée sur GTID. La procédure stockée pour la réplication en utilisant GTID est disponible sur tous les serveurs à haute disponibilité sous le nom mysql.az_replication_with_gtid.

• Puis-je basculer vers un serveur de secours pour réduire le temps d’arrêt pendant le redémarrage du serveur ou une mise à l’échelle ?
  Actuellement, le serveur flexible Azure Database pour MySQL d’Azure a recours au basculement planifié pour optimiser les opérations de haute disponibilité, y compris la mise à l’échelle vers le haut ou vers le bas, et la maintenance planifiée pour aider à réduire les temps d’arrêt. Lorsque de telles opérations sont lancées, elles fonctionnent d’abord sur l’instance de secours d’origine, puis déclenchent une opération de basculement planifiée, avant de fonctionner sur l’instance principale d’origine.
  

• Peut-on modifier le mode de disponibilité (HA redondante interzone/dans la même zone) du serveur ?
  Si vous créez le serveur avec le mode Haute disponibilité redondante interzone activé, vous pouvez passer de la haute disponibilité redondante interzone à la haute disponibilité dans la même zone et vice versa. Pour modifier le mode de disponibilité ultérieurement, vous pouvez définir Haute disponibilité sur Désactivée dans le volet Haute disponibilité, puis la redéfinir sur Redondant interzone ou dans la même zone et choisir Mode Haute disponibilité
  .

Étapes suivantes

• Découvrir la continuité de l’activité.
• Découvrir la haute disponibilité redondante interzone.
• Découvrez la sauvegarde et la récupération.