Bonnes pratiques de configuration d'une instance Cloud SQL pour MySQL
Bien que vous puissiez déployer MySQL manuellement sur votre propre machine physique ou même sur une machine virtuelle, et choisir de le gérer vous-même, une option de plus en plus populaire consiste à utiliser une offre gérée issue d'un fournisseur de services cloud, qui prend en charge les nombreux aspects opérationnels de la gestion de MySQL.
Articles associés
Bonnes pratiques
Cloud SQL pour MySQL est un service de base de données entièrement géré qui vous aide à configurer, maintenir, gérer et administrer vos bases de données relationnelles MySQL sur Google Cloud. Lorsque vous êtes prêt à créer une instance Cloud SQL pour MySQL, vous disposez de plusieurs options, y compris la console d'interface utilisateur, gcloud CLI, Terraform et une API REST. Vous pouvez consulter notre documentation pour en savoir plus sur chacune de ces solutions. Toutefois, pour les besoins de cet article, nous utiliserons l'interface utilisateur à des fins de démonstration tandis que nous aborderons diverses bonnes pratiques de configuration d'instance.
Informations sur l'instance
Choisir un mot de passe suffisamment sécurisé
Il s'agit du mot de passe de l'utilisateur par défaut de la base de données "root"@"%" qui sera créé avec l'instance. Si vous souhaitez conserver l'utilisateur racine en tant qu'administrateur, assurez-vous de choisir un mot de passe sécurisé. Pour des raisons de sécurité, nous vous conseillons de faire appel à un administrateur peu courant plutôt qu'à un utilisateur "root". Veuillez consulter la section "Gérer les utilisateurs de la base de données".
Créer une règle de mot de passe au niveau de l'instance
La fonctionnalité de règles relatives aux mots de passe permet de renforcer la sécurité de la base de données. Elle vous permet de configurer des règles concernant la longueur, la complexité, l'expiration et la réutilisation restreinte de mots de passe. Pour en savoir plus, consultez la page Renforcer une instance MySQL.
Version de la base de données
Envisager la version 8.0 pour améliorer vos performances
Cloud SQL MySQL est compatible avec plusieurs versions mineures 8.0, v8.0.26 étant la version par défaut actuelle. Les tests d'analyse comparative portant sur différents types de machines montrent un meilleur débit de requêtes avec la version par défaut 8.0 par rapport aux versions 5.7 et 5.6.
N'associez pas votre instance de production à la dernière version en disponibilité générale
Malgré tous les efforts de test réalisés par Oracle et Cloud SQL, les versions actualisées de MySQL ne sont pas entièrement approuvées dans des scénarios réels complexes. Nous vous recommandons donc de garder vos instances de production sur une version stable, et d'utiliser vos instances de développement et de préproduction pour tester les dernières mises à niveau de versions mineures dans Cloud SQL pour MySQL.
Haute disponibilité
Configurer plusieurs zones pour votre instance de production
Cloud SQL pour MySQL offre comme solution de haute disponibilité la disponibilité régionale par basculement automatique vers une deuxième zone. Pour optimiser la disponibilité, configurez l'option sur plusieurs zones pour les instances de production afin d'obtenir automatiquement des sauvegardes quotidiennes et une récupération à un moment précis (consultez la section "Planning des sauvegardes" pour en savoir plus).
Type de machine
Évaluer votre utilisation actuelle du processeur et de la mémoire pour prendre des décisions éclairées concernant la migration.
Lors de la migration d'une instance existante vers Cloud SQL, votre charge de travail actuelle peut vous aider à choisir la taille de VM appropriée.
- Processeur : quelle est l'utilisation de votre processeur dans des conditions de charge de travail normales ? Et pendant le pic de charge de travail ? L'instance est-elle liée au processeur ou aux E/S ? Si le pourcentage d'utilisation du processeur de l'utilisateur et/ou du système est relativement élevé, cela indique une charge de travail liée au processeur. Si le pourcentage d'E/S est relativement élevé, cela indique une charge de travail liée aux E/S.
- Mémoire : de même, quelle est l'utilisation normale de la mémoire de l'instance, et l'utilisation maximale ?
À titre de référence, 1 processeur virtuel dans Cloud SQL pour MySQL peut gérer jusqu'à 6,5 Go de mémoire.
Prévoir 20 à 50 % d'espace supplémentaire pour le processeur et la mémoire
Même dans une instance généralement stable, prévoyez au moins 20 % d'espace supplémentaire pour que le processeur et la mémoire puissent absorber les pics non planifiés. C'est d'autant plus important pour une entreprise en pleine croissance ; prévoyez dans ce cas une augmentation de 50 %.
Cloud SQL facilite la mise à niveau de votre type de machine. Notez simplement qu'une mise à niveau entraîne un temps d'arrêt.
Personnaliser l'espace de stockage
Utiliser des disques SSD pour améliorer les performances de la base de données
Cloud SQL pour MySQL propose l'option de stockage HDD, plus économique, mais si vous avez besoin d'une base de données hautes performances, optez pour l'option SSD. Voici une comparaison des performances d'E/S.
Prévoir d'équilibrer les performances et les coûts en termes de capacité de stockage
Les IOPS et le débit des disques sont liés à la taille du disque persistant. Une capacité plus élevée augmente le nombre d'IOPS et le débit dans la limite de l'instance.
Pour les disques SSD, les configurations zonales et régionales affecteront les performances. Pour en savoir plus, consultez la section Données sur les performances des disques SSD zonaux et régionaux. Si vous avez sélectionné la disponibilité dans plusieurs zones, reportez-vous aux données sur les performances des disques SSD régionaux. En bref, le nombre d'IOPS en lecture et en écriture s'élève à 30 par Go, et le débit à 0,48 Mo par Go. Avec les disques SSD régionaux, les données de performances sont similaires, sauf que le nombre d'IOPS et le débit en écriture par instance sont plus faibles.
Notez que la taille de stockage maximale acceptée est de 64 To sur une instance Cloud SQL.
Activer l'augmentation automatique de l'espace de stockage et surveiller la croissance du disque
Cloud SQL dispose d'une fonctionnalité d'augmentation automatique de l'espace de stockage pour éviter que les instances ne manquent d'espace disque (OOD). Lorsque la fonctionnalité est activée, le stockage est vérifié toutes les 30 secondes, et une capacité de stockage incrémentielle est ajoutée si nécessaire.
Bien que cette fonctionnalité vous protège contre le mode ODD, la capacité accrue est permanente : vous ne pourrez plus réduire la taille de votre instance. Commencez par configurer des alertes sur la taille de votre disque afin de pouvoir gérer et planifier la capacité de stockage.
Se familiariser avec les options de chiffrement
Par défaut, Cloud SQL chiffre les données au repos. Toutefois, il est possible d'utiliser une clé de chiffrement gérée par le client (CMEK) au lieu de la clé par défaut gérée par Google, si cela répond mieux à vos besoins.
Configurer les connexions
Évaluer le compromis entre adresse IP privée et adresse IP publique
Les adresses IP privées et publiques font référence aux types d'adresses utilisés par les appareils d'un réseau. L'adresse IP privée offre une meilleure sécurité réseau et une latence réseau inférieure à celle de l'adresse IP publique. Toutefois, une adresse IP privée nécessite des configurations supplémentaires pour l'API et IAM, et parfois une adresse IP publique. Si vous savez que vous avez besoin d'une adresse IP publique, mais que vous souhaitez renforcer la sécurité, vous pouvez choisir d'utiliser un réseau autorisé ou le proxy d'authentification Cloud SQL.
Envisager d'utiliser le proxy d'authentification Cloud SQL pour les connexions sécurisées
Le proxy d'authentification Cloud SQL fournit un accès sécurisé à l'instance Cloud SQL au lieu de configurer SSL ou les réseaux autorisés. L'application communique avec le client du proxy d'authentification, qui s'exécute dans l'environnement local et utilise un tunnel sécurisé pour communiquer avec le serveur proxy sur l'instance Cloud SQL.
Configurer le planning de sauvegarde et la conservation
Activez les sauvegardes et la récupération à un moment précis, puis examinez votre règle de conservation
Des sauvegardes régulières des données et une récupération vérifiable des données sont essentielles à une gestion de base de données saine. Ces pratiques sont très utiles dans des situations telles que la corruption de données ou les opérations de données inattendues, qui ne peuvent être compensées par la haute disponibilité.
Cloud SQL propose des sauvegardes automatisées, la validation des sauvegardes et la récupération à un moment précis (PITR). Ces options sont activées par défaut et requises sur les instances comprenant plusieurs zones. Des sauvegardes automatiques sont effectuées quotidiennement. La règle de conservation par défaut est définie sur sept copies des sauvegardes et sept jours de journaux binaires (obligatoire pour la récupération à un moment précis). Vous pouvez ajuster la règle de conservation dans la section "Options avancées".
Configurer des options de base de données
Les options de base de données sont des configurations de serveur qui redirigent vers le fichier my.cnf. Il existe une liste d'options de base de données configurables, mais certaines options gérées ne sont pas configurables. Nous vous recommandons d'examiner les options de base de données et de les configurer sur la valeur appropriée au moment de la création de l'instance. Étant donné que certaines options de base de données ne sont pas dynamiques, leur modification déclenchera un redémarrage de l'instance.
Vérifier character_set_server
Sur les instances Cloud SQL pour MySQL, la valeur de character_set_server par défaut est utf8 sur les versions 5.6 et 5.7, et utf8mb4 sur les versions 8.0. La variable character_set_server définit character_set_client, character_set_connection, character_set_database et character_set_results sur la même valeur. La valeur de character_set_system, est définie par défaut sur utf8mb3 pour les versions 8.0.
Si vous migrez une instance et que la configuration actuelle utilise un jeu de caractères différent (par exemple, latin1), assurez-vous de définir explicitement character_set_server sur la nouvelle instance.
Vérifier time_zone
Le fuseau horaire par défaut est system_time_zone (UTC). Si vous souhaitez utiliser un autre fuseau horaire, définissez-le via default_time_zone. Cette option utilise deux formats : le décalage horaire (par exemple, +08:00) et le nom du fuseau horaire (par exemple, America/Los_Angeles). Lorsque le fuseau horaire est défini par un nom de fuseau horaire, il s'adapte automatiquement à l'heure d'été (le cas échéant). L'option default_time_zone n'est pas dynamique et sa modification nécessite un redémarrage de l'instance de base de données.
Activer le journal des requêtes lentes
Par défaut, l'option slow_query_log est désactivée. Nous vous recommandons vivement d'activer le journal des requêtes lentes et de définir long_query_time sur un seuil pertinent pour l'application. Le journal des requêtes lentes permet de capturer les requêtes de longue durée à des fins d'analyse et d'optimisation. Ces informations facilitent non seulement les requêtes individuelles, mais aussi le débit global du serveur et l'analyse rétrospective des charges de travail inattendues.
Examiner innodb_buffer_pool_size
Il s'agit de la configuration la plus efficace pour les performances InnoDB. Plus la quantité de données pouvant être mise en mémoire tampon est élevée, meilleures seront les performances du serveur. Dans le même temps, il doit y avoir suffisamment de mémoire réservée pour les tampons globaux et les tampons dynamiques par thread.
Dans Cloud SQL, les valeurs par défaut, et les valeurs minimale et maximale autorisées de l'option innodb_buffer_pool_size dépendent de la mémoire de l'instance, comme décrit dans la documentation.
Une bonne valeur de innodb_buffer_pool_size ne doit pas nécessairement contenir toutes les données, mais uniquement les données fréquemment consultées. Les variables d'état qui reflètent l'efficacité du pool de mémoire tampon sont Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests. Innodb_buffer_pool_read_requests correspond au nombre de requêtes de lecture logiques, et Innodb_buffer_pool_reads au nombre de lectures logiques non satisfaites à partir du pool de mémoire tampon et qui doivent être lues à partir du disque. Dans l'idéal, dans le cas où les données sont entièrement dans le pool de mémoire tampon, le ratio Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests est proche de zéro. La surveillance de ces variables donnerait une idée de l'efficacité du pool de mémoire tampon InnoDB. Si innodb_buffer_pool_size est définie sur la valeur maximale autorisée, que l'efficacité du pool de mémoire tampon n'est pas bonne et que l'application souffre de problèmes de performances des requêtes, envisagez de mettre à niveau votre instance de sorte à augmenter le volume de la mémoire.
Cette variable devient dynamique dans MySQL versions 5.7 et 8.0, tandis que dans la version 5.6, un redémarrage de l'instance est nécessaire pour modifier la variable.
Vérifier innodb_log_file_size
Avant la version 8.0.30, innodb_log_file_size et innodb_log_files_in_group n'étaient pas dynamiques, et la modification de innodb_log_file_size nécessitait un arrêt normal. Dans la version 8.0.30, innodb_redo_log_capacity a été introduit pour remplacer innodb_log_file_size et innodb_log_files_in_group.
Les instances Cloud SQL pour MySQL sont configurées avec innodb_log_file_size= 512 Mo, innodb_log_files_in_group= 2 (ou innodb_redo_log_capacity= 1 Go). InnoDB peut ainsi appliquer davantage de modifications au pool de mémoire tampon sans effectuer de synchronisation sur le disque, ce qui améliore les performances du serveur. L'inconvénient des fichiers journaux de rétablissement volumineux réside dans le fait que le temps de récupération après plantage est plus long. En fonction des exigences et de la configuration de la haute disponibilité de l'instance, cette décision nécessite un équilibre entre performances et disponibilité.
En règle générale, nous vous recommandons de disposer de fichiers journaux de rétablissement suffisamment volumineux pour occuper une heure d'activités d'écriture. Une façon d'évaluer cela consiste à observer Innodb_os_log_written sur une journée, puis à s'assurer que la valeur de innodb_log_file_size * innodb_log_files_in_group est suffisamment élevée pour l'heure de pointe observée.
Vérifier innodb_log_buffer_size
Dans MySQL v5.6 et v5.7, innodb_log_buffer_size n'est pas dynamique, et toute modification nécessite un redémarrage de l'instance. Par conséquent, il est préférable de le définir lors de l'initialisation.
Lorsque la valeur de innodb_log_buffer_size est suffisamment élevée pour contenir l'intégralité de la transaction, il n'y a pas de vidage supplémentaire sur le disque pendant l'exécution de la transaction. Par défaut, la valeur innodb_log_buffer_size est définie sur 16 Mo, ce qui est généralement suffisant. Toutefois, pour savoir si une transaction volumineuse peut nécessiter un tampon plus important, surveillez la variable d'état Innodb_log_waits lorsque vous émettez une transaction volumineuse. Si la valeur de innodb_log_buffer_size est trop petite et doit attendre un vidage, la valeur de Innodb_log_waits augmentera de un.
Ajuster les variables dynamiques au fur et à mesure
Certaines options de base de données liés aux performances sont dynamiques, par exemple table_open_cache et thread_cache_size. Il est préférable de commencer par choisir la taille appropriée, mais nous vous recommandons d'établir les mesures et de les ajuster si nécessaire.
table_open_cache correspond au nombre de tables ouvertes. Un cache suffisant permet de réduire le temps d'ouverture des tables, et donc d'améliorer les performances des requêtes. La variable d'état Opened_tables indique le nombre de tables qui ont été ouvertes. Si la valeur de Opened_tables ne cesse de croître, envisagez d'augmenter la valeur de table_open_cache.
thread_cache_size permet de mettre en cache les threads à réutiliser après la déconnexion des clients. Si une instance attend beaucoup de nouvelles connexions simultanées, définissez une taille plus importante. Le ratio des variables d'état Threads_created et des connexions indique l'efficacité du cache des threads. Un ratio faible est préférable.
Soyez prudent avec les options de mémoire par thread
Il existe des tampons de mémoire par thread qui affectent les performances des requêtes. Par exemple :tmp_table_size, max_heap_table_size, join_buffer_size, sort_buffer_size, etc. Ces variables ont un champ d'application global et une portée session. Le champ d'application global définit la valeur par thread pour toutes les nouvelles connexions, tandis que la portée de session est effectif pour les requêtes suivantes dans la session en cours. Une mémoire plus importante pour des paramètres comme ceux-ci permet d'améliorer les performances des requêtes. Toutefois, comme ils sont dynamiques et allouent un ou plusieurs threads, ils peuvent entraîner des scénarios de mémoire saturée (OOM, Out Of Memory).
Il est préférable d'utiliser des nombres modérés pour les valeurs globales et de réserver les nombres plus élevés à des sessions spécifiques afin d'obtenir de meilleures performances de manière contrôlée.
Envisager d'utiliser performance_schema
La variable performance_schema est désactivée par défaut avant MySQL 8.0.26 et son activation nécessite un redémarrage. La variable performance_schema permet diverses instrumentations et fournit un riche ensemble de données pour l'analyse des opérations du serveur, mais entraîne des coûts de mémoire et de performances. Les instrumentations par défaut génèrent des baisses de performances d'environ 5 %, et ce chiffre augmente à mesure que des instruments sont ajoutés. Effectuez des analyses comparatives des instrumentations avec votre charge de travail, car la consommation de mémoire peut atteindre 1 Go ou plus. Vous pouvez observer cette consommation de mémoire dans la table memory_summary_global_by_event_name.
Gérer les utilisateurs de bases de données
Une fois l'instance Cloud SQL créée, un utilisateur de base de données est disponible : "root'@'%". Vous devrez probablement créer des utilisateurs de base de données supplémentaires.
Limiter l'accès des utilisateurs aux opérations requises
Limitez toujours l'accès des utilisateurs au minimum requis.
Lorsque vous créez un utilisateur via la CLI de MySQL, vous devez explicitement lui accorder des droits.
Un utilisateur créé via la console Cloud dispose des mêmes droits que l'utilisateur "root’@’%". Dans MySQL v5.6 et v5.7, les droits par défaut incluent tous les droits avec l'option d'attribution, à l'exception des droits SUPER et FILE. Dans la version 8.0, l'utilisateur dispose de droits dynamiques. Bien que les droits SUPER et FILE demeurent restreints, d'autres rôles d'administrateur sont disponibles (par exemple, APPLICATION_PASSWORD_ADMIN, CONNECTION_ADMIN, ROLE_ADMIN, SET_USER_ID et XA_RECOVER_ADMIN). Vous devrez révoquer tous les droits inutiles via la CLI de MySQL. Sur les instances 8.0, la variable partial_revokes est activée.
Envisager de remplacer "root'@'%" par un administrateur spécifique
L'utilisateur "root'@'%" est le super-utilisateur par défaut le plus populaire. Il est donc souvent ciblé par des pirates informatiques. Nous vous recommandons de créer vos propres administrateurs avec le même ensemble de droits que l'utilisateur "root'@'%", puis de remplacer ce dernier pour renforcer la sécurité.
Configurer la surveillance
Il est très important de surveiller et de suivre divers aspects des opérations de base de données et des ressources système. Cela vous permet d'examiner et d'analyser l'état opérationnel de votre instance au fil du temps, ce qui peut également vous aider à planifier les ressources.
- La page de présentation de la console Cloud contient une liste de métriques de base.
- Cloud Monitoring propose des métriques supplémentaires. Vous pouvez créer un tableau de bord avec les métriques sélectionnées pour vos instances de base de données. Dans la console Cloud, dans le menu de navigation en haut à gauche, sélectionnez OPÉRATIONS --> Monitoring pour accéder à Cloud Monitoring.
- Utilisez les insights sur les requêtes dans Cloud SQL pour analyser les performances des requêtes. Sa section d'aperçu affiche la charge du processeur divisée par adresse de base de données, d'utilisateur ou de client. L'utilisation du processeur est également ventilée selon le temps d'attente d'E/S et de verrouillage. La section répertorie également les requêtes les plus fréquentes par condensé de requête. Pour chaque condensé de requête, vous pouvez voir la durée d'exécution moyenne, le nombre de requêtes et le nombre moyen de lignes analysées et renvoyées. Ces métriques sont très utiles pour identifier les points chauds et les requêtes à optimiser.
- Vous pouvez également compléter les éléments ci-dessus avec des outils de surveillance développés par nos soins et/ou des outils tiers. L'objectif principal est de comprendre les opérations de base de données qui peuvent influencer à la fois l'optimisation et le dépannage des requêtes et des serveurs.
Configurer les alertes
Des alertes appropriées sont essentielles pour préserver l'état du serveur. Elles permettent d'éviter les interruptions de service, telles que la saturation de la mémoire ou les blocages du système dus à la saturation du processeur.
Si vous utilisez Cloud Monitoring, vous pouvez créer des alertes basées sur des métriques. Pour en savoir plus, consultez la documentation.
Si vous utilisez d'autres outils de surveillance, veillez à configurer les alertes.
Configurer des instances répliquées
Pour effectuer un scaling des lectures, envisagez d'ajouter des instances répliquées avec accès en lecture. Vous pouvez utiliser HAProxy, ProxySQL ou un autre équilibreur de charge pour répartir les lectures entre plusieurs instances répliquées avec accès en lecture.
Cloud SQL est également compatible avec la réplication en chaîne, que vous pouvez découvrir dans la section Instances répliquées en cascade.
Les instances répliquées avec accès en lecture sont créées avec la même version de MySQL que l'instance principale. Après la création, vous pouvez choisir de mettre à niveau l'instance répliquées vers l'instance principale.
Planifier la reprise après sinistre
La solution à haute disponibilité assure la redondance des données dans une zone secondaire de la même région. En cas de sinistre, une région peut devenir indisponible. Les instances répliquées interrégionales avec accès en lecture constituent une ressource fiable dans un plan de reprise après sinistre, car elles peuvent être promues en instance principale si nécessaire. Pour en savoir plus, consultez la documentation.
Produits et services associés
Google Cloud propose une base de données MySQL gérée conçue pour répondre aux besoins de votre entreprise, de la suppression de votre centre de données sur site à l'exécution d'applications SaaS, en passant par la migration de systèmes d'entreprise principaux.
