Bonnes pratiques

Cette page présente les bonnes pratiques pour optimiser la performance, la durabilité et la disponibilité de Cloud SQL.

En cas de problème avec votre instance Cloud SQL, veuillez prendre connaissance des points suivants lors du dépannage :

Configurer et administrer une instance

Bonne pratique En savoir plus
Lisez et suivez les consignes opérationnelles pour vous assurer que vos instances sont couvertes par le contrat de niveau de service Cloud SQL.
Configurez un intervalle de maintenance permettant à votre instance principale de contrôler à quel moment des mises à jour perturbatrices peuvent se produire. Consultez la page Intervalle de maintenance.
Pour les charges de travail intensives en lecture, ajoutez des instances dupliquées avec accès en lecture pour décharger le trafic de l'instance principale. Vous pouvez éventuellement utiliser un équilibreur de charge tel que HAProxy pour gérer le trafic vers les instances dupliquées.
Si vous supprimez et recréez régulièrement des instances, utilisez un horodatage dans l'ID d'instance pour augmenter les chances d'utilisation des nouveaux ID d'instances. Vous devez attendre quelques jours avant de pouvoir réutiliser l'ID d'une instance supprimée.
Ne démarrez pas une opération administrative avant la fin de l'opération précédente.

Les instances Cloud SQL n'acceptent pas une nouvelle requête d'opération avant d'avoir terminé l'opération précédente. Si vous essayez de démarrer prématurément une nouvelle opération, la requête d'opération échoue. Cela inclut les redémarrages d'instances.

L'état de l'instance dans Cloud Console ne permet pas de savoir si une opération est en cours d'exécution. La coche verte indique uniquement que l'instance est à l'état RUNNABLE. Pour savoir si une opération est en cours d'exécution, accédez à l'onglet Opérations et vérifiez l'état de la dernière opération.

Videz les tables système après les mises à jour. Les tables système MySQL (par exemple, mysql.user ou mysql.db) utilisent le moteur de stockage MyISAM. Ces tables sont vulnérables aux arrêts incorrects. Vous devez exécuter la commande FLUSH CHANGES après avoir modifié ces tables, par exemple en ajoutant ou en mettant à jour un utilisateur à l'aide du client mysql. Si MyISAM est corrompu et que l'instance peut redémarrer, vous pouvez utiliser les commandes CHECK TABLE et REPAIR TABLE pour tenter de résoudre le problème de corruption. Cependant, le contenu de la table peut ne pas être correct.

Architecture de données

Bonne pratique En savoir plus
Partitionnez vos instances si possible. Lorsque cela est possible, l'utilisation de nombreuses instances Cloud SQL plus petites est préférable à une instance de grande taille. La gestion d'une instance monolithique de grande taille présente des défis que ne posent pas des instances plus nombreuses et plus petites.
N'utilisez pas trop de tables de base de données.

Un trop grand nombre de tables de base de données peuvent influer sur le temps de réponse d'une instance. Par exemple, un nombre de tables supérieur à 10 000 aura une incidence sur la couverture de votre contrat de niveau de service. Pour en savoir plus, consultez la page Consignes opérationnelles.

Assurez-vous que vos tables ont une clé primaire ou unique. Cloud SQL utilise une réplication basée sur les lignes, qui fonctionne mieux sur les tables avec des clés primaires ou uniques.

Mise en œuvre de l'application

Bonne pratique En savoir plus
Utilisez de bonnes pratiques de gestion des connexions, telles que le regroupement de connexions et l'intervalle exponentiel. Ces techniques améliorent l'utilisation des ressources de votre application et vous aident à respecter les limites de connexion de Cloud SQL. Pour en savoir plus et pour obtenir des exemples de code, consultez la page Gérer les connexions à la base de données.
Testez la réponse de votre application aux mises à jour de maintenance qui peuvent se produire à tout moment pendant l'intervalle de maintenance. La modification du type de machine d'une instance est l'approche la plus semblable à une mise à jour de maintenance, sauf que lors d'une mise à jour de maintenance, l'instance dupliquée de basculement est mise à jour (et mise hors ligne) en premier. Une fois sa mise à jour terminée, l'instance principale est à son tour mise à jour (et mise hors ligne). Pour apporter des modifications au type de machine, l'instance principale est mise hors ligne avant l'instance dupliquée. Assurez-vous que l'application tente de se reconnecter à la base de données, en utilisant de préférence un intervalle exponentiel pendant au moins 10 minutes afin de vous assurer de bien retablir un fonctionnement normal après un événement de maintenance. Pour en savoir plus, consultez la page Gérer les connexions à la base de données.
Testez la réponse de votre application aux basculements qui peuvent se produire à tout moment. Vous pouvez déclencher un basculement manuellement à l'aide de Cloud Console, de l'outil de ligne de commande gcloud ou de l'API. Consultez la page Déclencher un basculement.
Évitez les transactions volumineuses. Effectuez de petites transactions. Si une base de données volumineuse doit être mise à jour, faites-le en plusieurs petites transactions plutôt qu'en une seule grosse transaction.
Si vous utilisez le proxy Cloud SQL, assurez-vous que vous employez la version la plus récente. Consultez la page Maintenir le proxy Cloud SQL à jour.

Importer et exporter des données

Bonne pratique En savoir plus
Accélérez les importations pour les petites instances. Pour les petites instances, vous pouvez temporairement augmenter le niveau d'une instance afin d'améliorer la performance en cas d'importation de grands ensembles de données.
Si vous exportez des données à importer dans Cloud SQL, veillez à suivre la procédure appropriée. Consultez la page Exporter des données à partir d'un serveur de base de données géré en externe.
Accélérez les importations en utilisant la commande mysqldump appropriée lors de l'exportation. Si vous utilisez l'utilitaire mysqldump pour exporter des données à importer dans Cloud SQL, envisagez les options suivantes :
  • Désactivez le commit automatique et encapsulez le fichier ou la table dans une transaction unique à l'aide de l'option --single-transaction.
  • Incluez de nombreuses lignes dans chaque instruction INSERT à l’aide de l’option --extended-insert (activée par défaut).
Lors de la migration de données avec une exportation et une importation, utilisez le même mode SQL pour l'importation et pour l'exportation. Consultez la section Utiliser le même mode SQL pour l'importation et l'exportation.
Protégez vos données à l'aide de la fonctionnalité Cloud SQL appropriée.

Les sauvegardes et les exportations sont deux façons d'assurer la redondance et la protection des données. Elles permettent chacune d'éviter différents scénarios indésirables et se complètent dans le cadre d'une stratégie efficace de protection des données.

Les sauvegardes sont légères. Elles permettent de restaurer les données de votre instance dans l'état où elles se trouvaient au moment de la sauvegarde. Cependant, les sauvegardes ont certaines limites. Si vous supprimez l'instance, les sauvegardes sont également supprimées. Vous ne pouvez pas sauvegarder une seule base de données ou une seule table. De plus, si la région dans laquelle se trouve l'instance n'est pas disponible, vous ne pouvez pas restaurer l'instance à partir de cette sauvegarde, même dans une région disponible.

Les exportations prennent plus de temps, car un fichier externe est créé dans Cloud Storage pour recréer vos données. Les exportations ne sont pas affectées si vous supprimez l'instance. En outre, vous ne pouvez exporter qu'une seule base de données, voire une seule table, en fonction du format d'exportation choisi.