Éviter d'épingler un proxy RDS - Amazon Relational Database Service
Ce que RDS Proxy suit pour les bases de données RDS for SQL ServerCe que RDS Proxy suit pour les bases de données RDS for MariaDB et RDS for MySQLMinimiser l'épinglageConditions qui entraînent l'épinglage pour toutes les familles de moteursConditions qui entraînent l'épinglage pour RDS for Microsoft SQL ServerConditions qui entraînent l'épinglage pour RDS for MariaDB et RDS for MySQLConditions qui entraînent l'épinglage pour RDS for 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.

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

RDS Proxy é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 RDS Proxy 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. RDS Proxy suit certaines instructions et variables. Ainsi, le proxy RDS n'épingle pas la session lorsque vous les modifiez. Dans ce cas, RDS Proxy réutilise la connexion uniquement pour les autres sessions dont les valeurs de ces paramètres sont identiques. Pour plus de détails sur ce que RDS Proxy suit pour un moteur de base de données, consultez ce qui suit :

Ce que RDS Proxy suit pour les bases de données RDS for SQL Server

Le proxy RDS suit les instructions SQL Server suivantes :

  • USE

  • SET ANSI_NULLS

  • SET ANSI_PADDING

  • SET ANSI_WARNINGS

  • SET ARITHABORT

  • SET CONCAT_NULL_YIELDS_NULL

  • SET CURSOR_CLOSE_ON_COMMIT

  • SET DATEFIRST

  • SET DATEFORMAT

  • SET LANGUAGE

  • SET LOCK_TIMEOUT

  • SET NUMERIC_ROUNDABORT

  • SET QUOTED_IDENTIFIER

  • SET TEXTSIZE

  • SET TRANSACTION ISOLATION LEVEL

Ce que RDS Proxy suit pour les bases de données RDS for MariaDB et RDS for MySQL

RDS Proxy suit les instructions MariaDB et MySQL suivantes :

  • DROP DATABASE

  • DROP SCHEMA

  • USE

RDS Proxy suit les variables MySQL et MariaDB 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 TRANSACTION_READ_ONLY variables TRANSACTION_ISOLATION et lorsque vous les définissez au cours de la session. Toutefois, si vous les définissez lors de la prochaine transaction, le proxy RDS épingle les connexions. Ce comportement s'applique que vous utilisiez une SET instruction ou une SET TRANSACTION instruction pour configurer ces valeurs.

Minimiser l'épinglage

Le réglage des performances RDS Proxy 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.

  • Découvrez la fréquence de l'épinglage en surveillant la CloudWatch métrique DatabaseConnectionsCurrentlySessionPinned Amazon. Pour en savoir plus sur ce sujet et sur d'autres métriques CloudWatch, consultez la section Surveillance 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 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. RDS Proxy 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, 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 qui entraînent l'épinglage pour RDS for Microsoft SQL Server

Pour RDS for SQL Server, les interactions suivantes entraînent également l'épinglage :

  • Utilisation de plusieurs ensembles de résultats actifs (MARS). Pour plus d'informations sur MARS, consultez la documentation Microsoft SQL Server.

  • Utilisation de la communication DTC (Distributed Transaction Coordinator).

  • Création de tables temporaires, de transactions, de curseurs ou d'instructions préparées.

  • À l'aide des instructions SET suivantes :

    • SET ANSI_DEFAULTS

    • SET ANSI_NULL_DFLT

    • SET ARITHIGNORE

    • SET DEADLOCK_PRIORITY

    • SET FIPS_FLAGGER

    • SET FMTONLY

    • SET FORCEPLAN

    • SET IDENTITY_INSERT

    • SET NOCOUNT

    • SET NOEXEC

    • SET OFFSETS

    • SET PARSEONLY

    • SET QUERY_GOVERNOR_COST_LIMIT

    • SET REMOTE_PROC_TRANSACTIONS

    • SET ROWCOUNT

    • SET SHOWPLAN_ALL, SHOWPLAN_TEXT et SHOWPLAN_XML

    • SET STATISTICS

    • SET XACT_ABORT

Conditions qui entraînent l'épinglage pour RDS for MariaDB et RDS for MySQL

Pour MariaDB et 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.

  • La définition d'une variable utilisateur ou système (à quelques exceptions près) associe la session au proxy. Si cela limite considérablement la réutilisation des connexions, vous pouvez configurer les SET opérations 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 RDS ( 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 FOUND_ROWS fonctions ROW_COUNT et entraîne parfois un épinglage.

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

  • RDS Proxy 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. RDS 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, le proxy RDS 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 qui entraînent l'épinglage pour RDS for PostgreSQL

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

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

    RDS Proxy n'attache pas aux verrous consultatifs au niveau des transactions, en particulier pg_advisory_xact_lockpg_advisory_xact_lock_shared,pg_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. RDS 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, le proxy RDS n'est actuellement pas compatible avec une procédure stockée qui crée une table temporaire qui persiste dans toutes les transactions.

  • Suppression de l'état de la session. Si vous utilisez des bibliothèques de regroupement de connexions avec une DISCARD ALL requête 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 DISCARD ALL commande peut interférer avec la gestion de l'état de session.