Session-level connection pools and transaction-level connection pools of PolarDB - PolarDB

PolarDB prend en charge deux types de pools de connexions : au niveau de la session et au niveau de la transaction. Ces pools réduisent la surcharge liée aux connexions à la base de données en réutilisant les connexions existantes plutôt qu'en établissant une nouvelle connexion pour chaque requête.

Le pool de connexions décrit ici est une fonctionnalité de PolarProxy, la couche proxy de PolarDB. Il n'affecte aucun pool de connexions intégré à votre application. Si votre application gère déjà son propre pool de connexions, il est inutile d'activer cette fonctionnalité.

Fonctionnement

Pool de connexions au niveau de la session

Session-level connection pool diagram

Lorsqu'une connexion applicative se ferme, PolarProxy vérifie si elle est inactive. Dans ce cas, PolarProxy la conserve dans le pool pendant une courte période. La prochaine requête entrante réutilise cette connexion inactive si les paramètres user, clientip et dbname correspondent, ce qui évite le coût d'ouverture d'une nouvelle connexion. En l'absence de correspondance, PolarProxy ouvre une nouvelle connexion vers la base de données.

Les pools au niveau de la session diminuent la fréquence d'établissement des connexions, réduisant ainsi le nombre de threads principaux MySQL consommés et améliorant le débit. Ils ne réduisent toutefois pas le nombre total de connexions simultanées ; les connexions inactives continuent d'être comptabilisées dans la limite de connexions de la base de données.

Pool de connexions au niveau de la transaction

Transaction-level connection pool diagram

Un pool au niveau de la transaction réduit à la fois le nombre de connexions directes à la base de données et la surcharge engendrée par les connexions éphémères. Les applications peuvent ouvrir des milliers de connexions vers PolarProxy, tandis que ce dernier ne maintient que quelques dizaines ou centaines de connexions vers les bases de données back-end.

Lorsqu'une application envoie une requête, PolarProxy n'ouvre pas immédiatement une connexion back-end. Il recherche dans le pool une connexion inactive correspondant aux paramètres user, dbname et aux variables système (sql_mode, character_set_server, collation_server, time_zone). Si une correspondance existe, PolarProxy la réutilise. Une fois la transaction terminée, la connexion retourne dans le pool pour servir d'autres requêtes.

PolarProxy n'impose aucune limite de nombre de connexions côté application. Le nombre maximal de connexions à un endpoint de cluster PolarDB dépend des spécifications des nœuds de calcul back-end. Sans pool au niveau de la transaction, le système doit ouvrir une connexion distincte sur le nœud principal et sur chaque nœud en lecture seule pour chaque requête.

Choisir un pool de connexions

Consultez ce tableau pour identifier le type de pool adapté à votre scénario :

Scénario	Pool recommandé	Raison
Peu de connexions, principalement persistantes, ou application disposant déjà de son propre pool	Aucun (désactivé)	Un pool PolarDB ajoute une surcharge sans apporter de bénéfice
Dizaines de milliers de connexions, ou architecture serverless avec des connexions évoluant linéairement	Niveau de la transaction	Multiplexe de nombreuses connexions applicatives vers un nombre réduit de connexions back-end
Connexions éphémères uniquement, dans les scénarios listés sous Limitations du niveau de la transaction	Niveau de la session	Réduit la fréquence des connexions sans nécessiter un multiplexage complet
Exécution fréquente de `COM_STATISTICS`	Aucun (désactivé)	L'activation du pool convertit les connexions non persistantes en connexions persistantes, augmentant leur nombre et déclenchant un goulot d'étranglement de type verrouillage-parcours dans `COM_STATISTICS`. Des exécutions fréquentes peuvent provoquer une dégradation importante des performances et affecter le temps de réponse global de l'application.
Nombre élevé de requêtes SQL lentes entraînant des connexions en attente	Aucun (désactivé)	Les pools de connexions ne résolvent pas la contention due aux requêtes lentes ; réduisez plutôt le nombre de requêtes lentes

Limitations

Limitations du niveau de la session

Les pools au niveau de la session réduisent la fréquence des connexions, mais pas la concurrence. Les connexions inactives du pool continuent d'être comptabilisées dans la limite totale de connexions de la base de données.
Ces pools ne résolvent pas les problèmes de connexions en attente causés par des requêtes SQL lentes.

