Réplicas en lecture dans Azure Database pour MySQL - Serveur flexible

  • Article

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

MySQL est l’un des moteurs de base de données couramment utilisés pour exécuter des applications web et mobiles à l’échelle d’Internet. La plupart de nos clients s’en servent pour leurs services de formation en ligne, services de diffusion vidéo, solutions de paiement numérique, plateformes de commerce électronique, services de jeux, portails d’actualité, administrations publiques et sites web de santé. Ces services sont requis à des fins de mise à l’échelle à mesure que le trafic sur l’application web ou mobile augmente.

Du côté des applications, l’application est généralement développée en Java ou PHP et migrée pour s’exécuter sur Azure Virtual Machine Scale Sets ou Azure App Services ou est conteneurisée pour s’exécuter sur Azure Kubernetes Service (AKS). Avec virtual Machine Scale Set, App Service ou AKS comme infrastructure sous-jacente, la mise à l’échelle des applications est simplifiée en approvisionnant instantanément de nouvelles machines virtuelles et en répliquant les composants sans état des applications pour répondre aux demandes, mais souvent, la base de données finit par être un goulot d’étranglement en tant que composant avec état centralisé.

La fonctionnalité de réplica en lecture vous permet de répliquer des données à partir d’une instance de serveur flexible Azure Database pour MySQL vers un serveur en lecture seule. Vous pouvez effectuer la réplication à partir du serveur source vers dix réplicas au maximum. Les réplicas sont mis à jour de manière asynchrone à l’aide de la technologie de réplication selon la position du fichier journal binaire (binlog) native au moteur MySQL. Pour en savoir plus sur la réplication binlog, consultez la vue d’ensemble de la réplication binlog MySQL.

Les réplicas sont de nouveaux serveurs que vous gérez de la même façon que vos instances de serveur source Azure Database pour MySQL flexibles. Vous entraînez des frais de facturation pour chaque réplica en lecture en fonction du calcul provisionné dans les vCores et du stockage en Go/mois. Pour plus d’informations, voir la tarification.

Remarque

La fonctionnalité de réplica en lecture est disponible uniquement pour Azure Database pour MySQL instances de serveur flexibles dans les niveaux tarifaires Usage général ou Critique pour l’entreprise. Vérifiez que le serveur source se trouve dans l’un de ces niveaux tarifaires.

Pour découvrir plus en détail les fonctionnalités de réplication MySQL et les problèmes associés, consultez la documentation sur la réplication MySQL.

Notes

Cet article contient des références au terme esclave, un terme que Microsoft n’utilise plus. Lorsque le terme sera supprimé du logiciel, nous le supprimerons de cet article.

Cas d’usage courants du réplica en lecture

La fonctionnalité de réplica en lecture contribue à améliorer les performances et la scalabilité des charges de travail nécessitant une lecture intensive. Les charges de travail de lecture peuvent être isolées sur les réplicas, tandis que les charges de travail d’écriture peuvent être dirigées vers la source.

Voici des cas d’utilisation courants :

  • Mise à l’échelle des charges de travail de lecture provenant de l’application à l’aide d’un proxy de connexion léger comme ProxySQL ou à l’aide d’un modèle basé sur les microservices pour effectuer un scale-out de vos requêtes de lecture provenant de l’application en réplicas en lecture.
  • Les charges de travail décisionnelles et analytiques peuvent utiliser des réplicas en lecture en tant que source de données pour la création de rapports.
  • Pour les scénarios IoT ou de fabrication dans lesquels les informations de télémétrie sont ingérées dans le moteur de base de données MySQL alors que plusieurs réplicas en lecture sont utilisés pour la création de rapports de données.

Dans la mesure où les réplicas sont en lecture seule, ils ne réduisent pas directement les charges relatives à la capacité d’écriture sur la source. Cette fonctionnalité ne cible pas les charges de travail nécessitant une écriture intensive.

