Partager via

Réplicas en lecture dans Azure Database pour MySQL

  • Article

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

Important

Le serveur unique Azure Database pour MySQL est en voie de mise hors service. Nous vous conseillons vivement de procéder à une mise à niveau vers Azure Database pour MySQL – Serveur flexible. Pour obtenir plus d’informations sur la migration vers Azure Database pour MySQL – Serveur flexible, consultez Qu’en est-il du Serveur unique Azure Database pour MySQL ?

La fonctionnalité de réplica en lecture vous permet de répliquer les données d’un serveur Azure Database pour MySQL sur un serveur en lecture seule. Vous pouvez effectuer la réplication à partir du serveur source vers cinq 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 manière similaire aux serveurs Azure Database pour MySQL classiques. Pour chaque réplica en lecture, vous êtes facturé en fonction de la capacité de calcul provisionnée dans les vCores et du stockage provisionné en Go/mois.

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.

Quand utiliser un 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.

Un scénario courant est d’avoir les charges de travail décisionnelles et analytiques qui utilisent le réplica en lecture comme source de données pour la création de rapports.

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

Vous pouvez disposer d’un serveur source dans toute région Azure Database pour MySQL. Un serveur source peut avoir un réplica dans sa région jumelée ou dans les régions de réplica universelles. L’image suivante montre les régions de réplica disponibles en fonction de votre région source.

Régions de réplica universelles

Vous pouvez créer un réplica en lecture dans les régions suivantes, quel que soit l’emplacement de votre serveur source. Les régions de réplica universelles prises en charge sont les suivantes :

Région Disponibilité des réplicas
Australie Est ✔️
Sud-Est de l’Australie ✔️
Brésil Sud ✔️
Centre du Canada ✔️
Est du Canada ✔️
USA Centre ✔️
USA Est ✔️
USA Est 2 ✔️
Asie Est ✔️
Japon Est ✔️
OuJapon Est ✔️
Centre de la Corée ✔️
Corée du Sud ✔️
Europe Nord ✔️
Centre-Nord des États-Unis ✔️
États-Unis - partie centrale méridionale ✔️
Asie Sud-Est ✔️
Suisse Nord ✔️
Sud du Royaume-Uni ✔️
Ouest du Royaume-Uni ✔️
Centre-USA Ouest ✔️
USA Ouest ✔️
USA Ouest 2 ✔️
Europe Ouest ✔️
Inde Centre* ✔️
France Centre* ✔️
Émirats arabes unis Nord* ✔️
Afrique du Sud Nord* ✔️

Remarque

*Régions où Azure Database pour MySQL dispose d’un stockage à usage général V2 en préversion publique
*Pour ces régions Azure, vous aurez la possibilité de créer un serveur à la fois dans le stockage à usage général v1 et v2. Pour les serveurs créés avec stockage à usage général v2 dans la préversion publique, vous êtes limité à la création d’un serveur réplica uniquement dans les régions Azure qui prennent en charge le stockage à usage général v2.

Régions jumelées

Outre les régions de réplica universelles, vous pouvez créer un réplica en lecture dans la région Azure jumelée de votre serveur source. Si vous ne connaissez pas la région jumelée de votre région, vous trouverez plus d’informations dans l’article sur les régions jumelées Azure.

Si vous utilisez des réplicas entre régions pour la planification de la récupération d’urgence, nous vous recommandons de créer le réplica dans la région jumelée plutôt que dans une autre région. Les régions jumelées évitent les mises à jour simultanées et hiérarchisent l’isolement physique et la résidence des données.

Il existe toutefois quelques limitations à prendre en compte :

  • Disponibilité régionale : Azure Database pour MySQL est disponible dans les régions France Centre, Émirats arabes unis Nord et Allemagne Centre. Toutefois, leurs régions jumelées ne sont pas disponibles.

  • Paires unidirectionnelles : Certaines régions Azure sont jumelées dans une seule direction. Ces régions incluent Inde Ouest, Brésil Sud et US Gov Virginie. Cela signifie qu’un serveur source dans la région Inde Ouest peut créer un réplica dans la région Inde Sud. Toutefois, un serveur source dans la région Inde Sud ne peut pas créer de réplica dans la région Inde Ouest. En effet, la région secondaire de la région Inde Ouest est Inde Sud, mais la région secondaire de la région Inde Sud n’est pas Inde Ouest.

Créer un réplica