Limitations du niveau de la transaction

Les opérations suivantes verrouillent la connexion pour toute la durée de la session. Une connexion verrouillée n'est pas restituée au pool et devient indisponible pour les autres requêtes.

Opération	Solution de contournement
Exécuter une instruction `PREPARE`	Utilisez des instructions préparées côté client si votre pilote les prend en charge
Créer une table temporaire	Utilisez une table régulière avec un identifiant de session unique, puis supprimez-la une fois terminé
Modifier des variables utilisateur	Définissez les variables au début de la session ou transmettez les valeurs explicitement dans chaque requête
Recevoir des entrées de journal dépassant 16 Mo	Fractionnez les écritures de journaux volumineuses en lots plus petits
Exécuter une instruction `LOCK TABLE`	Privilégiez le verrouillage au niveau de la ligne (`SELECT ... FOR UPDATE`)
Exécuter plusieurs instructions dans une seule chaîne d'instructions	Séparez-les en instructions individuelles
Appeler une procédure stockée	Migrez la logique vers la couche applicative lorsque cela est possible

Fonctions non prises en charge

Les fonctions FOUND_ROWS(), ROW_COUNT() et LAST_INSERT_ID() peuvent être appelées, mais risquent de retourner des résultats inexacts lorsque les connexions sont réutilisées.

Fonction	Solution de contournement
`FOUND_ROWS()`	Sur PolarProxy V1.13.11 ou ultérieur, placez `SELECT FOUND_ROWS()` immédiatement après `SELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT `. Notez que cette méthode n'est plus recommandée par MySQL open source. Vous pouvez également la remplacer par `SELECT COUNT() FROM tb1`. Pour plus de détails, consultez FOUND_ROWS().
`LAST_INSERT_ID()`	Placez `SELECT LAST_INSERT_ID()` immédiatement après l'instruction `INSERT` pour obtenir des résultats exacts.
`ROW_COUNT()`	Aucune solution de contournement disponible ; la fonction peut être invoquée mais risque de retourner des résultats inexacts lors de la réutilisation des connexions.

Autres différences de comportement

wait_timeout : Lorsque le délai expire, seules les connexions back-end sont fermées. Les connexions côté application vers PolarProxy restent ouvertes, car PolarProxy sélectionne une connexion dans le pool pour chaque nouvelle requête.
Variables de session : Le pool fait correspondre les connexions en utilisant sql_mode, character_set_server, collation_server et time_zone. Si vos requêtes dépendent d'autres variables système au niveau de la session, exécutez des instructions SET pour les configurer après l'établissement de chaque connexion. Sinon, le pool risque de réutiliser une connexion dont les valeurs de variables sont inattendues.
Niveau d'isolation : Conservez le niveau d'isolation par défaut READ COMMITTED. Si un client modifie explicitement le niveau d'isolation, la connexion est restituée au pool après la fin de la transaction et peut être réutilisée par d'autres requêtes, ce qui entraîne une incohérence du niveau d'isolation.
SELECT connection_id() : Peut retourner des ID de thread différents pour ce qui semble être la même connexion, car les connexions sont réutilisées entre les requêtes.
SHOW PROCESSLIST et SQL Explorer : Les adresses IP et numéros de port affichés peuvent différer de l'adresse IP et du port réels de votre application, car les connexions sont multiplexées via PolarProxy.
Commande KILL : Retourne ERROR 1094 (HY000): Unknown thread id: xxx car l'ID de thread entre le client et PolarProxy diffère de celui entre PolarProxy et la base de données. PolarProxy fusionne les résultats de SHOW PROCESSLIST de tous les nœuds avant de les retourner au client.

Remarques d'utilisation

Les paramètres du pool de connexions ne s'appliquent qu'aux connexions créées après la modification. Les connexions existantes ne sont pas affectées. Pour les étapes de configuration, consultez Configurer PolarProxy.
Le pool de connexions ne prend pas en charge les permissions spécifiques à une adresse IP pour un compte. Si vous accordez à user@192.xx.xx.1 l'accès à database_a mais pas à user@192.xx.xx.2, une erreur de permission peut survenir lors de la réutilisation de cette connexion. Évitez de configurer des permissions différentes pour le même compte sur plusieurs adresses IP lorsque le pool de connexions est activé.