Contournement de l’épinglage d’un proxy RDS - Amazon Aurora
Ce que le proxy RDS suit pour les bases de données Aurora MySQLMinimiser l’épinglageConditions qui entraînent l’épinglage pour toutes les familles de moteursConditions qui entraînent l’épinglage pour Aurora MySQLConditions qui entraînent l’épinglage pour Aurora PostgreSQL

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.

Contournement de l’épinglage d’un proxy RDS

Le multiplexage est plus efficace lorsque les demandes de base de données ne dépendent pas des informations d’état issues de demandes précédentes. Dans ce cas, le proxy RDS peut réutiliser une connexion à la fin de chaque transaction. Ces informations d’état incluent la plupart des variables et des paramètres de configuration que vous pouvez modifier à l’aide des instructions SET ou SELECT. Les transactions SQL sur une connexion client peuvent se multiplexer entre les connexions de base de données sous-jacentes par défaut.

Vos connexions au proxy peuvent entrer dans un état appelé épinglage. Lorsqu’une connexion est épinglée, chaque transaction ultérieure utilise la même connexion de base de données sous-jacente jusqu’à la fin de la session. De même, les autres connexions client ne peuvent pas réutiliser cette connexion à la base de données tant que la session n’est pas terminée. La session se termine lorsque la connexion client est supprimée.

Le proxy RDS épingle automatiquement une connexion client à une connexion de base de données spécifique lorsqu’il détecte un changement d’état de session qui n’est pas approprié pour d’autres sessions. L’épinglage réduit l’efficacité de la réutilisation des connexions. Si la totalité, ou presque, de vos connexions font l’objet d’un épinglage, pensez à modifier le code de votre application ou votre charge de travail afin de réduire les conditions à l’origine de l’épinglage.

Par exemple, votre application modifie une variable de session ou un paramètre de configuration. Dans ce cas, les instructions ultérieures peuvent reposer sur la nouvelle variable ou le nouveau paramètre pour entrer en vigueur. Ainsi, lorsque le proxy RDS traite des demandes de modification des variables ou des paramètres de configuration de session, il épingle cette session à la connexion de base de données. De cette manière, l’état de session reste en vigueur pour toutes les transactions ultérieures de la même session.

Pour les moteurs de bases de données, cette règle ne s’applique pas à tous les paramètres que vous pouvez définir. Le proxy RDS suit certaines instructions et variables. Ainsi, le proxy RDS n’épingle pas la session lorsque vous les modifiez. Dans ce cas, le proxy RDS réutilise la connexion uniquement pour les autres sessions dont les valeurs de ces paramètres sont identiques. Pour les listes des instructions et des variables suivies pour Aurora MySQL, consultez Ce que le proxy RDS suit pour les bases de données Aurora MySQL.

Ce que le proxy RDS suit pour les bases de données Aurora MySQL

Le proxy RDS suit les instructions MySQL suivantes :

  • DROP DATABASE

  • DROP SCHEMA

  • USE

Le proxy RDS suit les variables MySQL suivantes :

  • AUTOCOMMIT

  • AUTO_INCREMENT_INCREMENT

  • CHARACTER SET (or CHAR SET)

  • CHARACTER_SET_CLIENT

  • CHARACTER_SET_DATABASE

  • CHARACTER_SET_FILESYSTEM

  • CHARACTER_SET_CONNECTION

  • CHARACTER_SET_RESULTS

  • CHARACTER_SET_SERVER

  • COLLATION_CONNECTION

  • COLLATION_DATABASE

  • COLLATION_SERVER

  • INTERACTIVE_TIMEOUT

  • NAMES

  • NET_WRITE_TIMEOUT

  • QUERY_CACHE_TYPE

  • SESSION_TRACK_SCHEMA

  • SQL_MODE

  • TIME_ZONE

  • TRANSACTION_ISOLATION (or TX_ISOLATION)

  • TRANSACTION_READ_ONLY (or TX_READ_ONLY)

  • WAIT_TIMEOUT

Note

Le proxy RDS suit les modifications apportées aux variables TRANSACTION_ISOLATION et TRANSACTION_READ_ONLY lorsque vous les définissez au cours dans le champ de la session. Toutefois, si vous les définissez lors du prochain champ de transaction, le proxy RDS épingle les connexions. Ce comportement s’applique que vous utilisiez une instruction SET ou SET TRANSACTION pour configurer ces valeurs.

Minimiser l’épinglage

Le réglage des performances du proxy RDS entraîne une tentative d’optimisation de la réutilisation des connexions au niveau de la transaction (multiplexage) en réduisant l’épinglage.

Vous pouvez minimiser l’épinglage en procédant comme suit :

  • Évitez les requêtes de base de données inutiles qui pourraient provoquer l’épinglage.

  • Définissez les variables et les paramètres de configuration de manière cohérente sur toutes les connexions. De cette façon, les sessions ultérieures sont plus susceptibles de réutiliser les connexions qui ont ces paramètres particuliers.

    En revanche, pour PostgreSQL, la définition d’une variable entraîne l’épinglage de la session.

  • Pour une base de données de la famille de moteur MySQL, appliquez un filtre d’épinglage de session au proxy. Vous pouvez configurer certains types d’opérations pour qu’elles n’épinglent pas la session si vous savez que cela n’affecte pas le bon fonctionnement de votre application.

  • Consultez la fréquence d’épinglage en surveillant la métrique Amazon CloudWatch DatabaseConnectionsCurrentlySessionPinned. Pour en savoir plus sur ce sujet et sur d’autres métriques CloudWatch, consultez Surveillance des métriques RDS Proxy avec Amazon CloudWatch.

  • Si vous utilisez des instructions SET pour exécuter une initialisation identique pour chaque connexion client, vous pouvez conserver le multiplexage au niveau de la transaction. Dans ce cas, vous déplacez les instructions qui définissent l’état initial de la session vers la requête d’initialisation utilisée par un proxy. Cette propriété est une chaîne contenant une ou plusieurs instructions SQL, séparées par des points-virgules.

    Par exemple, vous pouvez définir une requête d’initialisation pour un proxy qui établit certains paramètres de configuration. Le proxy RDS applique ensuite ces paramètres dès qu’il configure une nouvelle connexion pour ce proxy. Vous pouvez supprimer les instructions SET correspondantes de votre code d’application, afin qu’elles n’interfèrent pas avec le multiplexage au niveau de la transaction.

    Pour les métriques relatives à la fréquence d’épinglage d’un proxy, consultez Surveillance des métriques RDS Proxy avec Amazon CloudWatch.

