Meilleures pratiques pour créer une application avec Azure Database pour MySQL

  • Article

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

Important

Azure Database pour MySQL serveur unique se trouve sur le chemin de mise hors service. Nous vous recommandons vivement de procéder à la mise à niveau vers Azure Database pour MySQL serveur flexible. Pour plus d’informations sur la migration vers Azure Database pour MySQL serveur flexible, consultez Ce qui se passe pour Azure Database pour MySQL serveur unique ?

Voici des exemples de meilleures pratiques pour créer une application cloud à l’aide d’Azure Database pour MySQL. En les suivant, vous pouvez réduire le temps de développement de votre application.

Configuration des ressources d’application et de base de données

Conserver l’application et la base de données dans la même région

Assurez-vous que toutes vos dépendances se trouvent dans la même région lors du déploiement de votre application dans Azure. La répartition des instances sur différentes régions ou zones de disponibilité crée une latence réseau, ce qui peut avoir un impact sur les performances globales de votre application.

Sécuriser votre serveur MySQL

Votre serveur MySQL doit être configuré pour être sécurisé et non accessible au public. Utilisez l’une des options suivantes pour sécuriser votre serveur :

Pour des raisons de sécurité, vous devez toujours vous connecter à votre serveur MySQL via SSL et configurer votre serveur MySQL et votre application pour utiliser TLS 1.2. Voir Configurer le protocole SSL.

Utiliser la mise en réseau avancée avec AKS

Lorsque la mise en réseau accélérée est activée sur une machine virtuelle, celle-ci bénéficie d’une latence plus faible, d’une diminution de l’instabilité et d’une utilisation moins importante du processeur. Pour en savoir plus, consultez Meilleures pratiques pour Azure Kubernetes Service et Azure Database pour MySQL.

Régler les paramètres de votre serveur

Pour les charges de travail intensives, le réglage des paramètres du serveur, tmp_table_size et max_heap_table_size, peut aider à optimiser les performances. Pour calculer les valeurs requises pour ces variables, examinez les valeurs totales des mémoires par connexion et de base. La somme des paramètres de mémoire par connexion, à l’exclusion de tmp_table_size, combinée à la mémoire de base, représente la mémoire totale du serveur.

Pour calculer la plus grande taille possible de tmp_table_size et max_heap_table_size, utilisez la formule suivante :

