Éviter d'épingler un proxy RDS - Amazon Aurora
Ce que RDS Proxy suit pour les SQL bases de données Aurora MyMinimiser l'épinglageConditions qui entraînent l'épinglage pour toutes les familles de moteursConditions à l'origine de l'épinglage pour Aurora My SQLConditions à l'origine de l'épinglage pour Aurora Postgre SQL

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.

Éviter d'épingler 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, RDS Proxy 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. SQLles transactions sur une connexion client peuvent être multiplexées 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.

RDSLe proxy associe 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 les 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 RDS proxy traite les demandes de modification des variables de session ou des paramètres de configuration, il associe cette session à la connexion à la 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. RDSLe proxy suit certaines instructions et variables. Ainsi, le RDS proxy n'épingle pas la session lorsque vous les modifiez. Dans ce cas, le RDS proxy ne réutilise la connexion que pour les autres sessions qui ont les mêmes valeurs pour ces paramètres. Pour les listes des instructions suivies et des variables pour Aurora MySQL, voirCe que RDS Proxy suit pour les SQL bases de données Aurora My.

Ce que RDS Proxy suit pour les SQL bases de données Aurora My

Voici les Mes SQL déclarations suivies RDS par Proxy :

  • DROP DATABASE

  • DROP SCHEMA

  • USE

Voici les SQL variables Mes variables suivies par le RDS proxy :

  • 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

Minimiser l'épinglage

L'optimisation des performances du RDS proxy implique d'essayer de maximiser la réutilisation des connexions au niveau des transactions (multiplexage) en minimisant le pinning.

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.

    Cependant, pour Postgre, la SQL définition d'une variable entraîne un épinglage de session.

  • Pour une base de données de la famille My SQL engine, 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.

  • Découvrez la fréquence de l'épinglage en surveillant la CloudWatch métrique DatabaseConnectionsCurrentlySessionPinned Amazon. Pour plus d'informations à ce sujet et sur d'autres CloudWatch mesures, consultezSurveillance des métriques du proxy RDS 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 SQL instructions, 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. RDSProxy applique ensuite ces paramètres chaque fois qu'il établit 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, veuillez consulter Surveillance des métriques du proxy RDS 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 à l'origine de l'épinglage pour Aurora My SQL

Pour MySQL, les interactions suivantes sont également à l'origine du pinning :

  • 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.

  • Le proxy épingle la session lors de la définition d'une variable utilisateur ou d'une variable système (à quelques exceptions près). Si cette situation réduit trop la réutilisation de votre connexion, optez pour SET des opérations qui ne provoquent pas d'épinglage. Pour plus d'informations sur la manière de procéder en définissant la propriété des filtres d'épinglage de session, consultez Création d'un RDS proxy et Modification du 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, FOUND_ROWS et LAST_INSERT_ID entraîne parfois un épinglage.

    Les circonstances exactes dans lesquelles ces fonctions provoquent l'épinglage peuvent différer selon les SQL versions d'Aurora My compatibles avec My SQL 5.7.

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

  • RDSLe proxy n'épingle pas les connexions lorsque vous l'utilisez SETLOCAL.

  • L'appel de procédures et de fonctions stockées ne provoque pas d'épinglage. RDSLe proxy 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 comptez sur cet état de session pour qu'il persiste dans toutes les transactions. Par exemple, RDS Proxy n'est actuellement pas compatible avec une procédure stockée qui crée une table temporaire qui persiste 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 à l'origine de l'épinglage pour Aurora Postgre SQL

Pour PostgreSQL, les interactions suivantes sont également à l'origine du pinning :

  • À l'aide de SET commandes.

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

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

  • Déclarer des curseurs.

  • Suppression de l'état de session.

  • Écoute sur un canal de notification.

  • Chargement d'un module de bibliothèque tel queauto_explain.

  • Manipulation de séquences à l'aide de fonctions telles que nextval et. setval

  • Interaction avec les verrous à l'aide de fonctions telles que pg_advisory_lock etpg_try_advisory_lock.

    Note

    RDSLe proxy n'épingle pas les verrous consultatifs au niveau des transactionspg_advisory_xact_lock, en particulier pg_advisory_xact_lock_sharedpg_try_advisory_xact_lock,, etpg_try_advisory_xact_lock_shared.

  • Définition d'un paramètre ou réinitialisation d'un paramètre à sa valeur par défaut. Plus précisément, utiliser SET des set_config commandes et 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. RDSLe proxy 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 comptez sur cet état de session pour qu'il persiste dans toutes les transactions. Par exemple, RDS Proxy n'est actuellement pas compatible avec une procédure stockée qui crée une table temporaire qui persiste dans toutes les transactions.