La fonctionnalité de réplica en lecture utilise la réplication asynchrone MySQL. La fonctionnalité n’est pas destinée aux scénarios de réplication synchrone. Il y a un délai mesurable entre la source et le réplica. Les données du réplica finissent par devenir cohérentes avec les données du serveur source. Utilisez cette fonctionnalité pour les charges de travail pouvant s’adapter à ce délai.

Réplication entre régions

Vous pouvez créer un réplica en lecture dans une autre région à partir de votre serveur source. La réplication entre régions peut être utile pour des scénarios tels que la planification de la récupération d’urgence ou le rapprochement des données de vos utilisateurs. Azure Database pour MySQL serveur flexible vous permet de provisionner un réplica en lecture dans toutes les régions support Azure où Azure Database pour MySQL serveur flexible est disponible. Grâce à cette fonctionnalité, un serveur source peut avoir un réplica dans sa région jumelée ou dans les régions de réplica universelles. Reportez-vous ici pour trouver la liste des régions Azure où Azure Database pour MySQL serveur flexible est disponible aujourd’hui.

Créer un réplica

Si un serveur source ne dispose d’aucun serveur de réplication, le serveur source redémarre tout d’abord afin de se préparer pour la réplication.

Lorsque vous démarrez le flux de travail de création de réplica, une instance de serveur flexible Azure Database pour MySQL vide est créée. Le nouveau serveur est rempli avec les données qui se trouvaient sur le serveur source. Le temps de création dépend de la quantité de données présentes sur le serveur source et du temps écoulé depuis la dernière sauvegarde complète hebdomadaire. Le temps nécessaire peut aller de quelques minutes à plusieurs heures.

Notes

Les réplicas en lecture sont créés avec la même configuration de serveur que le serveur source. La configuration du serveur réplica peut être modifiée après la création de ce dernier. Le serveur réplica est toujours créé dans le même groupe de ressources et dans le même abonnement que le serveur source. Si vous souhaitez créer un serveur réplica dans un autre groupe de ressources ou un autre abonnement, vous pouvez déplacer le serveur réplica après sa création. Il est recommandé de maintenir la configuration du serveur réplica à des valeurs égales ou supérieures à celles du serveur source pour garantir que le réplica sera à la hauteur du serveur source.

Découvrez comment créer un réplica en lecture dans le portail Azure.

Se connecter à un réplica

Au moment de sa création, un réplica hérite de la méthode de connectivité du serveur source. Vous ne pouvez pas modifier la méthode de connectivité du réplica. Par exemple, si le serveur source dispose d’un accès privé (intégration au réseau virtuel), le réplica ne peut pas être en accès public (adresses IP autorisées).

Le réplica hérite du compte Administrateur du serveur source. Tous les comptes d’utilisateur sur le serveur source sont répliqués sur les réplicas en lecture. Vous pouvez uniquement vous connecter à un réplica en lecture à l’aide des comptes d’utilisateur disponibles sur le serveur source.

Vous pouvez vous connecter au réplica à l’aide de son nom d’hôte et d’un compte d’utilisateur valide, comme vous le feriez sur une instance de serveur flexible Azure Database pour MySQL régulière. Sur un serveur nommé myreplica, à l’aide du nom d’utilisateur administrateur myadmin, vous pouvez vous connecter au réplica via l’interface de ligne de commande mysql :

mysql -h myreplica.mysql.database.azure.com -u myadmin -p

À l’invite, entrez le mot de passe du compte d’utilisateur.

Superviser la réplication

Azure Database pour MySQL serveur flexible fournit le Décalage de réplication en secondes dans Azure Monitor. Cette métrique est disponible pour les réplicas uniquement. Cette métrique est calculée à l’aide de la métrique seconds_behind_master disponible dans la commande SHOW SLAVE STATUS de MySQL. Définissez une alerte qui vous informe quand le décalage de la réplication atteint une valeur inacceptable pour votre charge de travail.