(total memory - (base memory + (sum of per-connection memory * # of connections)) / # of connections

Notes

Mémoire totale indique la quantité totale de mémoire dont dispose le serveur sur les vCores provisionnés. Par exemple, dans un serveur Azure Database pour MySQL avec deux vCores universel, la mémoire totale sera de 5 Go * 2. Vous trouverez plus de détails sur la mémoire pour chaque niveau de service dans la documentation relative aux niveaux tarifaires.

La mémoire de base indique les variables de mémoire, comme query_cache_size et innodb_buffer_pool_size, que MySQL initialise et alloue au démarrage du serveur. La mémoire par connexion, comme sort_buffer_size et join_buffer_size, correspond à la mémoire qui est allouée uniquement lorsqu’une requête en a besoin.

Créer des utilisateurs non-administrateurs

Créez des utilisateurs non-administrateurs pour chaque base de données. En règle générale, les noms des utilisateurs sont identifiés comme les noms des bases de données.

Réinitialiser votre mot de passe

Vous pouvez réinitialiser le mot de passe de votre serveur MySQL à l’aide du Portail Azure.

La réinitialisation du mot de passe de votre serveur pour une base de données de production peut rendre votre application inactive. Il est recommandé de réinitialiser le mot de passe pour toute charge de travail de production aux heures creuses afin de minimiser l’impact sur les utilisateurs de votre application.

Performance et résilience

Voici quelques outils et pratiques utiles pour déboguer les problèmes de performance de votre application.

Activer les journaux de requêtes lentes pour identifier les problèmes de performance

Vous pouvez activer les journaux de requêtes lentes et les journaux d’audit sur votre serveur. L’analyse de journaux de requêtes lentes peut aider à identifier les goulots d’étranglement en matière de performances, afin de les résoudre.

Les journaux d’audit sont également disponibles par le biais des journaux Diagnostics Azure dans les journaux Azure Monitor, Azure Event Hubs et les comptes de stockage. Consultez Guide pratique pour résoudre les problèmes de performances des requêtes.

Utiliser le regroupement de connexions

La gestion des connexions de base de données peut avoir un impact significatif sur les performances de l’application dans son ensemble. Pour optimiser les performances, vous devez réduire le nombre de fois où les connexions sont établies et la durée nécessaire à l’établissement des connexions dans les chemins de code clés. Utilisez le regroupement de connexions pour vous connecter à Azure Database pour MySQL afin d’améliorer la résilience et les performances.

Vous pouvez utiliser le regroupement de connexions ProxySQL pour gérer efficacement les connexions. L’utilisation d’une fonction de regroupement de connexions permet de réduire le nombre de connexions inactives et de réutiliser des connexions existantes afin d’éviter tout problème. Pour plus d’informations, consultez Configuration de ProxySQL.

Logique de nouvelle tentative pour traiter les erreurs temporaires

Votre application peut rencontrer des erreurs temporaires où les connexions à la base de données sont interrompues ou perdues par intermittence. Dans ce cas, le serveur est opérationnel après une ou deux nouvelles tentatives en 5 à 10 secondes.

Nous vous recommandons de patienter 5 secondes avant votre première nouvelle tentative. Ensuite, attendez progressivement plus longtemps entre chaque tentative, jusqu’à un délai de 60 secondes. Limitez le nombre maximal de nouvelles tentatives au-delà duquel votre application considère que l’opération a échoué. Vous pourrez ainsi poursuivre votre examen. Pour plus d’informations, consultez Comment résoudre les erreurs de connexion.

Activer le réplica en lecture pour atténuer les basculements

Pour les scénarios de basculement, vous pouvez utiliser la réplication des données entrantes. Aucun basculement automatique n'a lieu entre les serveurs source et réplica lors de l'utilisation de réplicas de lecture.

Vous remarquez un décalage entre le serveur source et le réplica, car la réplication est asynchrone. Le décalage du réseau dépend de nombreux facteurs, comme la taille de la charge de travail exécutée sur le serveur source et la latence entre les centres de données. Dans la plupart des cas, le décalage du réplica va de quelques secondes à quelques minutes.

Déploiement de base de données

Configurer une tâche Azure Database pour MySQL dans votre pipeline de déploiement CI/CD

Parfois, vous devez déployer des modifications dans votre base de données. Dans ce cas, vous pouvez utiliser l’intégration continue (CI) et la livraison continue (CD) via Azure Pipelines et utiliser une tâche pour votre serveur MySQL afin de mettre à jour la base de données en exécutant un script personnalisé.

Utiliser un processus efficace pour le déploiement manuel d’une base de données

Lors du déploiement manuel d’une base de données, suivez ces étapes pour minimiser le temps d’arrêt ou réduire le risque d’échec du déploiement :

  1. Créez une copie de la base de données de production sur une nouvelle base de données en utilisant mysqldump ou MySQL Workbench.
  2. Mettez à jour la nouvelle base de données avec vos nouvelles modifications de schéma ou les mises à jour nécessaires pour votre base de données.
  3. Placez la base de données de production en lecture seule. Il est préférable qu’aucune d’opération d’écriture ne soit présente sur la base de données de production tant que le déploiement n’est pas terminé.
  4. Testez votre application avec la base de données que vous venez de mettre à jour à l’étape 1.
  5. Déployez les modifications apportées à votre application et assurez-vous que l’application utilise désormais la nouvelle base de données avec les dernières mises à jour.
  6. Conservez l’ancienne base de données de production pour restaurer les modifications. Vous pouvez alors décider de supprimer l’ancienne base de données de production ou de l’exporter sur le Stockage Azure si nécessaire.

Notes

Si l’application est semblable à une application d’e-commerce et que vous ne pouvez pas la passer en lecture seule, déployez les modifications directement sur la base de données de production après avoir effectué une sauvegarde. Ces changements doivent avoir lieu pendant les heures creuses avec un faible trafic vers l’application afin de minimiser l’impact, car certains utilisateurs peuvent rencontrer des échecs de requêtes.

Assurez-vous que votre code d’application traite également toutes les requêtes ayant échoué.

Utiliser les métriques natives de MySQL pour déterminer si votre charge de travail dépasse la taille des tables temporaires en mémoire

Avec une charge de travail nécessitant beaucoup de lectures, les requêtes sur votre serveur MySQL peuvent dépasser la taille des tables temporaires en mémoire. Une charge de travail intensive en lecture peut amener votre serveur à passer à l’écriture de tables temporaires sur le disque, ce qui perturbe les performances de votre application. Pour déterminer si votre serveur écrit sur le disque en cas de dépassement de la taille des tables temporaires, examinez les métriques suivantes :

show global status like 'created_tmp_disk_tables';
show global status like 'created_tmp_tables';

La métrique created_tmp_disk_tables indique le nombre de tables qui ont été créées sur le disque. Compte tenu de votre charge de travail, la métrique created_tmp_table indique le nombre de tables temporaires qui doivent être formées en mémoire. Pour déterminer si une requête spécifique utilise des tables temporaires, exécutez l’instruction EXPLAIN sur la requête. Les détails de la colonne extra indiquent Using temporary si la requête s’exécute à l’aide de tables temporaires.

Pour calculer le pourcentage de votre charge de travail avec des requêtes débordant sur des disques, utilisez vos valeurs de métriques dans la formule ci-dessous :

(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100

Idéalement, ce pourcentage doit être inférieur à 25 %. Si le pourcentage est supérieur ou égal à 25 %, nous vous suggérons de modifier deux paramètres de serveur, tmp_table_size et max_heap_table_size.

Schéma de la base de données et requêtes

Voici quelques conseils à garder en tête lorsque vous concevez la structure de votre base de données et vos requêtes.

Utiliser le bon type de données pour les colonnes de votre table

En utilisant le type de données qui correspond aux données que vous souhaitez stocker, vous pouvez optimiser le stockage et réduire les erreurs causées par des types de données incorrects.

Utiliser des index

Pour éviter les requêtes lentes, vous pouvez utiliser des index. Les index permettent de trouver rapidement des lignes avec des colonnes spécifiques. Consultez Comment utiliser des index dans MySQL.

Utiliser l’instruction EXPLAIN sur vos requêtes SELECT

Utilisez l’instruction EXPLAIN pour obtenir des informations sur ce que MySQL fait pour exécuter votre requête. Cela peut vous aider à détecter les goulots d’étranglement ou les problèmes liés à votre requête. Voir Guide pratique pour utiliser l’instruction EXPLAIN visant à profiler les performances.