Fonctionnalités de niveau de performance d’Azure Database pour MySQL – Serveur flexible
Vous pouvez créer des serveurs flexibles Azure Database pour MySQL en fonction de l’un des trois niveaux de service : Burstable, usage général et critique pour l’entreprise. Les niveaux de service fournissent un niveau croissant de calcul et de taille de stockage, ainsi que le nombre de connexions maximales prises en charge et les opérations d’E/S par seconde (IOPS). Un serveur flexible MySQL peut héberger plusieurs bases de données. Vous pouvez surveiller les métriques de performances de votre serveur flexible MySQL, telles que l’utilisation du processeur et de la mémoire, le niveau de performance des E/S, les métriques de requête, etc. pour prendre des décisions de capacité éclairées.
Taille de calcul : RAM et cœurs
Chacun des trois niveaux de service fournit des références SKU de machine virtuelle sous-jacentes différentes. Le niveau Burstable utilise des machines virtuelles de série B, le niveau Usage général utilise des machines virtuelles de série D et le niveau Critique pour l’entreprise utilise des machines virtuelles de série E. La série de machines virtuelles utilisée détermine le nombre de vCores et de RAM disponibles sur le serveur.
Vous pouvez modifier le niveau de calcul, la taille de calcul et la taille de stockage après avoir créé un serveur. La modification du niveau de calcul ou de la taille de calcul nécessite un redémarrage qui prend généralement entre un et deux minutes. La modification de la taille de stockage ne nécessite pas de redémarrage.
Pour les charges de travail hors production (développement, préproduction, test, etc.), envisagez d’utiliser des serveurs basés sur le niveau Burstable, qui fournit une solution économique pour les charges de travail qui n’utilisent pas en permanence l’intégralité du processeur. Pendant les périodes de faible utilisation, les serveurs utilisant des machines virtuelles de série B accumulent des crédits d’UC qui peuvent être utilisés dans des périodes d’utilisation élevée pour « rafaler » le niveau de performance au-dessus de la ligne de base. Si votre ligne de base est trop élevée ou qu’il y a trop de rafales d’utilisation élevée, envisagez d’effectuer une mise à niveau vers les niveaux Usage général ou Critique pour l’entreprise afin d’éviter la détérioration des performances.
Tailles de calcul du niveau de service
Chacun des trois niveaux de service fournit différents niveaux de puissance de calcul. Bien que le niveau Burstable puisse prendre en charge jusqu’à 20 vCores et que le niveau Usage général peut prendre en charge jusqu’à 64 vCores, avec la prise en charge de jusqu’à 96 vCores, le niveau Critique pour l’entreprise fournit le niveau de puissance de calcul le plus élevé. Le niveau Critique pour l’entreprise fournit également les machines virtuelles de la série Ev5, qui jusqu’à 30 % plus de QPS et 50 % de latence inférieure que les machines virtuelles de la série Ev4.
IOPS : Mise à l’échelle automatique et préapprovisionnée
Le nombre d’opérations de lecture et d’écriture qui peuvent être effectuées par seconde est appelé IOPS de stockage (opérations d’E/S par seconde). Les paramètres d’E/S par seconde plus élevés offrent un meilleur niveau de performance de stockage : des opérations de lecture/écriture simultanées entraînent une récupération des données plus rapide, la persistance des données, les mises à jour d’index et l’efficacité globale de la base de données. Si les paramètres d’E/S par seconde sont trop faibles, la base de données peut rencontrer des retards de traitement et faire détériorer le niveau de performance. Toutefois, si les paramètres d’E/S par seconde sont trop élevés, vos coûts peuvent augmenter sans que vous réalisiez d’améliorations du niveau de performance.
Avec le serveur flexible Azure Database pour MySQL – , vous préapprovisionnez les IOPS ou utilisez la fonctionnalité IOPS de mise à l’échelle automatique.
Avec des E/S par seconde préapprovisionnés, vous allouez un nombre spécifique d’E/S par seconde pour fournir un niveau de performance cohérent et prévisible, ce qui fonctionne bien si la charge n’approche pas du seuil auquel les opérations d’E/S deviennent limitées. Bien que vous puissiez toujours allouer des E/S par seconde supplémentaires à mesure que vos demandes de charge de travail augmentent, cela nécessite une intervention manuelle.
Avec la fonctionnalité mise à l’échelle automatique fonctionnalités D’E/S par seconde activée, votre IOPS est mise à l’échelle à la demande en fonction de l’activité de charge de travail et vous payez en fonction de la consommation. À mesure que la charge de travail augmente, le serveur met à l’échelle le niveau de performance des E/S en toute transparence, ce qui permet à votre instance de gérer les pics de charge de travail sans payer de capacité inutilisée lorsque le trafic est faible.
Dans les deux cas, les IOPS ne peuvent pas dépasser le maximum du serveur. Pour plus d’informations sur le nombre maximal d’E/S par seconde par taille de calcul, consultez l’article documentation sur le calcul et le stockage.
Réplicas en lecture
À mesure que le trafic de votre base de données augmente, vous pouvez mettre à l’échelle sa capacité horizontalement ou « out » (nombre de nœuds de calcul), ou verticalement ou « up » (taille des nœuds de calcul). Les réplicas en lecture fournissent une mise à l’échelle horizontale.
Un réplica en lecture seule est une copie en lecture seule d’une base de données qui reste synchronisée à l’aide de la réplication du journal binaire de MySQL (binlog). À mesure que les applications augmentent, elles doivent mettre à l’échelle les ressources de calcul et de stockage (comme la base de données). La mise à l’échelle des composants d’application est simplifiée en approvisionnant de nouvelles machines virtuelles à l’aide d’Azure Kubernetes Service (AKS), Microsoft Azure Virtual Machine Scale Setset App Service. À mesure que ces ressources de calcul sont mises à l’échelle et que les données stockées augmentent, elles augmentent la charge sur la base de données, ce qui finit souvent par être un goulot d’étranglement dans l’architecture de l’application.
L’utilisation d’un réplica en lecture vous permet de rediriger les opérations en lecture seule vers des bases de données secondaires afin que le serveur principal prenne en charge les opérations de lecture/écriture. Azure Database pour MySQL fournit des réplicas en lecture managées. Vous pouvez répliquer un serveur source sur un maximum de 10 réplicas. Cela peut aider dans les cas d’utilisation tels que la création de rapports et les analytique, qui interrogent souvent de grandes quantités de données.
L’utilisation d’un réplica en lecture est particulièrement utile lorsque pour une raison ou une autre requête ne peut pas utiliser d’index. Il peut être difficile ou même perturbant d’ajouter des index pour tous les modèles de requête, car il place une charge supplémentaire sur le serveur (traitement, E/S disque, stockage, temps de transaction, etc.). Si une base de données de l’entrepôt de données n’est pas disponible ou si vous avez besoin de données plus récentes que son cycle d’actualisation, l’utilisation d’un réplica en lecture est un excellent moyen d’exécuter des requêtes « volumineuses » sans perturber les opérations critiques de lecture/écriture.
Les réplicas en lecture ne sont pas immédiatement synchrones de la même façon qu’une configuration à haute disponibilité. Les réplicas en lecture n’introduisent pas la latence transactionnelle associée à une solution haute disponibilité, mais il peut y avoir un léger retard lorsque les données atteignent le réplica de la base de données primaire.