Optimiser les ressources et isoler les requêtes de lecture avec le transfert de requêtes transparent

Aperçu — Transfert transparent des requêtes

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Cette page explique comment activer, configurer et surveiller le transfert de requêtes transparent dans vos instances AlloyDB pour PostgreSQL. Le transfert transparent des requêtes est une fonctionnalité intelligente d'optimisation des ressources qui permet au nœud principal d'intercepter les requêtes en lecture seule et de les transférer sélectivement vers des instances du pool de lecture sous-utilisées, tout en maintenant la cohérence "lire ses propres écrits". Les requêtes transférées au pool de lecture génèrent des résultats cohérents avec l'exécution du nœud principal.

Remarque : Les requêtes sont transférées vers les instances de pool de lecture de la région. Les requêtes ne sont pas transférées aux clusters secondaires.

Le transfert de requêtes transparent est particulièrement adapté aux scénarios suivants :

• Charges de travail hybrides (HTAP) : vous exécutez des requêtes de reporting ou d'analyse, avec une cohérence "read-your-writes", sur la même base de données qui gère les transactions, et vous souhaitez empêcher les lectures coûteuses d'avoir un impact sur la latence d'écriture.
• Applications monolithiques : vous souhaitez utiliser la capacité du pool de lecture sans refactoriser votre application pour utiliser des points de terminaison de lecteur et d'écriture distincts, tout en exigeant une cohérence stricte de type "lecture de vos écritures".
• Gestion dynamique de la charge : vous rencontrez des pics de trafic de lecture imprévisibles et vous souhaitez que la base de données décharge automatiquement le travail sur les nœuds du pool de lecture lorsque le nœud principal est fortement sollicité avec une cohérence "read-your-writes".

Avant de commencer

• Assurez-vous que votre cluster AlloyDB est compatible avec PostgreSQL 17 ou 18.

• Vous devez avoir configuré au moins une instance de pool de lecture active dans votre cluster AlloyDB. Pour savoir comment créer ou valider des instances de pool de lecture, consultez Créer une instance de pool de lecture dans un cluster et Afficher les détails d'une instance.

  Remarque : Si votre cluster ne dispose que d'une configuration principale ou à haute disponibilité (HA) sans pools de lecture, le transfert transparent des requêtes ne dispose d'aucun nœud de destination pour recevoir les requêtes transférées.

Rôles requis

• Assurez-vous de disposer du rôle de base de données alloydbsuperuser ou d'être connecté en tant qu'utilisateur postgres par défaut.

Activer le transfert transparent des requêtes

Le transfert transparent des requêtes est désactivé par défaut. Vous pouvez l'activer de manière dynamique au niveau de la session ou de la base de données sans redémarrer la base de données.

Activer au niveau de la session

Pour activer le transfert transparent des requêtes pour votre session actuelle, exécutez la commande SQL suivante :

SET alloydb.enable_query_forwarding = TRUE;

Activer au niveau de la base de données

Pour activer le transfert de requêtes transparent pour une base de données spécifique, exécutez la commande SQL suivante :

ALTER DATABASE DATABASE_NAME SET alloydb.enable_query_forwarding = ON;

Remplacez DATABASE_NAME par le nom de votre base de données.

Remarque : Une fois la commande ALTER DATABASE exécutée, le transfert de requêtes transparent est activé pour les nouvelles connexions à la base de données.

Conditions d'éligibilité des requêtes

• Le transfert transparent des requêtes ne s'applique qu'aux instructions SELECT en lecture seule.
• La requête ne doit pas prendre de verrouillage au niveau des lignes, comme ceux utilisés dans SELECT ... FOR UPDATE.
• Le transfert transparent des requêtes est limité pour les instructions SELECT dans les transactions multi-instructions.
• Les requêtes ne peuvent pas faire référence à des tables temporaires, non enregistrées ou de catalogue.
• La requête doit respecter les contraintes de fonction suivantes :
  • La requête ne doit pas contenir de fonctions volatiles ni de fonctions définies par l'utilisateur.
  • La requête ne doit pas contenir de fonctions de valeur SQL telles que CURRENT_DATE, LOCALTIME, USER ou CURRENT_SCHEMA.
  • La requête ne doit pas contenir d'expressions NEXTVAL().
  • La requête ne peut contenir aucune procédure ni fonction SQL.
• Toutes les colonnes de résultats doivent utiliser des types de données qui implémentent des fonctions d'envoi et de réception binaires.
• Une requête n'est éligible au transfert que si son coût indirect est minime par rapport au coût total de la requête. Cela signifie que les requêtes utilisant des analyses d'index sont généralement exclues, car leurs frais généraux dépassent généralement le coût de la requête elle-même.
• Le transfert vers un nœud de secours actif AlloyDB n'est pas pris en charge. Un nœud de secours actif AlloyDB est un nœud secondaire dédié aux instances principales à haute disponibilité (HA).

Vérifier l'éligibilité des requêtes avec EXPLAIN

Dans l'exemple suivant, large_table est une table d'une base de données comportant de nombreuses lignes. Pour vérifier si une requête spécifique peut être transférée avec votre configuration actuelle, exécutez la commande EXPLAIN :

EXPLAIN SELECT count(*) FROM large_table t1, large_table t2;

Si la requête est éligible, le résultat inclut une instruction sur l'état du transfert de la requête après le plan d'exécution Postgres standard. Si cette instruction est manquante, la requête n'est pas éligible au transfert de requête et s'exécute localement sur le primaire.

Aggregate  (cost=25000.00..25000.01 rows=1 width=8)
  ->  Nested Loop  (cost=0.00..20000.00 rows=1000000 width=0)
        ... [Standard Postgres Plan Steps] ...
Query Forwarding: Eligible. (overhead=1250.02)

Dans la réponse, Eligible indique que la requête répond aux critères SQL en lecture seule standards et que l'analyse coûts/avantages favorise son routage vers une instance de pool de lecture. Le paramètre overhead indique le coût du planificateur calculé pour transférer la requête à une instance de pool de lecture, y compris le coût indirect de l'établissement de la connexion et de la restauration des instantanés sur le réplica.

Surveiller les métriques de transfert de requêtes

Pour vérifier que le transfert transparent des requêtes fonctionne dans votre charge de travail, vous pouvez suivre la métrique suivante dans Cloud Monitoring :

Métrique	Description	Détails
alloydb.googleapis.com/internal/database/postgresql/workload/distributed/tqf_query_count	Nombre cumulé de requêtes traitées par le transfert de requêtes transparent.	Nom à afficher : nombre de requêtes TQF Type de métrique : CUMULATIVE Type de valeur : INT64 Libellés : status : gestion des requêtes si le transfert transparent des requêtes est activé. Ce libellé enregistre l'une des valeurs suivantes : completed : exécuté sur une instance de pool de lecture. fallback : exécuté sur le nœud principal. disqualified : impossible de transférer.

Étapes suivantes

• Créer une instance de pool de lecture dans un cluster
• Surveiller les instances