Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Directives de configuration
Cette section décrit les paramètres disponibles dans RDS Proxy et fournit les meilleures pratiques pour aligner la configuration sur l'ensemble de la pile d'applications. Il s'agit de directives combinées pour l'utilisation du proxy RDS avec Amazon RDS et Amazon Aurora. RDS-specific et les Aurora-specific notes sont signalées le cas échéant.
Sauf indication contraire, les termes « base de données » ou « cible » font référence à un cluster Aurora, à un cluster de Multi-AZ base de données Amazon RDS ou à une instance Amazon RDS.
Rubriques
Paramètres du proxy RDS
MaxConnectionsPercent
| Valeur minimale | Valeur maximale | Valeur par défaut |
|---|---|---|
| le moins élevé des montants suivants : (1 MaxIdleConnectionsPercent) | 100 | 100 |
Pour de plus amples informations, veuillez consulter MaxConnectionsPercent.
Ce paramètre limite le nombre de connexions que le proxy RDS peut établir avec la base de données cible, en pourcentage du nombre maximum de connexions autorisées par la base de données. Le proxy ouvre les connexions principales selon les besoins, de sorte que le nombre réel de connexions à un moment donné peut être inférieur au maximum configuré.
Étant donné que le MaxConnectionsPercent paramètre est un pourcentage de la limite de connexion à la base de données, la taille du pool de connexions du proxy suit automatiquement la configuration de la base de données. Cela signifie que vous n'avez pas besoin de reconfigurer vos proxys chaque fois que vous redimensionnez vos instances de base de données ou que vous apportez des modifications à la configuration. Cela signifie également que vous devez être conscient des scénarios dans lesquels les paramètres de base de données peuvent changer, que ce soit implicitement ou explicitement :
-
Si vous n'avez pas défini explicitement la limite de connexion (comme le
max_connectionsparamètre) dans le groupe de paramètres de votre base de données, Amazon RDS et Aurora la calculent automatiquement en fonction de la classe d'instance de base de données. Par conséquent, la limite de connexion implicite peut changer lorsque vous dimensionnez vos instances de base de données, influençant ainsi la taille maximale du pool dans le proxy. Pour plus d'informations, consultez les sections Nombre maximal de connexions à la base de données dans le Guide de l'utilisateur Amazon RDS, Nombre maximal de connexions à une instance de base de données Aurora MySQL et Nombre maximal de connexions à une instance de base de données Aurora PostgreSQL dans le Guide de l'utilisateur Amazon Aurora. -
Les instances de base de données Aurora Serverless v2 déterminent leur limite de connexion en fonction de la configuration ACU maximale de la base de données. Pour plus de détails, consultez la section Nombre maximal de connexions pour Aurora Serverless v2 dans le guide de l'utilisateur Amazon Aurora.
Bonnes pratiques :
-
Le paramètre par défaut de 100 % convient aux bases de données qui reçoivent tout leur trafic via le proxy et qui n'ont pas besoin d'une marge de manœuvre pour l'accès administratif ou pour d'autres clients.
-
Réduisez ce paramètre lorsque la base de données reçoit également du trafic provenant directement des applications (en contournant le proxy) et que vous ne voulez pas que le proxy consomme toutes les connexions, ou lorsque vous souhaitez réserver un certain nombre de connexions à d'autres fins, telles que l'accès direct par les administrateurs de base de données.
-
Lorsque vous utilisez le proxy RDS avec des clusters de base de données Aurora Global et que le transfert d'écriture est activé, réduisez la
MaxConnectionsPercentvaleur de votre proxy par le quota alloué au transfert d'écriture. Pour plus de détails, consultez les paramètres de configuration pour le transfert d'écriture dans Aurora MySQL et Aurora PostgreSQL dans le guide de l'utilisateur Amazon Aurora. Cette recommandation s'applique que le proxy dessert un cluster dans la région principale ou secondaire de la base de données globale. Les clusters secondaires peuvent être promus au rôle principal. Il est donc recommandé de garantir la cohérence des paramètres de proxy sur l'ensemble de la topologie globale. Vous pouvez utiliser des paramètres asymétriques pour les proxys desservant les régions principales par rapport aux régions secondaires, mais vous devrez ajuster ces paramètres après chaque basculement ou basculement global. -
Si la cible dessert plusieurs proxys, la valeur combinée de
MaxConnectionsPercenttous ces proxys ne doit pas dépasser 100 afin que la base de données ne soit pas surabonnée. Nous recommandons d'utiliser un seul proxy par cible afin de simplifier la configuration et la gestion. En particulier, il n'est pas nécessaire d'utiliser plusieurs proxys par base de données à des fins de redondance. Pour de plus amples informations, veuillez consulter Utilisation de plusieurs proxys avec une seule cible.
Que vous utilisiez le MaxConnectionsPercent paramètre par défaut ou une valeur personnalisée, maintenez une marge d'au moins 30 % entre le nombre de connexions autorisées et le nombre maximum de connexions clients attendues pendant les périodes de pointe. Par exemple :
-
Si vous pensez que le proxy aura besoin de 50 % de la limite de connexion configurée pour la base de données, utilisez un
MaxConnectionsPercentparamètre d'au moins1.3 * 50% = 65%. -
Lorsque vous utilisez le
MaxConnectionsPercentparamètre par défaut de 100, assurez-vous que la limite de base de données elle-même fournit une marge de manœuvre suffisante.
Cette marge de manœuvre supplémentaire améliore l'expérience client lors de pics de charge de travail inattendus et aide RDS Proxy à redistribuer les connexions au sein de son infrastructure interne à des fins de gestion de la chaleur et à d'autres fins.
Bien que vous puissiez MaxConnectionsPercent définir une valeur inférieure à 1, nous recommandons les minimums suivants en fonction du type d'instance :
db.t3.small : 100
db.t3.medium : 55
db.t3.large : 35
db.r3.large ou supérieur : 20
MaxIdleConnectionsPercent
| Valeur minimale | Valeur maximale | Valeur par défaut (SQL Server) | Valeur par défaut (autres moteurs) |
|---|---|---|---|
| (zéro) | MaxConnectionsPercent | 5 % des MaxConnectionsPercent | 50 % des MaxConnectionsPercent |
Pour de plus amples informations, veuillez consulter MaxIdleConnectionsPercent.
Ce paramètre limite le nombre de connexions de base de données inactives que le proxy RDS conserve dans le pool de connexions, en pourcentage du nombre maximum de connexions autorisées par la base de données. Une connexion à une base de données (back-end) est considérée comme inactive lorsqu'aucune activité n'a été enregistrée pendant cinq minutes. Ce paramètre s'applique aux connexions entre le proxy et la base de données principale.
Notez ce qui suit :
-
Ce paramètre limite le nombre de connexions inactives dans le pool, mais n'oblige pas le proxy à conserver un nombre donné de connexions inactives. Si l'activité du client est très faible, le nombre réel de connexions à la base de données principale peut être inférieur
MaxIdleConnectionsPercentà. -
Les connexions sont considérées comme inactives lorsqu'elles peuvent être réutilisées dans le pool de connexions du proxy. Les connexions épinglées ne peuvent pas être réutilisées par d'autres clients et ne sont donc pas considérées comme inactives aux fins de leur application.
MaxIdleConnectionsPercentPour plus d'informations sur l'épinglage, consultezContournement de l’épinglage d’un proxy RDS. -
Le nombre de connexions inactives indiqué par les métadonnées de base de données est généralement supérieur au nombre de connexions inactives enregistrées par les métriques du proxy RDS. Cela peut être dû à des connexions clients directes contournant le proxy ainsi qu'à des connexions internes utilisées par Amazon RDS et Aurora Automation.
Note
Le temps d'inactivité de connexion observé et appliqué au niveau de la couche proxy peut être différent du temps d'inactivité indiqué par les outils de base de données tels que la liste des processus MySQL ou les tables de statistiques d'activité de PostgreSQL. Le proxy RDS envoie occasionnellement des requêtes ping aux connexions principales, ce qui réinitialise les délais d'inactivité de la base de données même si la connexion reste inactive en termes d'activité du client.
Bonnes pratiques :
Le paramètre par défaut de 50 convient et est recommandé pour la plupart des charges de travail. La modification du paramètre a l'effet suivant :
-
Lorsque vous augmentez
MaxIdleConnectionsPercent, la base de données observe un plus grand nombre de connexions inactives, ce qui peut augmenter la consommation de ressources de la base de données en dehors des heures de pointe. D'autre part, les pics de connexion gérés par le biais du proxy entraînent une latence d'emprunt plus faible, car le pool contient un plus grand nombre de connexions facilement disponibles. -
Lorsque vous baissez
MaxIdleConnectionsPercent, le proxy ferme les connexions inactives de manière plus agressive, ce qui peut réduire les conflits et la consommation de ressources causés par ces connexions. Toutefois, les pics de connexion passant par le proxy peuvent entraîner des délais d'emprunt plus longs. Comme il y a moins de connexions disponibles dans le pool, le proxy doit passer plus de temps à ouvrir de nouvelles connexions principales en cas de pic.
La consommation de ressources par les connexions inactives n'est peut-être pas un problème majeur dans les bases de données utilisant des types d'instance provisionnés, mais les bases de données Aurora utilisant le type d'instance Serverless v2 peuvent préférer optimiser la consommation des ressources inactives afin de réduire les coûts.
IdleClientTimeout
| Valeur minimale | Valeur maximale | Valeur par défaut |
|---|---|---|
| 1 minute | 8 heures | 30 minutes |
Pour de plus amples informations, veuillez consulter IdleClientTimeout.
Ce paramètre détermine la durée pendant laquelle une connexion client peut rester inactive avant que le proxy ne la ferme. Notez que le proxy RDS impose une durée de vie maximale de 24 heures, que la connexion soit inactive ou non. Par exemple, si vous configurez IdleClientTimeout sur 30 minutes (par défaut) et que vous envoyez un ping à la base de données toutes les minutes, la connexion ne dépasse jamais le délai d'inactivité, mais elle ne reste pas ouverte indéfiniment. Le proxy RDS ferme la connexion au bout de 24 heures, même si elle n'est pas considérée comme inactive.
Le IdleClientTimeout paramètre s'applique à la connexion entre un client (applications ou utilisateurs interactifs) et le proxy RDS. Pour comprendre le comportement inactif des connexions principales entre le proxy RDS et la base de données, consultez. MaxIdleConnectionsPercent
Bonnes pratiques :
-
Le délai d'inactivité doit être suffisamment long pour permettre les pauses normales de l'activité SQL au sein d'une connexion ou d'une transaction client. Elle ne doit pas être trop longue pour permettre à un client de conserver des ressources dont il n'a raisonnablement plus besoin, mais dont d'autres clients pourraient avoir besoin. Cela est particulièrement important si vous observez un épinglage de connexion, car une connexion épinglée par un client ne peut pas être réutilisée par d'autres clients.
-
Pour que le proxy RDS applique correctement le délai d'expiration, la connexion client doit être réellement inactive sans envoyer de requêtes (même de simples vérifications de santé, par exemple
SELECT 1;) ou de pings de protocole (comme dansCOM_PINGMySQL). Si vous constatez que les connexions ne sont pas fermées malgré le dépassement du délai, vérifiez la logique de connexion des pilotes de votre application. Application-level les pools de connexions sont particulièrement susceptibles d'effectuer leurs propres contrôles de durée de vie, interférant avec.IdleClientTimeout
ConnectionBorrowTimeout
| Valeur minimale | Valeur maximale | Valeur par défaut |
|---|---|---|
| (zéro) | 5 minutes | 2 minutes |
Pour de plus amples informations, veuillez consulter ConnectionBorrowTimeout.
Lorsqu'un client se connecte au proxy RDS, le proxy doit soit emprunter une connexion disponible existante au pool, soit ouvrir une nouvelle connexion à la base de données. Ce paramètre définit la durée pendant laquelle le proxy RDS attend qu'une connexion soit empruntée ou ouverte avant de renvoyer une erreur.
Notez ce qui suit :
-
Une valeur nulle entraîne
ConnectionBorrowTimeoutdes erreurs de temporisation lorsque le pool de connexions ne contient pas encore de connexion disponible. Cela est vrai même si le pool est inférieur à sa capacité maximale et pourrait ouvrir une nouvelle connexion principale. -
Même avec un nombre
MaxIdleConnectionsPercentégal àMaxConnectionsPercent, le nombre réel de connexions dans le pool peut être inférieur au maximum configuré. En d'autres termes,MaxIdleConnectionsPercentlimite le nombre de connexions inactives mais n'oblige pas les connexions à rester ouvertes.
Il est normal qu'un pool de connexions soit inférieur à sa capacité maximale. Dans ce cas, l'utilisation d'un ConnectionBorrowTimeout paramètre de zéro peut empêcher le pool de s'agrandir car le pool n'est pas autorisé à attendre l'ouverture d'une nouvelle connexion. Par conséquent, vous devez utiliser des ConnectionBorrowTimeout valeurs différentes de zéro pour toutes les charges de travail, sauf si le comportement décrit précédemment est préférable.
Note
Ce paramètre s'applique également lorsque la base de données n'est pas prête à accepter des connexions, par exemple lors d'opérations de maintenance hors ligne et de basculements sur incident. La logique d'application ConnectionBorrowTimeout est la même, que la base de données soit active ou inactive.
Requêtes d'initialisation et filtres d'épinglage
Le proxy RDS prend en charge des fonctionnalités supplémentaires qui peuvent réduire l'épinglage des connexions et améliorer ainsi l'efficacité du multiplexage.
Une requête d'initialisation est une ou plusieurs instructions exécutées chaque fois que le proxy établit une nouvelle connexion à la base de données principale. Si vos clients utilisent des instructions identiques pour configurer les paramètres de session, vous pouvez déplacer ces instructions vers la requête d'initialisation du proxy. Cela permet de réduire la probabilité d'épinglage et d'améliorer l'efficacité : une connexion donnée à une base de données principale exécute sa requête d'initialisation une fois pendant l'installation, mais elle peut être réutilisée ultérieurement par de nombreux clients. N'oubliez pas que le fait de placer des instructions SQL dans la requête d'initialisation ne les filtre pas du trafic client. Vous devez tout de même supprimer ces instructions du code de l'application afin qu'elles n'interfèrent pas avec le multiplexage.
Les filtres d'épinglage de session sont une propriété de configuration qui empêche le proxy d'épingler certains états de session. La seule option de filtre actuellement disponible indique au proxy d'ignorer toutes les SET instructions lorsqu'il détermine si une session doit être épinglée. EXCLUDE_VARIABLE_SETS Les SET instructions sont toujours transmises à la base de données et peuvent affecter l'état de la session, ce qui signifie que cette option n'est sûre que dans les situations suivantes :
-
Les
SETinstructions sont inopérantes, telles que la définition d'une variable système à une valeur identique à la valeur par défaut du serveur. -
Les
SETinstructions et les requêtes suivantes font partie de la même transaction, et chaque transaction définit son propre état de manière totalement indépendante afin de ne pas être affectée par les variables définies par d'autres transactions.
Note
Le filtre d'EXCLUDE_VARIABLE_SETSépinglage est un paramètre « tout ou rien » et vous ne pouvez pas choisir de manière sélective les SET instructions à ignorer. N'utilisez pas ce filtre comme solution globale pour l'épinglage, sauf si votre cas d'utilisation correspond à l'une des catégories décrites dans la liste précédente.
Pour de meilleurs résultats, supprimez les instructions inutiles du code de l'application dans la mesure du possible, et utilisez des filtres uniquement si les modifications de l'application ne sont pas possibles. Cela favorise un environnement client-serveur moins bruyant et plus prévisible, au lieu d'appliquer un traitement spécial aux instructions qui ne sont pas nécessaires au départ.
Important
Ni les requêtes d'initialisation ni les filtres d'épinglage n'obligent RDS Proxy à modifier le trafic de requêtes client-serveur. Les instructions provenant des clients sont toujours transmises à la base de données, quelle que soit la configuration de la requête d'initialisation ou du filtre d'épinglage.
Pour en savoir plus, consultez :
-
Création d'un proxy et modification d'un proxy pour Amazon RDS.
-
Création d'un proxy et modification d'un proxy pour Amazon Aurora.
Pour les connexions PostgreSQL, vous pouvez également indiquer les paramètres de connexion pris en charge dans le message de démarrage échangé entre le pilote client et le proxy. Cela permet d'éviter d'envoyer des SET commandes séparées, ce qui réduit les allers-retours et évite le blocage des connexions causé par des instructions explicites. SET Pour de plus amples informations, veuillez consulter Considérations relatives à la connexion à PostgreSQL.
Alignement de la configuration de l'application, du proxy et de la base de données
Comme indiqué dans la section précédente, RDS Proxy prend en charge une série de paramètres pour vous aider à adapter le comportement du proxy aux besoins de votre application. Cependant, le choix des bonnes valeurs de configuration est une tâche qui concerne toutes les couches de la pile : l'application, le proxy et la base de données elle-même. Les paramètres de tous ces composants doivent être alignés sur les objectifs suivants :
-
Fournir le niveau de performance et d'évolutivité attendu pendant les opérations normales.
-
Améliorez la clarté et la facilité de résolution des problèmes liés à la charge de travail.
-
Aidez la pile à faire face à des événements inattendus (tels que des pics de charge de travail) avec un impact minimal sur l'application.
Lorsque vous choisissez et ajustez les paramètres dans un environnement multicouche, essayez d'aligner les valeurs de configuration de telle sorte que les limites et les délais d'une couche inférieure soient égaux ou supérieurs aux limites et délais d'expiration correspondants d'une couche supérieure. En d'autres termes, considérez les paramètres d'une couche comme une enveloppe qui s'insère dans l'enveloppe de configuration suivante située plus bas dans la pile.
Supposons, par exemple, que votre application soit la couche supérieure, le proxy la couche intermédiaire et la base de données la couche inférieure. Si les délais et les limites au niveau du proxy sont inférieurs aux limites au niveau de l'application, les limites du proxy prévalent sur les limites des applications. L'application n'est pas en mesure d'exercer ses paramètres et présente des comportements qui ne peuvent être expliqués par sa propre configuration.
Prenons l'exemple du paramètre du IdleClientTimeout proxy. Si les pilotes de votre application ou vos groupes de clients appliquent leurs propres délais d'inactivité, le délai d'inactivité du proxy constitue un filet de sécurité qui vient s'ajouter aux paramètres de l'application. Cela signifie que le délai d'inactivité IdleClientTimeout doit être au moins égal à tout délai d'inactivité au niveau de l'application pour éviter toute confusion :
-
Lorsque le délai d'inactivité de l'application est inférieur au délai d'expiration du proxy, vous vous attendez à ce que l'application ferme ses connexions conformément à la configuration. Si l'application ne parvient pas à fermer les connexions inactives à temps, le proxy agit comme un filet de sécurité.
-
Lorsque le délai d'inactivité de l'application est supérieur au délai d'expiration du proxy, l'application peut connaître des fermetures de connexion considérées comme prématurées. Cela peut être source de confusion du côté de l'application.
La même logique s'applique aux autres paramètres tels que les limites de connexion : les paramètres de chaque couche doivent correspondre à l'enveloppe définie par la configuration de la couche suivante.
Pour de meilleurs résultats, les paramètres de configuration doivent inclure un certain rembourrage entre une couche et la suivante. Par exemple, vous pouvez prolonger le délai d'expiration du proxy de quelques secondes par rapport au délai d'expiration de l'application pour éviter des erreurs sporadiques dues à une dérive de l' client/server horloge, ou au cas où le client aurait besoin de plus de temps pour fermer correctement la connexion.
En d'autres termes, alignez vos paramètres comme suit :
client timeout < proxy timeout < database timeout
Au lieu de faire ceci :
client timeout = proxy timeout = database timeout
Et évitez cela :
client timeout > proxy timeout > database timeout
Configuration de base de données
Limites de connexions
Le proxy RDS utilise ce MaxConnectionsPercent paramètre pour déterminer la taille maximale de son pool de connexions, ce qui signifie que la taille du pool de connexions du proxy est relative à la limite de connexion de la base de données. Lorsque vous modifiez la limite de connexion de la base de données, la taille du pool du proxy suit automatiquement. Si vous souhaitez que la base de données réserve une partie de la limite de connexion aux utilisateurs non proxy, vous devez le faire en abaissant le MaxConnectionsPercent paramètre dans le proxy plutôt qu'en augmentant la limite de base de données.
Le proxy RDS n'élimine pas la nécessité de configurer correctement les limites de connexion à la base de données. Une connexion proxy unique n'est pas intrinsèquement plus légère qu'une connexion client directe. N'augmentez donc pas les limites de la base de données uniquement parce que vous utilisez un proxy. Un proxy ne réduit pas la quantité de travail que la base de données doit effectuer pour traiter les requêtes, mais il permet à la base de données de gérer la même charge de travail en utilisant moins de connexions.
Délais d'inactivité
Les bases de données peuvent imposer leurs propres délais d'inactivité, par exemple en utilisant les interactive_timeout paramètres wait_timeout et dans MySQL ou les idle_in_transaction_session_timeout paramètres transaction_timeout et dans PostgreSQL. Il est peu probable que les valeurs par défaut de ces paramètres interfèrent avec la configuration du proxy, mais si vous utilisez des délais d'expiration personnalisés au niveau de la base de données, assurez-vous qu'ils sont au moins aussi longs que les délais d'expiration du proxy correspondants, faute de quoi le proxy rencontrera des erreurs de connexion en raison de délais prématurés.
La même logique s'applique aux environnements de base de données utilisant des tueurs de connexion, qui sont des scripts ou des processus qui surveillent l'état des sessions et interrompent activement les connexions en fonction de certains critères. Si votre environnement utilise de telles techniques, assurez-vous que la logique de terminaison de connexion est conforme aux paramètres du proxy.
Les bases de données qui gèrent l'ensemble de leur charge de travail via le proxy peuvent généralement dépendre de la configuration du proxy pour les délais d'inactivité et conserver les paramètres au niveau de la base de données à leurs valeurs par défaut.
Configuration de l'application
Gestion de l'état de session
De nombreux pilotes de base de données, frameworks d'applications et outils de mappage relationnel objet (ORM) utilisent des variables de session ou des SET instructions pour configurer des connexions avant d'envoyer le trafic de requêtes. L'utilisation d'instructions d'initialisation de connexion et de transaction peut ne pas être évidente si l'on considère uniquement le code de l'application, et il peut y avoir plusieurs couches d'abstraction entre la base de données elle-même et les instructions SQL et la logique de l'application. Vous pouvez utiliser la fonctionnalité de journalisation améliorée du proxy RDS pour enregistrer les raisons de l'épinglage des connexions, et les journaux de requêtes de base de données peuvent fournir des informations supplémentaires sur toutes les instructions envoyées via vos connexions à la base de données.
Tenez compte des bonnes pratiques suivantes :
-
Définissez les paramètres de connexion uniquement lorsqu'ils sont différents des valeurs par défaut de la base de données et que la session client doit s'en écarter. La suppression des instructions d'initialisation inutiles facilite non seulement le multiplexage, mais elle réduit également le nombre d'allers-retours client-serveur pour chaque nouvelle connexion à la base de données.
-
Définissez les variables et les paramètres de configuration de manière cohérente sur toutes les connexions.
-
Évitez la configuration de session qui peut également être appliquée lors de l'exécution de la requête. Par exemple, si différents clients ont besoin de voir des données dans différents fuseaux horaires, envisagez d'utiliser les fonctions de conversion de fuseau horaire au niveau de la requête plutôt que de définir le fuseau horaire au niveau de la session.
-
Si possible, déplacez les instructions de configuration de session vers la couche proxy à l'aide de la fonction de requête d'initialisation. Pour en savoir plus, consultez Requêtes d'initialisation et filtres d'épinglage.
Contrôles de vitalité
Si votre application utilise le regroupement de connexions ou des pilotes avancés, recherchez la configuration liée aux contrôles de réactivité, tels que les pings de protocole, les instructions de vérification de l'état ou les requêtes de maintien en vie. Le proxy RDS traite toutes les demandes des clients de la même manière. Ainsi, même si une SELECT 1; requête ou une COM_PING demande est interdite du point de vue de l'application, cela empêche le proxy d'imposer des délais d'inactivité aux clients et de gérer la taille du pool de connexions en conséquence. MaxIdleConnectionsPercent
Note
Le proxy RDS impose une durée de vie maximale de 24 heures, quelle que soit l'activité de la connexion.
Dans la plupart des cas, il peut être approprié de désactiver les contrôles de réactivité côté client afin de réduire le bruit du protocole et d'aider le proxy RDS à gérer les connexions inactives. Dans certains cas extrêmes, vous souhaiterez peut-être exécuter ces contrôles de santé malgré tout :
-
Vous souhaitez délibérément empêcher l'expiration du délai de certaines connexions dans la couche proxy.
-
Vous souhaitez autoriser le pilote ou le pool d'applications à détecter de manière proactive lorsqu'une connexion est interrompue par le proxy. Par exemple, les connexions dorsales épinglées peuvent être fermées en raison du redémarrage de la base de données et les connexions client peuvent dépasser la durée de vie maximale de 24 heures.
Envisagez de désactiver les contrôles de réactivité du côté de l'application ou de les exécuter uniquement pour les connexions spécifiques dont vous souhaitez empêcher l'expiration du délai.
Suivi de l'état des sessions
Certains pilotes de base de données MySQL, tels que le pilote MariaDB, session_track_* utilisent des variables pour permettre le suivi de l'état de la session. Lorsque cette fonctionnalité est activée, chaque fois que le client effectue un changement d'état de session que le serveur peut suivre, le serveur inclut les informations de changement d'état dans ses paquets de réponse. Cela permet au pilote d'être informé de l'état de la session par le serveur.
Cette méthode de suivi de l'état de session peut être utile lorsque le client interagit directement avec le serveur et implémente ses propres fonctionnalités de gestion de session, telles que la migration de session dans des environnements multiserveurs. RDS Proxy implémente ses propres mécanismes de suivi de l'état et n'utilise pas les informations activées par session_track_* les variables, mais la définition de ces variables entraîne le blocage de session.
Si le pilote de votre base de données définit ces variables, vous pouvez rechercher des moyens de désactiver la fonctionnalité de suivi dans le pilote, de passer à un autre pilote ou d'utiliser des filtres d'épinglage de session pour ignorer les instructions si vous pouvez le faire en toute sécurité. Pour en savoir plus, consultez Requêtes d'initialisation et filtres d'épinglage.