Si vous constatez un décalage de la réplication supérieur, consultez Résoudre les problèmes de latence de réplication pour dépanner et comprendre les causes possibles.

Important

Le réplica en lecture utilise la technologie de réplication basée sur le stockage, qui n’utilise plus la métrique « SLAVE_IO_RUNNING » /'REPLICA_IO_RUNNING' disponible dans la commande « SHOW SLAVE STATUS » de MySQL/ « SHOW REPLICA STATUS ». Cette valeur est toujours affichée sous la forme « Non » et n’indique pas l’état de réplication. Pour connaître l’état correct de la réplication, reportez-vous aux métriques de réplication : état de l’E/S du réplica et état SQL du réplica sous le panneau Surveillance.

Arrêter la réplication

Vous pouvez arrêter la réplication entre un serveur source et un réplica. Une fois la réplication arrêtée entre un serveur source et un réplica en lecture, celui-ci devient un serveur autonome. Les données du serveur autonome sont les données disponibles sur le réplica au lancement de la commande d’arrêt de la réplication. Le serveur autonome ne se met pas au même niveau que le serveur source.

Lorsque vous décidez d’arrêter la réplication pour un réplica, celui-ci perd tous les liens avec son serveur source précédent et d’autres réplicas. Il n’existe aucun basculement automatique entre une source et son réplica.

Important

Le serveur autonome ne peut pas être retransformé en réplica. Avant d’arrêter la réplication sur un réplica en lecture, vérifiez que celui-ci contient toutes les données nécessaires.

Découvrez comment arrêter la réplication sur un réplica.

Basculement

Il n’existe aucun basculement automatique entre des serveurs sources et serveurs réplicas.

Les réplicas en lecture ont vocation à mettre à l’échelle les charges de travail intensives en lecture, et non à répondre aux besoins de haute disponibilité d’un serveur. L’arrêt de la réplication sur le réplica en lecture pour le mettre en ligne en mode lecture-écriture permet d’effectuer ce basculement manuel.

Étant donné que la réplication est asynchrone, il y a un décalage entre la source et le réplica. Le niveau de décalage dépend de nombreux facteurs, comme la charge de travail exécutée sur le serveur source et la latence qui existe entre les centres de données. Dans la plupart des cas, le décalage du réplica va de quelques secondes à quelques minutes. Pour connaître le décalage d’un réplica, consultez la métrique Décalage de la réplication, qui est disponible pour chaque réplica. Cette métrique indique le temps écoulé depuis la dernière transaction réexécutée. Il est recommandé d’observer votre réplica sur une période donnée afin de déterminer le décalage moyen. Vous pouvez configurer une alerte afin d’être averti lorsque le décalage d’un réplica sort de la plage définie et prendre les mesures nécessaires.

Conseil

Si vous basculez vers le réplica, le décalage qui existe au moment où vous supprimez la liaison entre le réplica et le serveur source indique la quantité de données perdues.

Une fois que vous avez décidé de basculer vers un réplica :

  1. Arrêtez la réplication vers le réplica
    Cette étape est nécessaire pour que le serveur de réplication puisse accepter les écritures. Dans le cadre de ce processus, le serveur de réplication est dissocié du serveur source. En général, une fois que le processus d’arrêt de la réplication est lancé, le processus back-end prend environ 2 minutes. Pour comprendre les implications d’une telle action, consultez la section Arrêter la réplication.

  2. Faites pointer votre application vers l’ancien réplica
    Chaque serveur est associé à une chaîne de connexion unique. Mettez à jour votre application pour qu’elle pointe vers l’ancien réplica plutôt que le serveur source.

Une fois que votre application est en mesure de traiter les lectures et les écritures, le basculement est terminé. Le temps d’arrêt de votre application dépend du moment où vous détectez le problème et où vous effectuez les étapes 1 et 2 ci-dessus.

Identificateur de transaction global (GTID)

