Bonnes pratiques pour améliorer les performances et la disponibilité d'AlloyDB

Cette page présente les bonnes pratiques générales pour vous aider à améliorer les performances, la durabilité et la disponibilité d'AlloyDB pour PostgreSQL. Cette page s'adresse aux administrateurs de bases de données et aux développeurs qui connaissent déjà AlloyDB et PostgreSQL.

Configurer et administrer une instance

Utiliser les outils AlloyDB pour surveiller l'utilisation et l'état des bases de données

Utilisez le tableau suivant pour en savoir plus sur les outils AlloyDB qui vous aident à surveiller l'utilisation, l'état et les performances de votre base de données.

Outil AlloyDB Description
Rapport "Instantané des performances" Compare les instantanés des métriques système entre deux moments différents.
Insights sur les requêtes Vous aide à détecter, diagnostiquer et éviter les problèmes de performances des requêtes pour les bases de données AlloyDB. Il fournit des informations en libre-service, une surveillance intuitive et des diagnostics qui vont au-delà de la détection afin de vous aider à identifier l'origine des problèmes de performances.
Insights sur le système Vous permet de surveiller les ressources et les métriques de la base de données, y compris le nombre de nœuds actifs, l'utilisation du processeur, les pics de connexion, les erreurs de journal, les transactions par seconde et le délai de réplication maximal.

Respecter les consignes opérationnelles

Pour vous assurer que vos instances sont couvertes par le contrat de niveau de service AlloyDB pour PostgreSQL, suivez les consignes opérationnelles.

Configurer un intervalle de maintenance pour votre instance principale

Configurez un intervalle de maintenance pour votre instance principale afin de planifier quand des mises à jour perturbatrices peuvent se produire. Pour en savoir plus, consultez la section Afficher et définir les heures de maintenance.

Ajouter des instances de pool de lecture pour décharger le trafic de lecture

Pour les charges de travail lourdes en lecture, ajoutez des instances de pool de lecture pour décharger le trafic de lecture de l'instance principale.

Configurez un ou plusieurs pools de lecture pour chaque base de données de l'instance afin d'améliorer le cache.

Envisagez d'ajouter un ou plusieurs nœuds par pool pour faciliter l'équilibrage de charge automatique et la haute disponibilité.

Gérer le délai de réplication

AlloyDB a apporté plusieurs améliorations pour améliorer le délai de réplication. Toutefois, vous pouvez rencontrer des scénarios dans lesquels la relecture des journaux est bloquée ou ne peut pas suivre, ce qui peut entraîner un retard de réplication plus important.

Par exemple, si la taille de votre VM principale est beaucoup plus importante que celle de votre nœud de pool de lecture, en cas de charges de travail d'écriture importantes, la VM principale peut générer des enregistrements de journal plus rapidement que les nœuds de lecture ne peuvent les lire, en particulier s'il existe également une charge de travail de lecture importante exécutée simultanément sur les nœuds de lecture. Dans ce scénario, il peut être utile d'augmenter la taille du nœud de lecture pour lui accorder plus de ressources.

En fonction des besoins de votre application, vous pouvez ajuster les paramètres suivants:

  • max_standby_streaming_delay : détermine la durée d'attente de la relecture avant d'annuler les requêtes qui la bloquent.
  • google_storage.log_replay_throttle_read_transactions: détermine si les requêtes doivent être limitées lorsque le temps de latence est élevé. Le débit limité des requêtes permet à la relecture de disposer de plus de ressources pour rattraper plus rapidement et éviter de renvoyer des données obsolètes aux requêtes.
  • alloydb.promote_cancel_to_terminate : détermine si les backends de requêtes qui ne répondent pas à l'annulation doivent être arrêtés de force.

Ne démarrez pas une opération administrative avant la fin de l'opération précédente.

Les instances AlloyDB ne peuvent pas accepter de nouvelles requêtes d'opération tant que l'opération précédente n'est pas terminée. Si vous essayez de démarrer une nouvelle opération avant la fin de l'opération précédente, la requête d'opération échoue. Cela inclut les redémarrages d'instances.

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

Configurer un quota de stockage suffisant pour la maintenance critique des bases de données

Par défaut, vous pouvez utiliser jusqu'à 16 To de stockage par cluster. Si vous avez besoin de plus d'espace, pensez à augmenter votre quota de stockage.

Éviter 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 la section Surveiller les instances. 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 faire évoluer votre instance vers un plus grand nombre de processeurs. La modification du nombre de processeurs nécessite un redémarrage de l'instance. Si votre instance a déjà atteint le nombre maximal de processeurs, nous vous recommandons de segmenter votre base de données sur plusieurs instances.

Éviter l'épuisement de la mémoire

AlloyDB dispose d'une gestion automatique de la mémoire pour éviter les problèmes de mémoire saturée. Toutefois, une pression de mémoire constante peut entraîner des problèmes de performances. Lorsque vous recherchez des signes d'épuisement de la mémoire, vous devez principalement utiliser la métrique usage. Pour des performances optimales, nous vous recommandons de maintenir cette métrique en dessous de 90 %.

Vous pouvez également utiliser la métrique total_usage pour observer le pourcentage de mémoire disponible utilisé par votre instance AlloyDB, 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 métriques d'utilisation et d'utilisation totale, 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.

Mettez à l'échelle votre instance AlloyDB pour augmenter la taille de sa mémoire. Pour modifier la taille de la mémoire de l'instance, vous devez redémarrer 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 de l'utilisation et des métriques d'utilisation totale dans la console Google Cloud , consultez Surveiller les instances.

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 Resource Type sur AlloyDB for PostgreSQL Database et Metric sur Percentage of instance's transaction IDs consumed. Pour en savoir plus, consultez la section Créer des graphiques avec l'explorateur de métriques.

