Pour les charges de travail nécessitant beaucoup de lectures que vous voulez monter en charge, vous pouvez utiliser des réplicas en lecture, qui sont désormais à la disposition générale de tous les utilisateurs d’Azure Database pour MySQL. Les réplicas en lecture permettent de monter en charge horizontalement au-delà d’un serveur de base de données unique. Cela est utile dans les charges de travail telles que la génération de rapports de décisionnel et les applications web, qui ont généralement plus d’opérations de lecture que d’opérations d’écriture.

La fonctionnalité prend en charge la réplication asynchrone continue des données d’un serveur Azure Database pour MySQL (serveur « maître ») vers un maximum de cinq serveurs Azure Database pour MySQL (serveurs « réplicas en lecture ») situés dans la même région. Les charges de travail nécessitant beaucoup de lectures peuvent être réparties entre les serveurs réplicas à votre convenance. Les serveurs de réplicas sont en lecture seule, sauf pour les lectures répliquées à partir des modifications de données apportées sur le maître.

Qu’est-ce qui est pris en charge avec les réplicas en lecture ?

Vous pouvez créer ou supprimer des serveurs réplicas en fonction des besoins de votre charge de travail. Un serveur maître peut prendre en charge jusqu’à cinq serveurs réplicas au sein de la même région Azure. Le fait d’arrêter la réplication sur un serveur réplica le convertit en serveur en lecture-écriture autonome.

Vous pouvez gérer facilement vos serveurs réplicas à l’aide du portail Azure et de l’interface de ligne de commande Azure.

Dans le portail Azure :

Utilisez Azure Monitor pour effectuer le suivi de la réplication avec la métrique « décalage de la réplication en secondes » :

Dans Azure CLI :

az mysql server replica create -n mydemoreplica1 -g myresourcegroup -s mydemomaster

Voici des modèles d’applications utilisés par nos clients et partenaires qui tirent parti de réplicas en lecture pour mettre à l’échelle des charges de travail.

Génération de rapports de décisionnel

Des données provenant de différentes sources sont traitées à intervalles de quelques minutes et chargées dans le serveur maître. Le serveur maître est dédié aux charges et au traitement, ce qui ne l’expose pas directement aux utilisateurs de décisionnel pour la génération de rapports ou l’analytique afin de garantir des performances prévisibles. La charge de travail de génération de rapports est montée en charge sur plusieurs réplicas en lecture pour gérer la simultanéité d’utilisateurs élevée avec une latence faible.

Microservices

Dans ce modèle d’architecture, l’application est divisée en différents microservices. Des API de modification des données se connectent au serveur maître tandis que des API de génération de rapports se connectent aux réplicas en lecture. Les API de modification des données commencent par le préfixe « Set- », et les API de génération de rapports le préfixe « Get- ». L’équilibreur de charge est utilisé pour acheminer le trafic en fonction du préfixe de l’API.

Étapes suivantes

• Apprivoisez le service en créant votre premier serveur Azure Database pour MySQL à l’aide du portail Azure ou de l’interface de ligne de commande Azure.
• En savoir plus sur les réplicas en lecture et la façon de les créer dans le portail Azure ou Azure CLI.
• Contactez notre équipe à l’adresse AskAzureDBforMySQL@service.microsoft.com.
• Envoyez vos demandes de fonctionnalités sur UserVoice.
• Suivez-nous sur Twitter @AzureDBMySQL pour ne rien manquer des dernières fonctionnalités.