Important

  • La fonctionnalité de réplica en lecture est disponible uniquement pour les serveurs Azure Database pour MySQL dans les niveaux tarifaires Usage général ou Mémoire optimisée. Vérifiez que le serveur source se trouve dans l’un de ces niveaux tarifaires.
  • Si votre serveur source n’a pas de serveurs de réplication existants, le serveur source peut nécessiter un redémarrage pour se préparer à la réplication en fonction du stockage utilisé (v1/v2). Veuillez envisager le redémarrage du serveur et effectuer cette opération pendant les heures creuses. Pour plus d’informations, consultez Redémarrage du Serveur Source.

Quand vous démarrez le workflow de création de réplica, un serveur Azure Database pour MySQL vide est créé. 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. 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.

Chaque réplica est activé pour la croissance automatique du stockage. La fonctionnalité de croissance automatique permet au réplica de s’adapter aux données qui sont répliquées sur celui-ci et d’empêcher une interruption de la réplication à cause d’erreurs liées à la saturation de l’espace de stockage.

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 des règles de pare-feu du serveur source. Ensuite, ces règles sont indépendantes du serveur source.

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 faites sur un serveur Azure Database pour MySQL classique. 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@myreplica -p

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

Superviser la réplication

Azure Database pour MySQL fournit la métrique Décalage de la 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.

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.

É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 indiquera 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 décrites précédemment.

Identificateur de transaction global (GTID)

L'identificateur de transaction global (GTID) est un identificateur unique créé pour chaque transaction validée sur un serveur source. Par défaut, il est désactivé dans Azure Database pour MySQL. Le GTID est pris en charge sur les versions 5.7 et 8.0, et uniquement sur les serveurs qui prennent en charge un stockage maximum de 16 To (stockage à usage général v2). 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.

MySQL prend en charge deux types de transactions : les transactions GTID (avec GTID) et les transactions anonymes (sans GTID)

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

Notes

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

  • La modification de la valeur d’un GTID ne peut être effectuée qu’une étape à la fois dans l’ordre croissant des modes. Par exemple, si gtid_mode est défini sur OFF_PERMISSIVE, il est possible de le changer en ON_PERMISSIVE mais pas en ON.

  • Pour assurer la cohérence de la réplication, vous ne pouvez pas le mettre à jour pour un serveur maître/de réplication.

  • Il est recommandé de définir enforce_gtid_consistency sur ON avant de définir gtid_mode=ON

Pour activer le GTID et configurer le comportement de cohérence, mettez à jour les paramètres serveur gtid_mode et enforce_gtid_consistency à l'aide du portail Azure, d'Azure CLI ou de PowerShell.

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 le ou les serveurs maîtres ou de réplication sont créés avec le GTID activé.

Observations et limitations

Niveaux de tarification

Les réplicas en lecture ne sont actuellement disponibles que dans les niveaux tarifaires Usage général et Mémoire optimisée.

Notes

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

Serveur disposant d’un stockage à usage général v1, le log_bin paramètre sera désactivé par défaut. La valeur est activée lorsque vous créez le premier réplica de lecture. Si un serveur source ne dispose d’aucun réplica en lecture, le serveur source redémarrera dans un premier temps afin de se préparer pour la réplication. Veuillez envisager le redémarrage du serveur et effectuer cette opération pendant les heures creuses.

Serveur source disposant d’un stockage à usage général v2, le log_bin paramètre sera activé par défaut et ne nécessitera pas de redémarrage lorsque vous ajoutez un réplica en lecture.

Nouveaux réplicas

Un réplica en lecture est créé en tant que serveur 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 tarifaire peut également être changé indépendamment, sauf vers ou depuis le niveau De base.

Important

Avant de mettre à jour une configuration de serveur source avec de nouvelles valeurs, mettez à jour la configuration du réplica avec des valeurs égales ou supérieures. Ainsi, vous aurez la garantie que le réplica peut suivre les changements apportés au serveur source.

Les règles de pare-feu 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 :

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.

GTID

Le GTID est pris en charge sur :

  • MySQL versions 5.7 et 8.0.
  • Serveurs prenant en charge un stockage maximum de 16 To. Reportez-vous à l'article Niveau tarifaire pour obtenir la liste complète des régions qui prennent en charge le stockage de 16 To.

Le GTID est désactivé par défaut. 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.

Si le GTID est activé sur un serveur source, il sera également activé sur les réplicas nouvellement créés, et ceux-ci utiliseront la réplication GTID. Pour assurer la cohérence de la réplication, vous ne pouvez pas mettre à jour gtid_mode sur les serveurs sources ou réplicas.

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