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 lourdes 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. | |
| 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 de 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 Google 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 |
| Configurez l'espace de stockage pour tenir compte de la maintenance critique des bases de données. |
Si le paramètre d'activation de l'augmentation automatique de l'espace de stockage est désactivé ou si la limite d'augmentation automatique de l'espace de stockage est activée, assurez-vous de disposer d'au moins 20 % d'espace disponible pour prendre en charge toutes les opérations de maintenance de base de données critiques que Cloud SQL peut effectuer. Pour recevoir des alertes lorsque l'espace disque disponible est inférieur à 20 %, créez une règle d'alerte basée sur les métriques pour l'utilisation du disque avec une position au-dessus du seuil et une valeur de 0,8. Pour en savoir plus, consultez la page Créer des règles d'alerte basées sur des métriques. |
| Évitez de trop solliciter votre processeur. |
Vous pouvez afficher le pourcentage de processeur disponible utilisé par votre instance sur la page "Informations sur l'instance" de la console Google Cloud. Pour en savoir plus, consultez l'article Métriques. Vous pouvez également surveiller votre utilisation du processeur et recevoir des alertes à un seuil spécifié à l'aide de la procédure décrite dans Créer des règles d'alerte basées sur un seuil de métrique. Pour éviter toute surutilisation, vous pouvez augmenter le nombre de processeurs de votre instance. La modification du nombre de processeurs nécessite un redémarrage de l'instance. Si l'instance est déjà au nombre maximal de processeurs, segmentez la base de données sur plusieurs instances. |
| Évitez l'épuisement de la mémoire. |
Lorsque vous recherchez des signes d'épuisement de la mémoire, vous devez principalement utiliser la métrique usage. Pour éviter les erreurs liées à une mémoire insuffisante, nous vous recommandons de maintenir cette métrique à un niveau inférieur à 90 %. Vous pouvez également utiliser la métrique total_usage pour observer le pourcentage de mémoire disponible utilisé par votre instance Cloud SQL, y compris la mémoire utilisée par le conteneur de base de données et la mémoire allouée par le cache du système d'exploitation. En observant la différence entre les deux métriques, vous pouvez identifier la quantité de mémoire utilisée par les processus par rapport à la quantité utilisée par le cache du système d'exploitation. Vous pouvez réutiliser la mémoire dans ce cache. Pour prédire les problèmes de mémoire insuffisante, vérifiez les deux métriques et interprétez-les ensemble. Si les métriques semblent élevées, l'instance peut être à court de mémoire. Cela peut être dû à une configuration personnalisée, au sous-dimensionnement de l'instance pour la charge de travail ou à une combinaison de ces facteurs. Mettez à l'échelle votre instance Cloud SQL pour augmenter la taille de sa mémoire. La modification de la taille de la mémoire de l'instance nécessite un redémarrage de l'instance. Si l'instance est déjà à la taille maximale de la mémoire, vous devez segmenter votre base de données sur plusieurs instances. Pour en savoir plus sur la surveillance des deux métriques dans la console Google Cloud, consultez la page Métriques. |
| Assurez-vous que l'instance dispose d'ID de transaction optimaux. |
Vous pouvez consulter l'utilisation des ID de transaction de votre instance sur la page Explorateur de métriques de la console Google Cloud en définissant Le réglage et la surveillance des instances de base de données peuvent vous aider à réduire ou à éviter les problèmes liés à la fonction VACUUM. Surveillez l'utilisation des ID de transaction de votre instance et activez puis ajustez les paramètres
|
Architecture de données
| Bonne pratique | En savoir plus |
|---|---|
| Dans la mesure du possible, scindez vos instances volumineuses en instances plus petites. | 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 pose pas un groupe d'instances plus petites. |
| N'utilisez pas trop de tables de base de données. |
Le nombre de tables de votre instance doit être inférieur à 10 000. Un trop grand nombre de tables de base de données peut influer sur le temps de mise à niveau de la base de données. |
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 entre les tentatives. | 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. | Essayez la maintenance en libre-service pour simuler une mise à jour de maintenance. Pendant la maintenance, votre instance devient indisponible pendant une courte période et les connexions existantes sont supprimées. Tester les déploiements de maintenance permet de mieux comprendre comment votre application gère la maintenance planifiée et à quel rythme le système peut récupérer. |
| 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 la console Google Cloud, de gcloud CLI 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 d'authentification Cloud SQL, assurez-vous de bien utiliser la version la plus récente. | Consultez la section Maintenir le proxy d'authentification Cloud SQL à jour. |
Importer et exporter des données
| Bonne pratique | En savoir plus |
|---|---|
| Utiliser des exportations sans serveur | Les exportations sans serveur déchargent l'opération d'exportation vers une instance temporaire. L'instance principale peut ainsi continuer à diffuser des requêtes et effectuer les opérations à son niveau habituel. Une fois l'exportation des données terminée, l'instance temporaire est automatiquement supprimée. |
| Accélérez les importations pour les petites instances. | Pour les petites instances, vous pouvez temporairement augmenter le nombre de processeurs et la quantité de mémoire RAM 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. |
Sauvegarde et récupération
| Bonne pratique | En savoir plus |
|---|---|
| Protégez vos données à l'aide de la fonctionnalité Cloud SQL appropriée. |
Les sauvegardes, la récupération à un moment précis et les exportations permettent 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. La récupération à un moment précis vous aide à récupérer l'état précédent d'une instance à un moment spécifique. Par exemple, en cas de perte de données due à une erreur, vous pouvez restaurer une base de données à l'état qui précède l'occurrence de l'erreur. Une récupération à un moment précis d'une instance existante n'est pas possible, car une nouvelle instance est créée lors de l'opération. 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. |
| Dimensionnez les instances de manière à prendre en compte la conservation des journaux de transactions (binaires). | Une activité d'écriture élevée sur la base de données peut générer un grand volume de journaux de transactions (binaires), ce qui peut consommer beaucoup d'espace disque et entraîner une augmentation considérable de l'espace disque sur les instances autorisées à augmenter automatiquement l'espace de stockage. Nous vous recommandons de dimensionner le stockage des instances en tenant compte de la conservation des journaux de transactions. |
| Protégez votre instance et vos sauvegardes contre toute suppression accidentelle. | Une instance Cloud SQL que vous créez dans la console Google Cloud ou via Terraform active par défaut la protection contre la suppression accidentelle. Utilisez la fonctionnalité d'exportation de Cloud SQL pour exporter vos données afin de bénéficier d'une protection supplémentaire. Utilisez Cloud Scheduler avec l'API REST pour automatiser la gestion des exportations. Pour les scénarios plus avancés, utilisez Cloud Scheduler avec les fonctions Cloud Run pour l'automatisation. |
Réglage et surveillance
Le réglage et la surveillance des instances de base de données peuvent vous aider à réduire ou à éviter les problèmes liés à l'opération VACUUM.
L'opération VACUUM possède plusieurs variantes avec différents niveaux de verrouillage : VACUUM standard et VACUUM FULL.
L'option VACUUM FULL permet de récupérer plus d'espace disque, mais elle s'exécute bien plus lentement et verrouille exclusivement la table. Utilisez plutôt la forme standard VACUUM, qui peut s'exécuter en parallèle des opérations de base de données de production.
Lorsque vous utilisez l'opération VACUUM, les commandes telles que SELECT, INSERT, UPDATE, and DELETE continuent de fonctionner normalement. Vous ne pouvez pas modifier la définition d'une table avec des commandes telles que ALTER TABLE lorsque l'opération VACUUM est en cours d'exécution.
Voici quelques recommandations qui peuvent vous aider à réduire le temps nécessaire à l'exécution de l'opération VACUUM :
- Augmentez la mémoire système et
maintenance_work_mem. Cette opération regroupe plus de tuples dans chaque itération et effectue la tâche le plus rapidement possible. Sachez que lors de l'exécution de l'opération AUTOVACUUM, jusqu'àautovacuum_max_workersfois cette mémoire peut être allouée. Veillez donc à ne pas définir une valeur par défaut trop élevée. - L'opération
VACUUMgénère de nombreux enregistrements de journaux WAL. S'il est possible de réduire le nombre d'enregistrements WAL, par exemple si aucune instance dupliquée n'est configurée pour cette instance, l'opération est effectuée plus rapidement. - Si la table a atteint la limite de deux milliards d'ID de transaction, car aucun des tuples n'est figé, essayez de réduire le volume de travail effectué en mode mono-utilisateur. Une option possible consiste à définir
vacuum_freeze_min_age=1,000,000,000(valeur maximale autorisée, supérieure à la valeur par défaut de 50 000 000). Cette nouvelle valeur réduit le nombre de tuples figés de moitié. - Les versions 12.0 et ultérieures de PostgreSQL sont compatibles avec les opérations de nettoyage et
VACUUM, sans nettoyer les entrées d'index. Cette étape est cruciale, car le nettoyage de l'index nécessite son analyse complète. Si vous disposez de plusieurs index, le temps total dépend de la taille des index. - Les index plus volumineux peuvent prendre beaucoup de temps à analyser. Par conséquent, il est préférable d'utiliser
INDEX_CLEANUP OFFpour procéder rapidement au nettoyage et figer les données de la table. Les versions antérieures à PostgreSQL 12.0 doivent ajuster le nombre d'index. En d'autres termes, si des index ne sont pas critiques, il peut s'avérer utile de supprimer l'indexNON-CRITICALpour accélérer l'opération VACUUM.