La fonctionnalité Database Proxy intègre un mécanisme de regroupement de connexions (connection pooling) qui s'intercale entre votre application et l'instance RDS. Lorsque votre application utilise des connexions éphémères ou approche la limite maximale de connexions de l'instance, le regroupement de connexions réduit la fréquence d'établissement de nouvelles connexions. Cela diminue la charge sur le thread principal et réduit le nombre total de connexions ouvertes.
Choisir un type de pool de connexions
ApsaraDB RDS for MySQL propose deux types de pools de connexions. Répondez aux questions suivantes pour déterminer celui qui correspond le mieux à votre charge de travail.
Vos connexions restent-elles ouvertes pendant toute la durée de la session ou sont-elles éphémères ?
Connexions persistantes (frameworks web avec pools intégrés tels que Druid, DBCP, c3p0 ou HikariCP) : désactivez le regroupement de connexions. Le proxy n'apporte aucune valeur ajoutée dans ce cas, car le pool au niveau de l'application est suffisant.
Connexions éphémères (scripts PHP, fonctions serverless, modèles de connexion par requête) : activez le regroupement de connexions et poursuivez la lecture ci-dessous.
**Atteignez-vous la limite de connexions de l'instance ou vos charges de travail utilisent-elles les limites au niveau des transactions ?**
| Situation | Type recommandé |
|---|---|
| Les connexions atteignent fréquemment le maximum de l'instance | Regroupement de connexions au niveau des transactions (recommandé) |
| Les limites au niveau des transactions affectent votre charge de travail | Regroupement de connexions au niveau de la session |
Par défaut, le regroupement de connexions est désactivé. Après avoir modifié le type de pool de connexions, la modification ne s'applique qu'aux nouvelles connexions.
Limitations
Le tableau ci-dessous compare les opérations et fonctions prises en charge dans chaque mode de pool. Consultez ces informations avant de choisir un type.
| Fonctionnalité | Au niveau des transactions | Au niveau de la session |
|---|---|---|
| Instruction PREPARE | Non prise en charge — verrouille la connexion jusqu'à sa fermeture | Pris en charge |
| Tables temporaires | Non pris en charge — verrouille la connexion jusqu'à sa fermeture | Pris en charge |
| Variables utilisateur | Non pris en charge — verrouille la connexion jusqu'à sa fermeture | Pris en charge |
| Paquets volumineux (≥16 Mo) | Non pris en charge — verrouille la connexion jusqu'à sa fermeture | Pris en charge |
| LOCK TABLE | Non pris en charge — verrouille la connexion jusqu'à sa fermeture | Pris en charge |
| Requêtes multi-instructions | Non pris en charge — verrouille la connexion jusqu'à sa fermeture | Pris en charge |
| Procédures stockées | Non pris en charge — verrouille la connexion jusqu'à sa fermeture | Pris en charge |
FOUND_ROWS() |
Imprécis (voir la note ci-dessous) | Pris en charge |
ROW_COUNT() |
Imprécis | Pris en charge |
LAST_INSERT_ID() |
Imprécis (voir la note ci-dessous) | Pris en charge |
Pour la version V1.13.11 ou ultérieure du proxy de base de données :
SELECT FOUND_ROWS()aprèsSELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT *renvoie des résultats précis. Toutefois, ce modèle n'est plus recommandé par MySQL. Remplacez-le parSELECT COUNT(*) FROM tb1. Consultez FOUND_ROWS() .
SELECT LAST_INSERT_ID()après une instructionINSERTrenvoie des résultats précis.
Lorsqu'une connexion est verrouillée (déclenché par les opérations ci-dessus), elle ne peut pas être rendue au pool tant que la connexion n'est pas explicitement fermée. En pratique, la session se comporte comme un regroupement au niveau de la session pendant toute la durée de vie de cette connexion.
Note d'utilisation pour les variables au niveau de la session : Le regroupement de connexions au niveau des transactions fait correspondre les variables suivantes dans les requêtes : sql_mode, character_set_server, collation_server et time_zone. Si une requête inclut d'autres variables système au niveau de la session, vous devez exécuter explicitement l'instruction SET sur votre client pour configurer ces variables après l'établissement de la connexion pour la requête. Sinon, une connexion dont les variables système ont été reconfigurées peut être sélectionnée dans le pool de connexions et réutilisée.
Fonctionnement
Le proxy de base de données divise chaque connexion en deux parties : une connexion frontale entre votre application et le proxy, et une connexion dorsale entre le proxy et la base de données.
Regroupement de connexions au niveau des transactions
Plusieurs sessions partagent une seule connexion dorsale. Le proxy n'ouvre pas immédiatement une connexion dorsale lorsqu'un client se connecte. Il attend plutôt qu'une transaction soit prête à s'exécuter, puis sélectionne une connexion dorsale disponible dans le pool.
Une connexion dorsale est disponible lorsque ses valeurs user et dbname correspondent aux valeurs des variables système spécifiées.
Si une connexion correspondante existe, le proxy l'utilise. Lorsque la transaction se termine, le proxy rend la connexion au pool ; la session peut continuer sans se terminer.
Si aucune connexion correspondante n'existe, le proxy en ouvre une nouvelle.
Étant donné que les sessions inactives ne conservent pas les connexions dorsales, plusieurs sessions en cours peuvent être multiplexées sur un nombre inférieur de connexions dorsales (N sessions : 1 connexion dorsale). Cela réduit à la fois la fréquence des connexions et le nombre total de connexions.
Le proxy de base de données n'impose pas de limite stricte au nombre de connexions. Le maximum est déterminé par les spécifications de votre instance RDS.
Regroupement de connexions au niveau de la session
Une session occupe une connexion dorsale (N sessions : N connexions dorsales). Le proxy recherche une connexion dorsale disponible dans le pool lorsqu'une session démarre.
Une connexion dorsale est disponible lorsque ses valeurs user, clientip et dbname correspondent toutes.
Si une connexion correspondante existe, le proxy la réutilise, évitant ainsi la surcharge liée à l'établissement de la connexion (handshake).
Si aucune connexion correspondante n'existe, le proxy en ouvre une nouvelle.
Lorsque la session se termine, le proxy rend la connexion dorsale au pool pour qu'elle soit réutilisée par la session suivante. Cela réduit la surcharge liée à l'établissement de la connexion sans réduire le nombre total de connexions ouvertes.
Tant qu'une session est active, sa connexion dorsale ne peut pas être utilisée par d'autres sessions, même si la session est inactive entre les instructions.
Notes d'utilisation
Autorisations spécifiques à l'adresse IP : Le regroupement de connexions ne prend pas en charge les autorisations par adresse IP pour un compte. Si un compte dispose d'autorisations différentes selon l'adresse IP source (par exemple, accès à
database_adepuis192.xx.xx.1mais pas depuis192.xx.xx.2), des erreurs d'autorisation peuvent se produire lors de la réutilisation des connexions existantes.Pools au niveau de l'application : Le regroupement de connexions du proxy n'interfère pas avec les pools au niveau de l'application (Druid, DBCP, c3p0, HikariCP). Si votre application gère déjà son propre pool, il n'est pas nécessaire d'activer le regroupement de connexions au niveau du proxy.
Requêtes lentes : Le regroupement de connexions ne résout pas l'accumulation de connexions causée par des requêtes SQL lentes. Optimisez les requêtes ou dépannez le problème au niveau de l'instance.
Version du proxy et type de point de terminaison : Les versions du proxy antérieures à la 2.9.1 ne prennent pas en charge le regroupement de connexions sur les points de terminaison en lecture seule. La version 2.9.1 et les versions ultérieures prennent en charge le regroupement de connexions sur les points de terminaison en lecture/écriture et en lecture seule.
Comportement de
wait_timeout: Lorsque le regroupement de connexions au niveau des transactions est activé, le paramètrewait_timeoutpeut ne pas prendre effet sur votre client. Le proxy sélectionne une connexion dans le pool à chaque requête. Lorsquewait_timeoutexpire, seules les connexions dorsales sont fermées ; la connexion côté client reste ouverte.Détection de la réutilisation des connexions : Exécutez
SELECT CONNECTION_ID()pour obtenir l'ID du thread actuel. Si l'ID du thread change entre les requêtes dans la même session client, la connexion est réutilisée depuis le pool.Comportement de SHOW PROCESSLIST : Lorsque le regroupement de connexions au niveau des transactions est activé, l'ID du thread frontal diffère de l'ID du thread dorsal. Par conséquent, une commande
KILLpeut renvoyer une erreur même après la fin réussie d'un processus. Exécutez à nouveauSHOW PROCESSLISTpour confirmer l'état du processus. Le proxy agrège également les résultats de toutes les instances principales, secondaires et en lecture seule avant de les renvoyer à votre application. L'adresse IP et le port affichés dansSHOW PROCESSLISTou dans la fonctionnalité SQL Explorer and Audit peuvent différer de l'adresse client réelle. Pour plus d'informations, consultez Utiliser la fonctionnalité SQL Explorer and Audit.
Activer le regroupement de connexions
Prérequis
Avant de commencer, assurez-vous d'avoir :
Activé la fonctionnalité Database Proxy. Pour plus d'informations, consultez Activer la fonctionnalité Database Proxy
Étapes
Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où réside l'instance RDS, puis cliquez sur l'ID de l'instance.
Dans le volet de navigation de gauche, cliquez sur Database Proxy.
-
Dans la section Connection Information, activez le regroupement de connexions en utilisant l'une des méthodes suivantes :
Méthode 1 — Activation rapide via l'icône d'état
Placez le pointeur sur l'icône
à droite du point de terminaison du proxy. Dans la boîte de dialogue qui s'affiche, cliquez sur Enable Transaction-level Connection Pooling ou Enable Session-level Connection Pooling, puis cliquez sur OK.Méthode 2 — Modifier la configuration du point de terminaison
Recherchez le point de terminaison du proxy, cliquez sur Method 2 — Modify endpoint configuration dans la colonne Modify Configuration, puis sélectionnez le type de pool de connexions à côté de Actions.
Si le regroupement de connexions est déjà activé, vous pouvez modifier le type de pool en utilisant cette méthode.
FAQ
Combien de connexions le pool peut-il contenir ?
Il n'y a pas de maximum fixe pour le pool lui-même. Si votre application approche la limite de connexions de l'instance, activez le regroupement de connexions au niveau des transactions pour multiplexer les sessions sur moins de connexions dorsales.
Combien de temps les connexions inactives restent-elles dans le pool ?
Les connexions dans le pool restent actives pendant 10 secondes avant d'être fermées.
Le regroupement de connexions affecte-t-il les performances ?
Pour les charges de travail avec des connexions éphémères, l'activation du regroupement de connexions améliore les performances de l'instance d'environ 10 %.
Quelle est la différence entre le regroupement au niveau des transactions et au niveau de la session ?
| Au niveau des transactions | Au niveau de la session | |
|---|---|---|
| Les sessions partagent les connexions dorsales | Oui | Non |
| Connexion dorsale en cours d'utilisation | Pendant le traitement d'une transaction | Pendant qu'une session est active |
| Connexion dorsale rendue au pool | Lorsque la transaction est terminée (la session peut continuer) | Lorsque la session se termine |
| Mappage session-vers-connexion dorsale | N:1 | N:N |
| Réduit le nombre total de connexions | Oui | Non |
Mon application s'est déconnectée du proxy. Le regroupement de connexions en est-il la cause ?
Pas nécessairement. La cause dépend des conditions spécifiques au moment de la déconnexion et peut ne pas être liée au regroupement de connexions.
Référence API
| Opération | Description |
|---|---|
| DescribeDBProxy | Interroge les détails du proxy dédié d'une instance ApsaraDB RDS |
| DescribeDBProxyEndpoint | Interroge les informations sur un point de terminaison de proxy |
| ModifyDBProxyEndpoint | Modifie les paramètres de connexion pour un point de terminaison de proxy |