Niveaux de service d’Azure Database pour MySQL - Serveur flexible
S’APPLIQUE À : 
Azure Database pour MySQL – Serveur flexible
Vous pouvez créer une instance de serveur flexible Azure Database pour MySQL dans l’un des trois niveaux de service : Burstable, Usage général et Critique pour l’entreprise. Les niveaux tarifaires sous-jacents des machines virtuelles différencient les niveaux de service utilisés : Série B, Série D et Série E. Le choix du niveau de calcul et de la taille détermine la mémoire et les cœurs virtuels disponibles sur le serveur. Une technologie de stockage identique est utilisée sur tous les niveaux de service. Toutes les ressources sont approvisionnées au niveau de l’instance de serveur flexible Azure Database pour MySQL. Un serveur peut avoir une ou plusieurs bases de données.
| Ressource/Niveau | Expansible | Usage général | Critique pour l’entreprise |
|---|---|---|---|
| Série de la machine virtuelle | Tailles de machines virtuelles Burstable Série B | Dadsv5-seriesDdsv4-series | Edsv4/Edsv5-series*/Eadsv5-series |
| vCores | 1, 2, 4, 8, 12, 16, 20 | 2, 4, 8, 16, 32, 48, 64 | 2, 4, 8, 16, 32, 48, 64, 80, 96 |
| Mémoire par vCore | Variable | 4 Gio | 8 Gio ** |
| Taille de stockage | De 20 Gio à 16 Tio | De 20 Gio à 16 Tio | De 20 Gio à 32 Tio |
| Période de rétention de sauvegarde de bases de données | 1 à 35 jours | 1 à 35 jours | 1 à 35 jours |
** Sauf 64, 80 et 96 cœurs virtuels, qui disposent de 504 Gio, 504 Gio et 672 Gio de mémoire, respectivement.
* Le calcul Ev5 s’effectue le mieux entre d’autres séries de machines virtuelles en ce qui concerne les QPS et la latence. En savoir plus sur les performances et la disponibilité régionale du calcul Ev5 ici.
Niveaux de service des serveurs flexibles
Pour choisir un niveau de calcul, utilisez le tableau suivant comme point de départ.
| Niveau de calcul | Charges de travail cibles |
|---|---|
| Expansible | Idéal pour les charges de travail qui n’utilisent pas intégralement l’UC en permanence. |
| Usage général | La plupart des charges de travail professionnelles nécessitent un équilibre entre la capacité de calcul et la mémoire, avec un débit d’E/S évolutif. Il s’agit, par exemple, de serveurs destinés à l’hébergement d’applications web et mobiles, ainsi que d’autres applications d’entreprise. |
| Critique pour l’entreprise | Charges de travail de base de données haute performance qui nécessitent des performances en mémoire suffisantes pour un traitement plus rapide des transactions et une simultanéité plus élevée. Il s’agit, par exemple, de serveurs destinés au traitement de données en temps réel et à des applications transactionnelles ou analytiques haute performance. |
Une fois que vous avez créé un serveur, vous pouvez modifier le niveau de calcul, la taille de calcul et la taille de stockage. La mise à l’échelle du calcul nécessite un redémarrage et prend de 60 à 120 secondes, alors que la mise à l’échelle du stockage n’en a pas besoin. Vous pouvez également augmenter ou réduire la période de rétention de sauvegarde, à la hausse ou à la baisse. Pour plus d’informations, consultez la section Mettre à l'échelle des ressources.
Niveaux de service, tailles et types de serveurs
Les ressources de calcul peuvent être sélectionnées en fonction du niveau et de la taille. Cela détermine les vCores et la taille de la mémoire. Les vCores représentent le processeur logique du matériel sous-jacent.
Expansible
Les spécifications détaillées des types de serveurs disponibles sont les suivantes pour le niveau de service Burstable.
| Taille de calcul | vCores | Taille de la mémoire physique (Gio) | Taille totale de la mémoire (Gio) | Nombre maximal d’E/S par seconde pris en charge | Nombre maximal de connexions | Stockage temporaire (SSD) en Gio |
|---|---|---|---|---|---|---|
| Standard_B1ms | 1 | 2 | 2.2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4 | 1 280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8.8 | 1 700 | 1365 | 0 |
| Standard_B4ms | 4 | 16 | 17.6 | 2 400 | 2731 | 0 |
| Standard_B8ms | 8 | 32 | 35,2 | 3100 | 5461 | 0 |
| Standard_B12ms | 12 | 48 | 52,8 | 3 800 | 8193 | 0 |
| Standard_B16ms | 16 | 64 | 70,4 | 4300 | 10923 | 0 |
| Standard_B20ms | 20 | 80 | 88 | 5 000 | 13653 | 0 |
Usage général
Les spécifications détaillées des types de serveurs disponibles sont les suivantes pour le niveau de service Usage général.
| Taille de calcul | vCores | Taille de la mémoire physique (Gio) | Taille totale de la mémoire (Gio) | Nombre maximal d’E/S par seconde pris en charge | Nombre maximal de connexions | Stockage temporaire (SSD) en Gio |
|---|---|---|---|---|---|---|
| Standard_D2ads_v5 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D2ds_v4 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D4ads_v5 | 4 | 16 | 22 | 6 400 | 2731 | 107 |
| Standard_D4ds_v4 | 4 | 16 | 22 | 6 400 | 2731 | 107 |
| Standard_D8ads_v5 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D8ds_v4 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D16ads_v5 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D16ds_v4 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D32ads_v5 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D32ds_v4 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D48ads_v5 | 48 | 192 | 264 | 20000 | 32 768 | 1290 |
| Standard_D48ds_v4 | 48 | 192 | 264 | 20000 | 32 768 | 1290 |
| Standard_D64ads_v5 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
| Standard_D64ds_v4 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
Critique pour l’entreprise
Les spécifications détaillées des types de serveurs disponibles sont les suivantes pour le niveau de service Critique pour l’entreprise.
| Taille de calcul | vCores | Taille de la mémoire physique (Gio) | Taille totale de la mémoire (Gio) | Nombre maximal d’E/S par seconde pris en charge | Nombre maximal de connexions | Stockage temporaire (SSD) en Gio |
|---|---|---|---|---|---|---|
| Standard_E2ds_v4 | 2 | 16 | 22 | 5 000 | 2731 | 37 |
| Standard_E2ads_v5 | 2 | 16 | 22 | 5 000 | 2731 | 37 |
| Standard_E4ds_v4 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E4ads_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v4 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E8ads_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v4 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E16ads_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v4 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E20ads_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v4 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E32ads_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v4 | 48 | 384 | 528 | 48 000 | 65536 | 906 |
| Standard_E48ads_v5 | 48 | 384 | 528 | 48 000 | 65536 | 906 |
| Standard_E64ds_v4 | 64 | 504 | 693 | 64 000 | 86016 | 1224 |
| Standard_E64ads_v5 | 64 | 504 | 693 | 64 000 | 86016 | 1224 |
| Standard_E80ds_v4 | 80 | 504 | 693 | 72 000 | 86016 | 1224 |
| Standard_E2ds_v5 | 2 | 16 | 22 | 5 000 | 2731 | 37 |
| Standard_E4ds_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v5 | 48 | 384 | 528 | 48 000 | 65536 | 906 |
| Standard_E64ds_v5 | 64 | 512 | 704 | 64 000 | 87383 | 1208 |
| Standard_E96ds_v5 | 96 | 672 | 924 | 80000 | 100000 | 2004 |
Résilience de zone par défaut dans Azure Database pour MySQL – Niveau critique pour l’entreprise du serveur flexible : à compter de la mi-décembre 2024, tous les nouveaux serveurs approvisionnés dans le niveau critique pour l’entreprise du serveur flexible seront fournis avec une résilience de zone intégrée, sans frais supplémentaires ! Cela signifie que vos données et fichiers de journaux seront automatiquement stockés sur un stockage redondant interzone, veillant ainsi à une récupération rapide après des incidents zonaux. Même sans activation de la Haute disponibilité, vous profitez d’une protection fluide avec des sauvegardes redondantes interzone. Plus d’informations
Gestion de la mémoire dans un serveur flexible Azure Database pour MySQL
Dans MySQL, la mémoire a un rôle vital dans diverses opérations, notamment le traitement des requêtes et la mise en cache. Le serveur flexible Azure Database pour MySQL optimise l’allocation de mémoire pour le processus de serveur MySQL (mysqld), ce qui lui permet de recevoir suffisamment de ressources de mémoire pour un traitement des requêtes, une mise en cache, une gestion des connexions clientes et une gestion des threads efficaces. Apprenez-en davantage sur la façon dont MySQL utilise la mémoire.
Taille de la mémoire physique (Go)
La taille de mémoire physique (Go) dans le tableau ci-dessous représente la mémoire vive (RAM) disponible en gigaoctets (Go) sur votre serveur flexible Azure Database pour MySQL.
Taille totale de la mémoire (Go)
Le serveur flexible Azure Database pour MySQL fournit une Taille totale de la mémoire (Go). Elle représente la mémoire totale disponible pour votre serveur, qui est une combinaison de mémoire physique et d’une quantité définie d’un composant SSD de stockage temporaire. Cette vue unifiée a pour but de rationaliser la gestion des ressources, ce qui vous permet de ne vous concentrer que sur la mémoire totale disponible pour votre processus serveur Azure MySQL (mysqld). La métrique Pourcentage de mémoire (memory_percent) représente le pourcentage de mémoire occupée par le processus serveur Azure MySQL (mysqld). Cette métrique est calculée à partir de la Taille totale de la mémoire (Go). Par exemple, lorsque la métrique Pourcentage de mémoire affiche une valeur de 60, cela signifie que votre processus de serveur Azure MySQL utilise 60 % de la taille totale de mémoire (Go) disponible sur votre serveur flexible Azure Database pour MySQL.
Serveur MySQL (mysqld)
Le processus serveur Azure MySQL, mysqld, est le moteur d’opérations de base de données principal. Au démarrage, il initialise l’ensemble des composants, tels que le pool de mémoires tampons InnoDB et le cache de threads, utilisant la mémoire en fonction des demandes de configuration et de charge de travail. Par exemple, le pool de mémoires tampons InnoDB met en cache les données et les index fréquemment sollicités pour améliorer la vitesse d’exécution des requêtes, tandis que le cache de threads gère les threads de connexion client. Plus d’informations
Moteur de stockage InnoDB
En tant que moteur de stockage par défaut de MySQL, InnoDB utilise la mémoire pour mettre en cache les données fréquemment sollicitées et gérer des structures internes telles que le pool de mémoires tampons innodb et la mémoire tampon de journal. Le pool de mémoires tampons InnoDB conserve les données de table et les index en mémoire afin de réduire les E/S de disque, ce qui améliore les performances. Le paramètre de taille du pool de mémoire tampon InnoDB est calculé d’après la taille de la mémoire physique (Go) disponible sur le serveur. Apprenez-en davantage sur les tailles du pool de mémoires tampons InnoDB disponibles dans le serveur flexible Azure Database pour MySQL.
Threads
Les connexions clientes sont gérées par le biais de threads dédiés gérés par le gestionnaire de connexions. Ces threads gèrent l’authentification, l’exécution des requêtes et la récupération des résultats pour les interactions du client. Plus d’informations
Pour plus d’informations sur les séries de calcul disponibles, consultez la documentation des machines virtuelles Azure concernant Tailles de machines virtuelles Burstable Série B, Usage général Série Dadsv5Série Ddsv4 et Critique pour l’entrepriseEdsv4/Série Edsv5/Série Eadsv5.
Limitations des performances des instances de série Burstable
Remarque
Pour les tailles de machine virtuelle Burstable Série B, si la machine virtuelle est démarrée, arrêtée ou redémarrée, les crédits peuvent être perdus. Pour plus d’informations, voir Tailles de machines virtuelles modulables Série B.
Le niveau de calcul Burstable est conçu pour fournir une solution économique pour les charges de travail qui n’utilisent pas intégralement l’UC en permanence. Ce niveau est idéal pour les charges de travail hors production, telles que les environnements de développement, de mise en lots ou de test. La fonctionnalité unique du niveau de calcul Burstable est sa capacité à fonctionner en « rafales », c’est-à-dire à utiliser plus que ses performances UC de référence, en utilisant jusqu’à 100 % du processeur virtuel lorsque la charge de travail l’exige. Cela est rendu possible par un modèle de crédit d’UC, qui permet aux instances Série B d’accumuler des « crédits d’UC » pendant les périodes de faible utilisation de l’UC. Vous pouvez ensuite dépenser ces crédits pendant des périodes d’utilisation élevée du processeur, ce qui permet à l’instance de dépasser ses performances de processeur de base.
Toutefois, il est important de noter qu’une fois qu’une instance Burstable a épuisé ses crédits d’UC, elle fonctionne selon ses performances UC de base. Par exemple, la performance UC de base d’une Standard_B1ms est de 20 %, soit 0,2 cœur virtuel. Supposons que le serveur de niveau Burstable exécute une charge de travail nécessitant plus de performances UC que le niveau de base, et qu’il a épuisé ses crédits d’UC. Dans ce cas, le serveur peut rencontrer des limitations de performances et finalement affecter diverses opérations système, comme Stop/Start/Restart, sur votre serveur.
Remarque
Pour les serveurs de tailles de machine virtuelle Burstable Série B, comme Standard_B1s/Standard_B1ms/Standard_B2s, la taille relativement plus petite de leur mémoire hôte peut entraîner des incidents (manque de mémoire) en cas de charge de travail continue, même si la métrique memory_percent n’a pas atteint 100 %.
En raison de cette limitation, le serveur pourrait rencontrer des problèmes de connectivité et les opérations système pourraient être affectées. Dans ces situations, il est recommandé de mettre en pause la charge de travail sur le serveur afin d’accumuler des crédits conformément au modèle de banque de crédits de la série B, ou d’envisager de mettre le serveur à l’échelle vers des niveaux supérieurs tels que les niveaux Usage général ou Critique pour l’entreprise.
Par conséquent, bien que le niveau de calcul Burstable offre des avantages significatifs en matière de coût et de flexibilité pour certains types de charges de travail, il n’est pas recommandé pour les charges de travail de production qui nécessitent des performances de processeur homogènes. Le niveau Burstable ne prend pas en charge la fonctionnalité de création des Réplicas en lecture dans Azure Database pour MySQL - Serveur flexible ni la fonctionnalité Concepts de haute disponibilité dans azure Database pour MySQL - Serveur flexible. D’autres niveaux de calcul, comme Usage général ou Critique pour l’entreprise, sont plus appropriés pour ces charges de travail et fonctionnalités.
Pour plus d’informations sur le modèle de crédit d’UC de la Série B d’Azure, consultez les Instances Burstable Série B et Modèle de crédit d’UC de la Série B.
Analyser les crédits d’UC du niveau Burstable
La supervision de votre solde de crédits de processeur est essentielle pour maintenir des performances optimales au niveau de calcul Burstable. Le serveur flexible Azure Database pour MySQL fournit deux mesures clés liées aux crédits de processeur. Le seuil idéal pour déclencher une alerte dépend de vos exigences en matière de charge de travail et de niveau de performance.
Analyser Azure Database pour MySQL - Serveur flexible : cette métrique indique le nombre de crédits d’UC utilisés par votre instance. Analyser cette métrique peut vous aider à comprendre les modèles d’utilisation de l’UC de votre instance et à gérer efficacement son niveau de performance.
Analyser Azure Database pour MySQL - Serveur flexible : cette métrique affiche le nombre de crédits d’UC restants pour votre instance. Analyser cette métrique peut vous aider à empêcher une dégradation du niveau de performance de votre instance en raison de l’épuisement de ses crédits d’UC. Si la mesure Crédit du processeur restant tombe en dessous d’un certain niveau (par exemple, moins de 30 % du total des crédits disponibles), cela indique que l’instance risque d’épuiser ses crédits de processeur si la charge actuelle du processeur se maintient.
Pour plus d’informations, sur la configuration des alertes sur les métriques, reportez-vous à ce guide.
Stockage
Le stockage que vous approvisionnez est la capacité de stockage disponible pour votre serveur flexible. Le stockage est utilisé pour les fichiers de base de données, les fichiers temporaires, les journaux d’activité de transaction, et les journaux d’activité du serveur MySQL. Pour les niveaux de service Burstable et Usage général, la plage de stockage s’étend d’un minimum de 20 Gio à un maximum de 16 Tio. La prise en charge du stockage s’étend par contre jusqu’à 32 Tio pour le niveau de service Critique pour l’entreprise. Dans tous les niveaux de service, le stockage est mis à l’échelle par incréments de 1 Gio et un scale-up peut être effectué après la création du serveur.
Remarque
Le stockage peut seulement monter en puissance.
Vous pouvez surveiller votre consommation de stockage dans le portail Azure (avec Azure Monitor) à l’aide des métriques de limite de stockage, de pourcentage de stockage et de stockage utilisé. Reportez-vous à l’article sur la surveillance pour en savoir plus sur les métriques.
Atteindre la limite de stockage
Lorsque le stockage utilisé sur le serveur est proche de la limite approvisionnée, le serveur est mis en mode lecture seule pour empêcher de perdre des écritures sur le serveur. Les serveurs avec moins de 100 Gio de stockage approvisionnés sont marqués en lecture seule si l’espace de stockage libre est inférieur à 5 % de la taille de stockage approvisionnée. Les serveurs avec plus de 100 Gio de stockage approvisionnés sont marqués en lecture seule lorsque l’espace de stockage libre est inférieur à 5 Gio.
Par exemple, si vous avez approvisionné 110 Gio de stockage et que l’utilisation réelle dépasse 105 Gio, le serveur est marqué en lecture seule. Sinon, si vous avez provisionné 5 Gio de stockage, le serveur est marqué en lecture seule quand le stockage disponible est inférieur à 256 Mo.
Pendant que le service tente de marquer le serveur en lecture seule, toutes les nouvelles requêtes de transactions en écriture sont bloquées et les transactions actives existantes continuent à être exécutées. Lorsque le serveur est défini sur lecture seule, toutes les opérations d’écriture et les validations de transaction suivantes échouent, mais les requêtes en lecture continuent de fonctionner sans interruption.
Pour sortir le serveur du mode lecture seule, vous devez augmenter le stockage approvisionné sur le serveur. Pour ce faire, vous pouvez utiliser le portail Azure ou Azure CLI. Une fois augmenté, le serveur est prêt à accepter de nouvelles transactions d’écriture.
Nous vous recommandions de configurer une alerte pour vous avertir quand votre serveur de stockage est proche du seuil afin d’éviter la mise en lecture seule. Pour plus d’informations, consultez la documentation sur comment configurer une alerte.
Croissance automatique de stockage
La croissance automatique du stockage permet à votre serveur de disposer en permanence d’un espace de stockage suffisant et de ne pas passer en lecture seule. Si la croissance automatique du stockage est activée, le stockage augmente automatiquement sans affecter la charge de travail. La croissance automatique du stockage est activée par défaut pour tous les serveurs créés. Pour les serveurs avec moins de 100 Go de stockage provisionnés, la taille de stockage provisionné augmente de 5 Go quand l’espace de stockage libre est inférieur à 10 % de la taille de stockage provisionné. Pour les serveurs avec plus de 100 Go de stockage approvisionnés, la taille de stockage approvisionnée augmente de 5 % lorsque l’espace de stockage libre est inférieur à 10 Go de taille de stockage approvisionnée. Les limites de stockage maximales indiquées ci-dessus s’appliquent. Actualisez l’instance de serveur pour voir l’approvisionnement du stockage mis à jour sous Paramètres sur la page Calcul + stockage.
Par exemple, si vous avez approvisionné 1000 Go de stockage et que l’utilisation réelle dépasse 990 Go, la taille de stockage du serveur est augmentée à 1050 Go. De même, si vous avez approvisionné 20 Go de stockage, la taille de stockage est augmentée à 25 Go lorsque moins de 2 Go du stockage est libre.
N’oubliez pas qu’il est impossible d’effectuer un scale-down du stockage une fois que le scale-up automatique a été configuré.
Remarque
La croissance automatique du stockage est activée par défaut pour un serveur configuré à haute disponibilité, et ne peut pas être désactivée.
D’OPÉRATIONS D’E/S PAR SECONDE
Le serveur flexible Azure Database pour MySQL prend en charge les IOPS pré-approvisionnés et les IOPS de mise à l’échelle automatique. IOPS de stockage dans Azure Database pour MySQL - Serveur flexible : le nombre minimal d’IOPS est de 360 sur toutes les tailles de calcul, et le nombre maximal d’IOPS est déterminé par la taille de calcul sélectionnée. Pour en savoir plus sur le nombre maximal d’IOPS par taille de calcul, consultez le tableau.
Important
**Le nombre minimal d’E/S par seconde est de 360 pour toutes les tailles de calcul
**Le nombre maximal d’E/S par seconde est déterminé par la taille de calcul sélectionnée.
Vous pouvez analyser votre consommation d’E/S dans le Portail Azure (avec Azure Monitor) en utilisant la métrique Analyser Azure Database pour MySQL - Serveur flexible. Vous devez mettre à l’échelle le calcul de votre serveur si vous avez besoin de plus d’IOPS que le nombre maximal d’IOPS basé sur le calcul.
IOPS par seconde préconfigurées
Azure Database pour MySQL serveur flexible offre des IOPS préconfigurées, ce qui vous permet d’allouer un nombre spécifique d’IOPS à votre instance de serveur flexible Azure Database pour MySQL. Ce paramètre garantit des performances cohérentes et prévisibles pour vos charges de travail. Avec les IOPS préconfigurées, vous pouvez définir une limite d’IOPS spécifique pour votre volume de stockage, garantissant ainsi la capacité à gérer certaines requêtes par seconde. Cela se traduit par un niveau de performance fiable et garanti. Les IOPS pré-approvisionnés vous permettent d’approvisionner des IOPS supplémentaires au-dessus de la limite d’E/S par seconde. À l’aide de cette fonctionnalité, vous pouvez augmenter ou diminuer à tout moment le nombre d’IOPS approvisionnées en fonction des exigences de votre charge de travail.
Mise à l’échelle automatique des E/S par seconde
La pierre angulaire du serveur flexible Azure Database pour MySQL est sa capacité à obtenir les meilleures performances pour les charges de travail de Niveau 1. Cela peut être amélioré en permettant au serveur de mettre automatiquement à l’échelle le niveau de performance de ses serveurs de base de données en toute fluidité, en fonction des besoins de la charge de travail. Cette fonctionnalité par adhésion permet aux utilisateurs de mettre à l’échelle les IOPS à la demande, sans avoir à pré-approvisionner une certaine quantité d’E/S par seconde. Avec la fonctionnalité de mise à l’échelle automatique des IOPS activée, vous pouvez désormais profiter sans souci de la gestion des E/S dans le serveur flexible Azure Database pour MySQL, car le serveur met à l’échelle les IOPS, à la hausse ou à la baisse, de manière automatique, en fonction des besoins de charge de travail. Les IOPS de mise à l’échelle automatique font automatiquement l’objet d’un scale-up jusqu’au « Nombre maximal d’IOPS pris en charge » pour chaque niveau de service et chaque taille de calcul, comme spécifié dans la documentation sur les niveaux de service. Cela garantit des performances optimales sans les efforts liés à la mise à l’échelle manuelle.
Grâce à la mise à l’échelle automatique des IOPS, vous ne payez que pour les E/S que le serveur utilise et n’avez plus besoin d’approvisionner et de payer des ressources qui ne sont pas entièrement utilisées, ce qui permet de gagner du temps et de l’argent. En outre, les applications stratégiques de Niveau 1 peuvent obtenir des performances constantes en rendant des E/S supplémentaires disponibles pour la charge de travail à tout moment. La mise à l’échelle automatique des E/S par seconde élimine l’administration requise pour fournir les meilleures performances au moindre coût pour les clients de serveur flexible Azure Database pour MySQL.
Mise à l’échelle dynamique : la mise à l’échelle automatique des IOPS ajuste dynamiquement la limite d’IOPS de votre serveur de base de données en fonction de la demande réelle de votre charge de travail. Cela garantit un niveau de performance optimales sans intervention ou configuration manuelle.
Gérer les pics de charge de travail: la mise à l’échelle automatique des IOPS permet à votre base de données de gérer en toute fluidité les pics de charge de travail ou les fluctuations, sans compromettre le niveau de performance de vos applications. Cette fonctionnalité garantit une réactivité cohérente même pendant les périodes d’utilisation maximales.
Économies : contrairement aux IOPS pré-approvisionnées, où une limite d’IOPS fixe est spécifiée et payée indépendamment de l’utilisation, la mise à l’échelle automatique des IOPS vous permet de ne payer que le nombre d’opérations d’E/S que vous utilisez.
Sauvegarde
Le service sauvegarde automatiquement votre serveur. Vous pouvez sélectionner une période de rétention comprise entre 1 et 35 jours. Pour plus d’informations sur les sauvegardes, consultez cet article sur les concepts de sauvegarde et de restauration.
Mettre les ressources à l’échelle
Après avoir créé votre serveur, vous pouvez modifier de manière indépendante le niveau de calcul, la taille de calcul (cœurs virtuels et mémoire), la quantité de stockage et la durée de rétention de sauvegarde. La taille de calcul peut être mise à l’échelle, à la hausse ou à la baisse, et il en va de même pour la période de rétention de sauvegarde, de 1 à 35 jours. La taille de stockage ne peut être qu’augmentée. La mise à l’échelle des ressources peut être effectuée par le biais du portail ou d’Azure CLI.
Remarque
La taille de stockage ne peut être qu’augmentée. Vous ne pouvez pas revenir à une taille de stockage inférieure après l’augmentation.
Lorsque vous modifiez le niveau de calcul ou la taille de calcul, le serveur doit être redémarré pour que le nouveau type de serveur prenne effet. Pendant que le système bascule vers le nouveau serveur, aucune nouvelle connexion ne peut être établie, et toutes les transactions non validées sont restaurées. Cette fenêtre varie, mais dans la plupart des cas elle est comprise entre 60 et 120 secondes.
La mise à l’échelle du stockage et la modification de la période de rétention de la sauvegarde sont des opérations en ligne et ne nécessitent pas de redémarrage du serveur.
Prix
Pour obtenir les dernières informations sur la tarification, veuillez consulter le service Page de tarification. Pour voir le coût de la configuration souhaitée, le Portail Azure affiche le coût mensuel dans l’onglet Calcul et stockage selon les options que vous avez sélectionnées. Si vous n’avez pas d’abonnement Azure, vous pouvez utiliser la calculatrice de prix Azure pour obtenir une estimation. Pour personnaliser les options, sur le site web Calculatrice de prix d’Azure, sélectionnez Ajouter des éléments, développez la catégorie Bases de données, sélectionnez Azure Database pour MySQL, puis Serveur flexible comme type de déploiement pour personnaliser les options.
Si vous souhaitez optimiser le coût serveur, vous pouvez prendre en compte les conseils suivants :
- Réduisez le niveau de calcul ou la taille de calcul (vCores) si le calcul est sous-exploité.
- Envisagez de basculer vers un niveau de calcul Burstable si votre charge de travail n’a pas besoin de la capacité de calcul complète en continu à partir des niveaux Usage général et Critique pour l’entreprise.
- Arrêtez le serveur lorsqu’il n’est pas en cours d’utilisation.
- Réduisez la période de rétention des sauvegardes si une rétention de sauvegarde plus longue n’est pas nécessaire.