L’identificateur de transaction global (GTID) est un identificateur unique créé avec chaque transaction validée sur un serveur source et désactivé par défaut dans Azure Database pour MySQL serveur flexible. Le GTID est pris en charge sur les versions 5.7 et 8.0. Pour en savoir plus sur le GTID et son utilisation lors de la réplication, consultez la documentation relative à la réplication avec GTID de MySQL.

Les paramètres serveur suivants sont disponibles pour la configuration du GTID :

Paramètre serveur Description Valeur par défaut Valeurs
gtid_mode Indique si des GTID sont utilisés pour identifier les transactions. Les changements entre modes peuvent être effectués seulement par étape, dans l’ordre croissant (par ex., OFF ->OFF_PERMISSIVE ->ON_PERMISSIVE ->ON) OFF* OFF : Les nouvelles transactions et les transactions de réplication doivent être anonymes.
OFF_PERMISSIVE : Les nouvelles transactions sont anonymes. Les transactions répliquées peuvent être des transactions anonymes ou des transactions GTID.
ON_PERMISSIVE : Les nouvelles transactions sont des transactions GTID. Les transactions répliquées peuvent être des transactions anonymes ou des transactions GTID.
ON : Les nouvelles transactions et les transactions répliquées doivent être des transactions GTID.
enforce_gtid_consistency Applique la cohérence GTID en autorisant uniquement l'exécution des instructions qui peuvent être consignées de manière sécurisée sur le plan transactionnel. Cette valeur doit être définie sur ON avant d'activer la réplication GTID. OFF* OFF : Toutes les transactions sont autorisées à enfreindre la cohérence GTID.
ON : Aucune transaction n'est autorisée à enfreindre la cohérence GTID.
WARN : Toutes les transactions sont autorisées à enfreindre la cohérence GTID, mais un avertissement est généré.

Pour Azure Database pour MySQL instances de serveur flexible avec la fonctionnalité Haute disponibilité activée, la valeur par défaut est définie ONsur .

Remarque

  • Une fois le GTID activé, vous ne pouvez pas le désactiver. Si vous avez besoin de désactiver le GTID, contactez le support technique.
  • Vous pouvez changer les GTID d’une valeur à une autre étape à la fois dans l’ordre croissant des modes. Par exemple, si gtid_mode est actuellement défini sur OFF_PERMISSIVE, il est possible de passer à ON_PERMISSIVE mais pas à ON.
  • Pour maintenir la cohérence de la réplication, vous ne pouvez pas la mettre à jour pour un serveur maître/réplica.
  • Il est recommandé de définir enforce_gtid_consistency sur ON avant de définir gtid_mode=ON.

Pour activer GTID et configurer le comportement de cohérence, mettez à jour les paramètres du serveur et enforce_gtid_consistency de l’Portail Azure gtid_mode à l’aide de l’interface de ligne de commande Azure.

Si le GTID est activé sur un serveur source (gtid_mode = ON), il sera également activé sur les réplicas nouvellement créés, et ceux-ci utiliseront la réplication GTID. Pour garantir que la réplication est cohérente, gtid_mode ne peut pas être changé une fois que les serveurs maîtres ou de réplication sont créés avec le GTID activé.

Observations et limitations

Scénario Limitation/Considération
Réplica sur le serveur dans le niveau tarifaire Burstable Non pris en charge
Tarifs Le coût d’exécution du serveur de réplication est basé sur la région où le serveur de réplication est en cours d’exécution.
Redémarrage du serveur source Lorsque vous créez un réplica pour un serveur source qui n’en a pas, ce dernier commence par redémarrer afin de se préparer à la réplication. Tenez-en compte et effectuez ces opérations en période creuse.
Nouveaux réplicas Un réplica en lecture est créé en tant qu’instance de serveur flexible Azure Database pour MySQL. Un serveur existant ne peut pas être transformé en réplica. Vous ne pouvez pas créer un réplica d’un autre réplica en lecture.
Configuration du réplica Un réplica est créé à partir de la même configuration que celle du serveur source. Une fois le réplica créé, vous pouvez changer plusieurs paramètres indépendamment du serveur source : génération de calcul, vCores, stockage et période de conservation de la sauvegarde. Le niveau de calcul peut également être modifié indépendamment.