AlloyDB dispose d'une fonction d'autovidage adaptative intégrée qui permet de réduire les problèmes liés au vidage.

Architecture de données

Dans la mesure du possible, scindez vos instances volumineuses en instances plus petites.

Lorsque cela est possible, utilisez de nombreux clusters AlloyDB plus petits plutôt qu'une seule 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.

Performances des requêtes

Activez le moteur de données en colonnes si vous exécutez des requêtes analytiques.

Consultez une présentation du moteur en colonnes AlloyDB. Recherchez les types de requêtes qui bénéficient de l'activation du moteur en colonnes.

Vous pouvez surveiller l'utilisation du moteur en colonnes.

Si vous ne connaissez pas le moteur de colonnes, commencez par vous familiariser avec la colonisation automatique. Vous pouvez ensuite choisir de gérer les colonnes manuellement.

Évoluer votre instance pour améliorer les performances des requêtes

Si les performances des requêtes sont faibles, envisagez d'augmenter la taille de votre instance.

Chaque SKU dispose de configurations de processeurs virtuels et de mémoire limitées, et d'un cache rapide limité. Si la taille de vos données est importante et que les performances de vos requêtes sont médiocres, envisagez de passer à une instance plus grande.

Déployer des pools de lecture et décharger les requêtes de lecture vers le pool de lecture

Si votre application effectue de nombreuses écritures et lectures, envisagez de déployer des pools de lecture et de décharger les requêtes de lecture vers le pool de lecture.

Pour les charges de travail lourdes en lecture, ajoutez des instances de pool de lecture pour décharger le trafic de lecture de l'instance principale.

Mise en œuvre de l'application

Utiliser de bonnes pratiques de gestion des connexions

Utilisez de bonnes pratiques de gestion des connexions, telles que le regroupement de connexions et l'intervalle exponentiel.

L'utilisation de bonnes techniques de gestion des connexions améliore l'utilisation des ressources de votre application et vous aide à respecter les limites de connexion AlloyDB.

Tester la réponse de votre application aux mises à jour de maintenance

Testez la réponse de votre application aux mises à jour de maintenance qui peuvent se produire à tout moment pendant l'intervalle de maintenance.

Vous pouvez simuler une mise à jour de maintenance en effectuant des opérations de scaling de calcul ou en mettant à jour des indicateurs PostgreSQL statiques qui déclenchent une maintenance à faible temps d'arrêt (LDTM, Low Downtime Maintenance).

Pendant la LDTM, votre instance devient indisponible pendant une courte période et les connexions existantes sont supprimées. Tester la LDTM vous permet de mieux comprendre comment votre application gère la maintenance planifiée et à quel rythme le système peut récupérer.

Tester la réponse de votre application aux basculements

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 la Google Cloud CLI ou de l'API. Pour en savoir plus, consultez la section Déclencher un basculement.

Éviter les transactions volumineuses

Effectuez de petites transactions. Si une mise à jour de base de données volumineuse est nécessaire, effectuez-la en plusieurs petites transactions plutôt qu'en une seule grande transaction.

Éviter un grand nombre de sous-transactions

Évitez un grand nombre de sous-transactions dans une transaction lorsque des transactions de longue durée sont présentes.

Dans AlloyDB, l'exécution d'une transaction dans un bloc d'erreur PL/pgSQL crée des sous-transactions de la transaction correspondant au bloc d'erreur. Les performances globales du système se dégradent si le nombre de sous-transactions dépasse 64 en présence de transactions de longue durée.

Utiliser la dernière version du proxy d'authentification

Si vous utilisez le proxy d'authentification AlloyDB, assurez-vous d'utiliser la version la plus récente. Pour en savoir plus, consultez la section Maintenir le client du proxy d'authentification à jour.

Importer et exporter des données

Restaurer à partir de sauvegardes Cloud SQL pour PostgreSQL pour la migration

Pour faciliter la migration, consultez Migrer de Cloud SQL pour PostgreSQL vers AlloyDB.

Pour découvrir comment migrer vos données de Cloud SQL pour PostgreSQL vers AlloyDB à l'aide de la reproduction continue des données, consultez Database Migration Service pour PostgreSQL vers AlloyDB.

Accélérer les importations pour les petites instances

Lorsque vous importez de grands ensembles de données pour de petites instances, vous pouvez temporairement augmenter le nombre de processeurs et la quantité de mémoire RAM d'une instance afin d'améliorer les performances.

Sauvegarde et récupération

Protéger vos données à l'aide des fonctionnalités AlloyDB appropriées

Utilisez des sauvegardes, une récupération à un moment précis (PITR) et des exportations pour assurer la redondance et la protection. 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. Toutefois, la fonctionnalité de sauvegarde d'AlloyDB présente 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 crée toujours une instance. Vous ne pouvez pas effectuer de récupération à un moment précis sur une instance existante.

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 ou une seule table, en fonction du format d'exportation.

Protégez votre instance et vos sauvegardes contre toute suppression accidentelle

Pour activer la protection contre la suppression accidentelle par défaut, créez une instance AlloyDB à l'aide de la console Google Cloud ou de Terraform.

Utilisez la fonctionnalité d'exportation d'AlloyDB pour exporter vos données afin de bénéficier d'une protection supplémentaire. Utilisez Cloud Scheduler avec l'API Cloud Scheduler pour automatiser la gestion des exportations.

Pour les scénarios plus avancés, utilisez Cloud Scheduler avec les fonctions Cloud Run pour l'automatisation.