Tous les produits
Search

Ce produit

    ApsaraDB RDS:Configure connection pooling

    Centre de documentation

    ApsaraDB RDS:Configure connection pooling

    Dernière mise à jour :Oct 09, 2026

    Si votre application crée fréquemment des connexions éphémères ou si le nombre de connexions est élevé et approche la limite de votre base de données MySQL, utilisez la fonctionnalité de regroupement de connexions du proxy de base de données ApsaraDB RDS for MySQL. Cette fonctionnalité réduit la fréquence d'établissement de nouvelles connexions, ce qui minimise la charge sur le thread principal de la base de données et diminue le nombre total de connexions.

    Choisir un type de regroupement de connexions

    Le proxy de base de données ApsaraDB RDS for MySQL propose un regroupement de connexions au niveau des transactions et au niveau des sessions. Vous pouvez décider d'utiliser ou non le regroupement de connexions et sélectionner un type en fonction de votre cas d'utilisation.

    Type de pool de connexions

    Cas d'utilisation

    Regroupement de connexions au niveau des transactions (recommandé)

    Scénarios impliquant des connexions éphémères, une création fréquente de connexions et un nombre de connexions approchant la limite de la base de données MySQL.

    Votre activité n'est pas affectée par les limites du regroupement de connexions au niveau des transactions.

    Regroupement de connexions au niveau des sessions

    Scénarios impliquant des connexions éphémères et une création fréquente de connexions, mais où l'application est affectée par les limites du regroupement de connexions au niveau des transactions.

    Ne pas utiliser le regroupement de connexions

    Scénarios avec des connexions persistantes, un nombre réduit de connexions ou un pool de connexions côté application, tel que Druid, DBCP, C3P0 ou HikariCP.

    Types de pools de connexions

    Regroupement de connexions au niveau des transactions (recommandé)

    Cas d'utilisation

    • Votre application utilise principalement des connexions éphémères.

    • Les connexions sont créées fréquemment.

    • Le nombre de connexions est élevé et approche la limite de connexions de la base de données MySQL.

    Avantages

    • Réduit la fréquence d'établissement des connexions entre votre application et la base de données, ce qui diminue la charge sur le thread principal de la base de données MySQL.

    • Réduit le nombre total de connexions à la base de données.

    Fonctionnement

    Après avoir activé le regroupement de connexions au niveau des transactions, lorsqu'un client initie une demande de session, le proxy de base de données établit une connexion frontale avec le client, mais ne crée pas immédiatement de connexion dorsale vers la base de données. Lorsqu'une demande doit être traitée, le proxy vérifie la disponibilité d'une connexion dorsale dans le pool de connexions au niveau des transactions.

    Remarque

    Une connexion dorsale est considérée comme disponible si ses paramètres user et dbname ainsi que certaines valeurs de variables système sont cohérents avec la demande.

    • Si une connexion disponible existe, le proxy la réutilise. Une fois la transaction terminée, le proxy renvoie la connexion au pool de connexions au niveau des transactions.

    • Si aucune connexion disponible n'existe, le proxy crée une nouvelle connexion dorsale vers la base de données.

    Plusieurs sessions peuvent partager une seule connexion dorsale. Les sessions avec des transactions actives occupent une connexion dorsale, tandis que les sessions avec des transactions inactives ne l'occupent pas, comme illustré dans la figure suivante.

    image

    En permettant à une seule connexion dorsale de gérer les demandes de transaction de plusieurs sessions au fil du temps, ce modèle offre les avantages suivants :

    • Fréquence de connexion réduite : Le backend maintient des connexions persistantes vers la base de données, réduisant ainsi le besoin d'établir fréquemment de nouvelles connexions et diminuant la charge sur le thread principal de la base de données.

    • Nombre total de connexions plus faible : Plusieurs sessions partagent la même connexion dorsale, empêchant les connexions inactives de consommer des ressources et réduisant le nombre total de connexions à la base de données.

    Remarque

    Le proxy de base de données lui-même n'impose pas de limite maximale de connexions ; cette limite est déterminée par les spécifications de la base de données backend.

    Limites

    • L'exécution des opérations suivantes verrouille la connexion jusqu'à sa fermeture. Une connexion verrouillée n'est pas renvoyée au pool de connexions pour réutilisation.

      • Exécuter une instruction ou une commande PREPARE.

      • Créer une table temporaire.

      • Modifier des variables utilisateur.

      • Traiter des paquets volumineux (par exemple, 16 Mo ou plus).

      • Utiliser LOCK TABLE.

      • Exécuter des requêtes multi-instructions.

      • Appeler une procédure stockée.

    • Les fonctions FOUND_ROWS, ROW_COUNT et LAST_INSERT_ID ne sont pas prises en charge. Vous pouvez appeler ces fonctions, mais leurs résultats ne sont pas garantis corrects.

      • Si la version du proxy est 1.13.11 ou ultérieure, vous pouvez utiliser la commande SELECT FOUND_ROWS() immédiatement après une instruction SELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT *. Toutefois, MySQL ne recommande plus cette utilisation. Nous vous recommandons de remplacer SELECT FOUND_ROWS() par SELECT COUNT(*) FROM tb1. Pour plus d'informations, consultez FOUND_ROWS().

      • Si la version du proxy est 1.13.11 ou ultérieure, vous pouvez utiliser l'instruction SELECT LAST_INSERT_ID() immédiatement après une instruction INSERT pour garantir un résultat de requête correct.

    Remarques d'utilisation

    • Pour les connexions où wait_timeout est défini, le paramètre wait_timeout peut ne pas prendre effet côté client car chaque demande récupère une connexion depuis le pool de connexions. Lorsque la période wait_timeout expire, seule la connexion dorsale dans le pool de connexions est déconnectée, ce qui ne provoque pas la déconnexion de la connexion cliente.

    • À l'exception des variables sql_mode, character_set_server, collation_server et time_zone, si votre application dépend d'autres variables système au niveau de la session, le client doit exécuter explicitement une instruction SET après l'établissement de la connexion. Sinon, le pool de connexions pourrait réutiliser une connexion dont les variables système ont été modifiées.

    • Étant donné que les connexions peuvent être réutilisées, vous pouvez exécuter select connection_id() pour interroger l'ID de thread de la connexion actuelle.

    • Étant donné que les connexions peuvent être réutilisées, l'adresse IP et le port affichés par show processlist ou SQL Explorer and Audit peuvent ne pas correspondre à l'adresse IP et au port réels du client.

    • Le proxy de base de données fusionne les résultats de show processlist de tous les nœuds et les renvoie. Les ID de thread des connexions frontales et dorsales ne peuvent pas être mappés. Cela peut entraîner une erreur de la commande KILL bien que celle-ci ait été exécutée avec succès.

    Regroupement de connexions au niveau des sessions

    Cas d'utilisation

    • Votre application utilise principalement des connexions éphémères.

    • Les connexions sont créées fréquemment.

    Avantages

    Réduit la fréquence d'établissement des connexions entre votre application et la base de données, ce qui diminue la charge sur le thread principal de la base de données MySQL.

    Fonctionnement

    Connexions frontales et dorsales

    Lorsqu'un client, tel qu'une application, établit une connexion avec une base de données, le proxy de base de données agit en tant qu'intermédiaire. Il divise la connexion en une connexion frontale entre le client et le proxy de base de données, et une connexion dorsale entre le proxy de base de données et la base de données, comme illustré dans la figure suivante.

    image

    Processus de connexion lorsque le regroupement de connexions est désactivé

    Si le regroupement de connexions est désactivé, le proxy crée une nouvelle connexion frontale et dorsale pour chaque session.

    image

    Fonctionnement du regroupement de connexions au niveau des sessions

    Lorsqu'une session est établie, le regroupement de connexions au niveau des sessions crée d'abord une connexion frontale. Ensuite, il vérifie la disponibilité d'une connexion dorsale dans le pool de connexions.

    Remarque

    Une connexion est considérée comme disponible si ses paramètres user, clientip et dbname correspondent à ceux de la demande.

    • Si une connexion disponible existe, elle est réutilisée.

    • Si aucune connexion disponible n'existe, une nouvelle connexion dorsale est établie avec la base de données.

    Lorsqu'une session se termine, le proxy déconnecte la connexion frontale et renvoie la connexion dorsale au pool. Cela permet à la connexion dorsale d'être réutilisée par une nouvelle session, ce qui réduit la charge sur le thread principal de la base de données.

    image

    Avec le regroupement de connexions au niveau des sessions, une session occupe une connexion dorsale jusqu'à la fin de la session. Ce n'est qu'à ce moment-là que la connexion dorsale est libérée vers le pool, comme illustré dans la figure suivante.

    image

    Limites

    Aucune.

    Remarques d'utilisation

    Avant la fin d'une session, sa connexion dorsale ne peut pas être utilisée par d'autres sessions, même si elle est inactive et n'a aucune transaction à traiter. Par conséquent, le regroupement de connexions au niveau des sessions ne réduit pas le nombre total de connexions à la base de données.

    Configurer le regroupement de connexions

    Prérequis

    Le proxy de base de données est activé.

    Remarques d'utilisation

    • La fonctionnalité de regroupement de connexions ne prend pas en charge l'attribution d'autorisations différentes au même compte en fonction d'adresses IP différentes. Si vous configurez des autorisations de base de données ou de table différentes pour le même compte sur différentes adresses IP (par exemple, user@192.xx.xx.1 dispose d'autorisations pour database_a, mais pas user@192.xx.xx.2), l'activation du regroupement de connexions peut entraîner des erreurs d'autorisation lors de la réutilisation des connexions.

    • Si votre application utilise déjà un pool de connexions côté client, vous n'avez pas besoin d'activer le regroupement de connexions du proxy de base de données.

    • Le regroupement de connexions ne peut pas résoudre un engorgement de connexions causé par de nombreuses requêtes SQL lentes. Nous vous recommandons d'optimiser vos requêtes SQL ou de diagnostiquer la cause de la lenteur sur l'instance MySQL.

    • Si la version du proxy est antérieure à 2.9.1, vous ne pouvez pas configurer le regroupement de connexions pour les endpoints de proxy en lecture seule. Si la version du proxy est 2.9.1 ou ultérieure, vous pouvez configurer le regroupement de connexions pour les endpoints de proxy en lecture/écriture et en lecture seule.

    Procédure

    1. Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région dans laquelle se trouve l'instance RDS. Recherchez ensuite l'instance RDS et cliquez sur son ID.

    2. Dans le volet de navigation de gauche, cliquez sur Database Proxy.

    3. Dans la section Connection Information, activez le regroupement de connexions en utilisant l'une des méthodes suivantes :

      Remarque

      • Le regroupement de connexions est désactivé par défaut.

      • Après avoir modifié le type de pool de connexions, la modification s'applique uniquement aux nouvelles connexions.

      • Méthode 1 : Placez le curseur sur l'icône image.png à droite de l'ID de l'endpoint 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 dans la boîte de dialogue de confirmation.

      • Méthode 2 : Dans la colonne Actions pour l'endpoint du proxy cible, cliquez sur Modify Configuration. Dans la boîte de dialogue qui s'affiche, sélectionnez le type de pool de connexions souhaité à côté de Connection Pooling pour l'activer.

        Remarque

        Si un type de pool de connexions est déjà activé, vous pouvez sélectionner un autre type pour le modifier.

        Dans cette boîte de dialogue, vous pouvez également configurer l'Attribut de lecture/écriture (options : Read/write (read/write splitting) ou Read-only), le Seuil de latence (plage : 0 à 3 600 secondes), le Fractionnement des transactions (activé ou désactivé) et l'Allocation du poids de lecture (options : System-assigned ou poids personnalisés).

    Référence API

    API

    Description

    DescribeDBProxy

    Interroge les détails du proxy de base de données pour une instance RDS.

    DescribeDBProxyEndpoint

    Interroge les informations sur les endpoints du proxy d'une instance RDS.

    ModifyDBProxyEndpoint

    Modifie la configuration d'un endpoint de proxy pour une instance RDS.

    Concepts clés

    • connexion éphémère : Connexion maintenue pendant une courte période seulement. Par exemple, une application PHP ferme une connexion après l'exécution d'une requête simple. Cette approche évite d'occuper une connexion pendant de longues périodes, mais nécessite l'établissement d'une nouvelle connexion pour chaque demande, augmentant ainsi la charge sur le thread principal de la base de données.

    • connexion persistante : Connexion maintenue pendant une longue période. Par exemple, un serveur web ou un serveur d'applications ouvre de nombreuses connexions vers un serveur MySQL et les maintient ouvertes jusqu'à l'arrêt du client. Cela réduit la charge sur le thread principal en minimisant les nouvelles demandes de connexion, mais occupe un canal de connexion pendant une durée prolongée.

    FAQ

    Q : À partir de quel nombre de connexions dois-je activer le regroupement de connexions ?

    R : Nous vous recommandons d'activer le regroupement de connexions au niveau des transactions lorsque le nombre de connexions approche la limite MySQL.

    Q : Combien de temps une connexion est-elle conservée dans le pool de connexions ?

    R : 10 secondes.

    Q : L'utilisation du regroupement de connexions affecte-t-elle les performances de l'instance ?

    R : Dans les scénarios avec des connexions éphémères, l'activation du regroupement de connexions peut améliorer les performances de l'instance d'environ 10 %.

    Q : Quelle est la différence fonctionnelle entre le regroupement de connexions au niveau des transactions et au niveau des sessions ?

    R : Le regroupement de connexions au niveau des transactions réduit à la fois la charge sur le thread principal et le nombre total de connexions. Le regroupement de connexions au niveau des sessions réduit uniquement la charge sur le thread principal.

    Q : En quoi le fonctionnement du regroupement de connexions au niveau des transactions diffère-t-il de celui au niveau des sessions ?

    R :

    Type de pool de connexions

    Partage de session

    Heure de récupération

    Heure de retour

    Mappage de connexion

    Au niveau des transactions

    Oui

    Lors du traitement d'une transaction

    Après le traitement d'une transaction (la session peut toujours être active)

    N:1

    Au niveau des sessions

    Non

    Lors de l'établissement d'une session

    Lors de la fin de la session

    N:N

    Q : La connexion du proxy de base de données a été déconnectée. Est-ce parce que l'application et le proxy de base de données utilisent tous deux le regroupement de connexions ?

    R : Une connexion peut être déconnectée pour de nombreuses raisons, pas nécessairement parce que l'application et le proxy utilisent tous deux le regroupement de connexions. La cause première dépend de votre charge de travail et de votre configuration spécifiques.