IMPORTANT : avant qu’une configuration de serveur source soit mise à jour vers de nouvelles valeurs, mettez à jour la configuration du réplica sur des valeurs égales ou supérieures. Ainsi, vous aurez la garantie que le réplica peut suivre les changements apportés au serveur source.
La méthode de connectivité et les paramètres sont transmis du serveur source au réplica lorsque le réplica est créé. Par la suite, les règles du réplica sont indépendantes.
Réplicas arrêtés Si vous arrêtez la réplication entre un serveur source et un réplica en lecture, le réplica arrêté devient un serveur autonome qui accepte aussi bien les lectures que les écritures. Le serveur autonome ne peut pas être retransformé en réplica.
Serveurs sources et autonomes supprimés Lorsqu’un serveur source est supprimé, la réplication est arrêtée sur tous les réplicas en lecture. Ces réplicas deviennent automatiquement des serveurs autonomes pouvant accepter des lectures et des écritures. Le serveur source lui-même est supprimé.
Comptes d'utilisateurs Les utilisateurs sur le serveur source sont répliqués sur les réplicas en lecture. Vous ne pouvez vous connecter à un réplica en lecture qu’avec des comptes d’utilisateur disponibles sur le serveur source.
Paramètres de serveur Pour empêcher les données de se désynchroniser et pour éviter leur perte ou leur endommagement potentiels, certains paramètres de serveur sont verrouillés et ne peuvent pas être mis à jour lors de l’utilisation des réplicas en lecture.
Les paramètres de serveur suivants sont verrouillés sur les serveurs sources et réplicas :
- innodb_file_per_table
- log_bin_trust_function_creators
Le paramètre event_scheduler est verrouillé sur les serveurs réplicas.
Pour mettre à jour l’un des paramètres ci-dessus sur le serveur source, supprimez les serveurs réplicas, mettez à jour la valeur du paramètre sur la source, puis recréez les réplicas.
Paramètres au niveau de la session Quand vous configurez des paramètres au niveau de la session comme « foreign_keys_checks » sur le réplica en lecture, vérifiez que les valeurs de paramètre définies sur le réplica en lecture sont cohérentes avec celles du serveur source.
Ajout de la clé primaire AUTO_INCREMENT à la table existante dans le serveur source. Nous vous déconseillons de modifier la table avec AUTO_INCREMENT après la création du réplica en lecture, car cela interrompt la réplication. Toutefois, si vous souhaitez ajouter la colonne d’incrément automatique après la création d’un serveur réplica, nous vous recommandons ces deux approches :
- Créez une table avec le même schéma de table que celui que vous souhaitez modifier. Dans la nouvelle table, modifiez la colonne avec AUTO_INCREMENT puis, à partir de la table d’origine, restaurez les données. Supprimez l’ancienne table et renommez-la dans la source. Nous ne devons pas nous occuper de la suppression du serveur de réplication, mais cela peut nécessiter un coût d’insertion important pour créer une table de sauvegarde.
- L’autre méthode plus rapide consiste à recréer le réplica après avoir ajouté toutes les colonnes avec incrémentation automatique.
Autre - La création d’un réplica de réplica n’est pas prise en charge.
- Les tables en mémoire peuvent entraîner la désynchronisation des réplicas. Il s’agit d’une limitation de la technologie de réplication MySQL. Pour plus d’informations, lisez la documentation de référence MySQL.
- Vérifiez que les tables du serveur source possèdent des clés primaires. L’absence de clés primaires peut entraîner une latence de réplication entre la source et les réplicas.
- Passer en revue la liste complète des limitations relatives à la réplication MySQL dans la documentation MySQL

Étapes suivantes