Partager via

Meilleures pratiques d’opérations serveur sur Azure Database pour MySQL : Serveur flexible

Découvrez les meilleures pratiques d’utilisation d’un serveur flexible Azure Database pour MySQL. Au fur et à mesure que nous ajouterons de nouvelles fonctionnalités à la plateforme, nous continuons de nous consacrer à affiner les meilleures pratiques décrites dans cette section.

Instructions opérationnelles sur le serveur flexible Azure Database pour MySQL

Vous trouverez ci-dessous les instructions opérationnelles à suivre pour utiliser un serveur flexible Azure Database pour MySQL en améliorant son niveau de performance :

  • Colocalisation : pour réduire le temps de réponse du réseau, placez le client et le serveur de base de données dans la même région Azure.

  • Surveiller l’utilisation de la mémoire, du processeur et du stockage : vous pouvez configurer des alertes pour savoir quand les modèles d’utilisation changent et quand vous approchez de la capacité de votre déploiement, dans l’objectif de maintenir le niveau de performance et la disponibilité du système.

  • Journaux accélérés pour des performances améliorées : l’activation de la fonctionnalité des journaux accélérés optimise les opérations liées aux journaux transactionnels, ce qui améliore le débit du serveur et les performances. Cette fonctionnalité, disponible sans coût supplémentaire, est un ajout significatif aux meilleures pratiques opérationnelles pour les utilisateurs du niveau de service Critique pour l’entreprise.

  • Effectuer un scale-up de votre instance de base de données : vous pouvez effectuer un scale-up lorsque vous approchez des limites de la capacité de stockage. Gardez une marge en matière de stockage et de mémoire pour gérer les augmentations imprévues de la demande de vos applications. Vous pouvez également activer la fonctionnalité de croissance automatique du stockage pour que le service mette automatiquement à l’échelle le stockage lorsqu’il approche de ses limites.

  • Configuration des sauvegardes : activez les sauvegardes locales ou géoredondantes selon l’exigence de l’entreprise. Modifiez également la période de rétention des sauvegardes en fonction de la durée nécessaire à la continuité d’activité.

  • Optimiser la capacité d’entrée/sortie avec la mise à l’échelle automatique des IOPS : si le volume d’E/S nécessaire à la charge de travail de la base de données est supérieur à ce qui a été provisionné, la récupération et d’autres opérations transactionnelles de la base de données seront lentes. Pour augmenter la capacité d’E/S d’une instance de serveur, procédez comme suit :

    • Utiliser la mise à l’échelle automatique des IOPS : la mise à l’échelle automatique des IOPS éliminent la nécessité de pré-approvisionner un nombre spécifique d’opérations d’E/S par seconde. Au lieu de cela, il permet à votre serveur d’ajuster automatiquement les IOPS en fonction des exigences de charge de travail. Cela signifie que votre serveur peut mettre à l’échelle les IOPS automatiquement en fonction des besoins de la charge de travail.

    • Le serveur flexible Azure Database pour MySQL assure la mise à l’échelle des IOPS à raison de trois IOPS par Go de stockage provisionné. Augmentez le stockage provisionné pour augmenter les IOPS et ainsi améliorer le niveau de performance.

    • Si vous utilisez déjà le stockage des IOPS approvisionnées, configurez une capacité de débit supplémentaire.

  • Mise à l’échelle du calcul : la charge de travail de la base de données peut également être limitée par le processeur ou la mémoire, ce qui risque d’avoir une sérieuse incidence sur le traitement transactionnel. Le calcul (niveau tarifaire) peut être uniquement augmenté ou réduit entre les niveaux Usage général et Mémoire optimisée.

  • Test de basculement : testez manuellement le basculement de votre instance de serveur afin de connaître la durée d’exécution du processus pour votre cas d’usage et de vérifier que l’application qui accède à votre instance de serveur peut se connecter automatiquement à la nouvelle instance après le basculement.

  • Utiliser la clé primaire : veillez à ce que vos tables comportent une clé primaire ou unique lorsque vous travaillez sur l’instance de serveur flexible Azure Database pour MySQL. La réalisation de sauvegardes, de réplicas, etc. s’en trouve grandement facilitée, et le niveau de performance amélioré.

  • Configuration de la valeur TTL : si votre application cliente met en cache les données DNS (Domain Name System) de vos instances de serveur, définissez une valeur de durée de vie (TTL) inférieure à 30 secondes. Étant donné que l’adresse IP sous-jacente d’une instance de serveur peut changer après un basculement, la mise en cache des données DNS pendant une période prolongée risque d’entraîner des échecs de connexion si l’application tente de se connecter à une adresse IP qui n’est plus en service.

  • Utilisez le regroupement de connexions pour éviter d’atteindre les limites de connexion maximales et suivez une logique de nouvelles tentatives pour éviter des problèmes de connexion intermittents.

  • Si vous avez recours à un réplica, utilisez ProxySQL pour équilibrer la charge entre le serveur principal et le serveur de réplication secondaire accessible en lecture. Consultez la procédure de configuration.

  • Lors de l’approvisionnement de la ressource, veillez à activer la croissance automatique sur votre instance de serveur flexible Azure Database pour MySQL. Cela n’ajoute aucun coût supplémentaire et protège la base de données contre les goulots d’étranglement de stockage que vous risquez de rencontrer.

Utiliser InnoDB avec un Serveur flexible Azure Database pour MySQL

  • La fonctionnalité ibdata1 consiste en un fichier de données tablespace système que l’on ne peut ni réduire ni vider en supprimant les données de la table ou en déplaçant la table vers file_per_table tablespaces.

  • Pour une base de données d’une taille supérieure à 1 To, créez la table dans innodb_file_per_tabletablespace. Dans le cas d’une table unique d’une taille supérieure à 1 To, utilisez la table partition.

  • Pour un serveur comportant un grand nombre de tablespace, le démarrage du moteur est très lent en raison de l’analyse séquentielle des tablespace qui a lieu pendant le démarrage ou le basculement du serveur flexible Azure Database pour MySQL.

  • Définissez innodb_file_per_table = ON avant de créer une table si le nombre total de tables est inférieur à 500.

  • Si votre base de données comporte plus de 500 tables, vérifiez individuellement la taille de chacune d’elles. Dans le cas d’une table volumineuse, envisagez toujours d’utiliser file_per_table tablespace pour éviter que le fichier tablespace système n’atteigne la limite de stockage maximale.

Notes

Pour les tables d’une taille inférieure à 5 Go, envisagez d’utiliser le tablespace système :

CREATE TABLE tbl_name ... *TABLESPACE* = *innodb_system*;

  • Partitionnez votre table lors de sa création si elle est volumineuse et susceptible de dépasser 1 To.

  • Utilisez plusieurs instances de serveur flexible Azure Database pour MySQL et répartissez les tables entre ces serveurs. Évitez de placer trop de tables sur un seul serveur si vous disposez d’environ 10 000 tables, voire plus.

Contenu connexe

  • Last updated on