Conditions qui entraînent l’épinglage pour toutes les familles de moteurs

Le proxy épingle la session à la connexion en cours dans les situations suivantes où le multiplexage peut entraîner un comportement inattendu :

  • Le proxy épingle la session si la taille de texte de l’instruction est supérieure à 16 Ko.

Conditions qui entraînent l’épinglage pour Aurora MySQL

Pour MySQL, les interactions suivantes entraînent également l’épinglage :

  • Le proxy épingle la session en cas d’instructions de verrouillage de table LOCK TABLE, LOCK TABLES ou FLUSH TABLES WITH READ LOCK explicites.

  • La création de verrous nommés à l’aide de GET_LOCK entraîne le proxy à épingler la session.

  • La définition d’une variable utilisateur ou système (sauf exceptions) épingle la session au proxy. Si cela limite considérablement la réutilisation des connexions, vous pouvez configurer des opérations SET pour éviter l’épinglage. Pour ce faire, ajustez la propriété des filtres d’épinglage de session. Pour plus d’informations, consultez Création d’un proxy pour Amazon Aurora et Modification d’un RDS Proxy.

  • Le proxy épingle la session lors de la création d’une table temporaire. De cette façon, le contenu de la table temporaire est conservé tout au long de la session, sans tenir compte des limites de transaction.

  • L’appel des fonctions ROW_COUNT et FOUND_ROWS entraîne parfois un épinglage.

    Les circonstances exactes dans lesquelles ces fonctions provoquent un épinglage peuvent différer selon les versions d’Aurora MySQL compatibles avec MySQL 5.7.

  • Le proxy épingle la session en cas d’instructions préparées. Cette règle s’applique si l’instruction préparée utilise du texte SQL ou le protocole binaire.

  • Le proxy RDS n’épingle pas les connexions lorsque vous utilisez SET LOCAL.

  • L’appel de procédures et de fonctions stockées ne provoque pas d’épinglage. Le proxy RDS ne détecte aucun changement d’état de session résultant de tels appels. Assurez-vous que votre application ne modifie pas l’état de session dans les routines stockées si vous reposez sur cet état de session pour persister entre les transactions. Par exemple, le proxy RDS n’est actuellement pas compatible avec une procédure stockée qui crée une table temporaire qui est conservée dans toutes les transactions.

Si vous avez des connaissances avancées sur le comportement de votre application, vous pouvez ignorer le comportement d’épinglage de certaines instructions d’application. Pour ce faire, sélectionnez l’option Filtres d’épinglage de session lors de la création du proxy. Actuellement, vous pouvez désactiver l’épinglage de session pour définir des variables de session et des paramètres de configuration.

Conditions qui entraînent l’épinglage pour Aurora PostgreSQL

Pour PostgreSQL, les interactions suivantes provoquent également l’épinglage :

  • Utilisation des commandes SET.

  • Utilisation des commandes PREPARE, DISCARD, DEALLOCATE ou EXECUTE pour gérer les instructions préparées.

  • Création de séquences, de tables ou de vues temporaires.

  • Déclaration de curseurs.

  • Suppression de l’état de la session.

  • Écoute d’un canal de notification.

  • Chargement d’un module de bibliothèque comme auto_explain.

  • Manipulation de séquences à l’aide de fonctions comme nextval et setval.

  • Interaction avec des verrous à l’aide de fonctions comme pg_advisory_lock et pg_try_advisory_lock.

    Note

    Le proxy RDS ne s’épingle pas aux verrous consultatifs au niveau des transactions, en particulier pg_advisory_xact_lock, pg_advisory_xact_lock_shared, pg_try_advisory_xact_lock et pg_try_advisory_xact_lock_shared.

  • Définition d’un paramètre ou rétablissement de sa valeur par défaut. Plus précisément, l’utilisation des commandes SET et set_config pour attribuer des valeurs par défaut aux variables de session.

  • L’appel de procédures et de fonctions stockées ne provoque pas d’épinglage. Le proxy RDS ne détecte aucun changement d’état de session résultant de tels appels. Assurez-vous que votre application ne modifie pas l’état de session dans les routines stockées si vous reposez sur cet état de session pour persister entre les transactions. Par exemple, le proxy RDS n’est actuellement pas compatible avec une procédure stockée qui crée une table temporaire qui est conservée dans toutes les transactions.

  • Suppression de l’état de la session. Si vous utilisez des bibliothèques de regroupement de connexions avec une requête DISCARD ALL configurée comme une requête de réinitialisation, le proxy RDS épingle votre connexion client lors de la publication. Cela réduit l’efficacité du multiplexage du proxy et peut entraîner des résultats inattendus, car la commande DISCARD ALL peut interférer avec la gestion de l’état de session.