Cómo evitar la fijación de RDS Proxy - Amazon Aurora
Qué seguimiento hace RDS Proxy para bases de datos de Aurora MySQLMinimizar la fijaciónCondiciones que provocan la fijación de todas las familias de motoresCondiciones que provocan la fijación para Aurora MySQLCondiciones que provocan la fijación para Aurora PostgreSQL

Cómo evitar la fijación de RDS Proxy

La multiplexación es más eficiente cuando las solicitudes de base de datos no dependen de la información de estado de solicitudes anteriores. En ese caso, RDS Proxy puede reutilizar una conexión en la conclusión de cada transacción. Algunos ejemplos de dicha información de estado incluyen la mayoría de las variables y parámetros de configuración que puede cambiar a través de instrucciones SET o SELECT. Las transacciones SQL en una conexión de cliente pueden multiplexar entre conexiones de base de datos subyacentes de forma predeterminada.

Las conexiones al proxy pueden entrar en un estado conocido como fijación. Cuando se fija una conexión, cada transacción posterior utiliza la misma conexión de base de datos subyacente hasta que finaliza la sesión. Otras conexiones de cliente tampoco pueden reutilizar esa conexión de base de datos hasta que finaliza la sesión. La sesión finaliza cuando se interrumpe la conexión del cliente.

RDS Proxy fija automáticamente una conexión de cliente a una conexión de base de datos específica cuando detecta un cambio de estado de sesión que no es apropiado para otras sesiones. La fijación reduce la eficacia de la reutilización de la conexión. Si todas o casi todas las conexiones experimentan asignación, plantéese modificar el código de la aplicación o la carga de trabajo para reducir las condiciones que provocan la fijación.

Por ejemplo, su aplicación cambia una variable de sesión o un parámetro de configuración. En este caso, las instrucciones posteriores pueden depender de que la nueva variable o parámetro esté en vigor. Por lo tanto, cuando RDS Proxy procesa solicitudes para cambiar las variables de sesión o los parámetros de configuración, fija esa sesión a la conexión de base de datos. De esta forma, el estado de la sesión permanece en vigor para todas las transacciones posteriores en la misma sesión.

Para algunos motores de base de datos, esta regla no se aplica a todos los parámetros que se pueden establecer. RDS Proxy realiza un seguimiento de ciertas sentencias y variables. Por lo tanto, RDS Proxy no fija la sesión cuando las modifica. En ese caso, RDS Proxy solo reutiliza la conexión para otras sesiones que tengan los mismos valores para esa configuración. Para obtener las listas de instrucciones y variables rastreadas para Aurora MySQL, consulte Qué seguimiento hace RDS Proxy para bases de datos de Aurora MySQL.

Qué seguimiento hace RDS Proxy para bases de datos de Aurora MySQL

A continuación se presentan las instrucciones MySQL de las que RDS Proxy realiza un seguimiento:

  • DROP DATABASE

  • DROP SCHEMA

  • USE

A continuación se presentan las variables MySQL de las que RDS Proxy realiza un seguimiento:

  • 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

Minimizar la fijación

El ajuste del rendimiento para RDS Proxy implica intentar maximizar la reutilización de la conexión en el nivel de transacción (multiplexación) minimizando la fijación.

Puede minimizar la fijación, puede realizar lo siguiente:

  • Evite las solicitudes de base de datos innecesarias que puedan provocar la fijación.

  • Establezca variables y parámetros de configuración de forma coherente en todas las conexiones. De esta forma, es más probable que las sesiones posteriores reutilicen conexiones que tengan esa configuración particular.

    Sin embargo, en el caso de PostgreSQL, el establecimiento de una variable conduce a la fijación de sesión.

  • Para una base de datos de familia de motores MySQL, aplique un filtro de sesión de fijación al proxy. Puede eximir a ciertos tipos de operaciones de asignar la sesión si sabe que hacerlo no afecta al correcto funcionamiento de la fijación.

  • Consulte la frecuencia con la que se produce la fijación mediante la supervisión de la métrica de Amazon CloudWatch DatabaseConnectionsCurrentlySessionPinned. Para obtener información sobre esta y otras métricas de CloudWatch, consulte Supervisión de las métricas de RDS Proxy con Amazon CloudWatch.

  • Si utiliza instrucciones SET para realizar una inicialización idéntica para cada conexión de cliente, puede hacerlo sin dejar de mantener la multiplexación en el nivel de transacción. En este caso, mueva las instrucciones que configuran el estado de la sesión inicial a la consulta de inicialización utilizada por un proxy. Esta propiedad es una cadena que contiene una o varias instrucciones SQL, separadas por punto y coma.

    Por ejemplo, puede definir una consulta de inicialización para un proxy que establezca determinados parámetros de configuración. A continuación, RDS Proxy aplica esa configuración cada vez que configura una nueva conexión para ese proxy. Puede eliminar las instrucciones SET correspondientes de su código de aplicación, para que no interfieran con la multiplexación en el nivel de transacción.

    Para obtener métricas acerca de la frecuencia con la que se produce la fijación de un proxy, consulte Supervisión de las métricas de RDS Proxy con Amazon CloudWatch.

Condiciones que provocan la fijación de todas las familias de motores

El proxy fija la sesión a la conexión actual en las siguientes situaciones en las que la multiplexación podría provocar un comportamiento inesperado:

  • Cualquier instrucción con un tamaño de texto superior a 16 KB hace que el proxy fije la sesión.

Condiciones que provocan la fijación para Aurora MySQL

Para PostgreSQL, las siguientes interacciones también producen fijación:

  • Las instrucciones de bloqueo de tabla explícitas LOCK TABLE, LOCK TABLES o FLUSH TABLES WITH READ LOCK hacen que el proxy fije la sesión.

  • Creación de bloqueos con nombre medianteGET_LOCKprovoca que el proxy instale la sesión.

  • El establecimiento de una variable de usuario o una variable de sistema (con algunas excepciones) hace que el proxy fije la sesión. Si esta situación reduce demasiado la reutilización de la conexión, puede elegir que las operaciones SET no provoquen la fijación. Para obtener información acerca de cómo hacerlo estableciendo la propiedad de los filtros de fijación de sesión, consulte Creación de un RDS Proxy y Modificación de RDS Proxy.

  • La creación de una tabla temporal hace que el proxy fije la sesión. De esta forma, el contenido de la tabla temporal se conserva a lo largo de la sesión con independencia de los límites de la transacción.

  • La llamada a las funciones ROW_COUNT, FOUND_ROWS y LAST_INSERT_ID a veces provoca fijación.

    Es posible que las circunstancias exactas en las que estas funciones provocan fijación difieran entre versiones de Aurora MySQL que son compatibles con MySQL 5.7.

  • Las instrucciones preparadas hacen que el proxy fije la sesión. Esta regla se aplica si la instrucción preparada utiliza texto SQL o el protocolo binario.

  • El proxy de RDS no fija las conexiones cuando se utiliza SET LOCAL.

  • La llamada a procedimientos almacenados y funciones almacenadas no causa fijación. El proxy de RDS no detecta ningún cambio de estado de sesión resultante de dichas llamadas. Asegúrese de que su aplicación no cambie el estado de la sesión dentro de las rutinas almacenadas si confía en que ese estado de sesión vaya a persistir en las transacciones. Por ejemplo, RDS Proxy no es compatible actualmente con un procedimiento almacenado que crea una tabla temporal que persiste a través de todas las transacciones.

Si tiene conocimientos especializados sobre el comportamiento de la aplicación, puede omitir el comportamiento de fijación de determinadas instrucciones de aplicación. Para ello, elija la opción Session pinning filters (Filtro de fijación de sesión) al crear el proxy. Actualmente, puede desactivar la fijación de sesión para establecer variables de sesión y valores de configuración.

Condiciones que provocan la fijación para Aurora PostgreSQL

Para PostgreSQL, las siguientes interacciones también producen fijación:

  • Uso de comandos SET.

  • Uso de los comandos PREPARE, DISCARD, DEALLOCATE o EXECUTE para gestionar las instrucciones preparadas.

  • Creación de secuencias, tablas o vistas temporales.

  • Declaración de cursores.

  • Descartar el estado de la sesión.

  • Escucha en un canal de notificación.

  • Carga de un módulo de biblioteca como auto_explain.

  • Manipulación de secuencias mediante el uso de funciones como nextval y setval.

  • Interacción con bloqueos mediante el uso de funciones como pg_advisory_lock y pg_try_advisory_lock.

    nota

    RDS Proxy no fija los bloqueos consultivos en la transacción, específicamente pg_advisory_xact_lock, pg_advisory_xact_lock_shared, pg_try_advisory_xact_lock y pg_try_advisory_xact_lock_shared.

  • Cómo configurar un parámetro o restablecerlo a su valor predeterminado. En concreto, el uso de comandos SET y set_config para asignar valores predeterminados a las variables de sesión.

  • La llamada a procedimientos almacenados y funciones almacenadas no causa fijación. El proxy de RDS no detecta ningún cambio de estado de sesión resultante de dichas llamadas. Asegúrese de que su aplicación no cambie el estado de la sesión dentro de las rutinas almacenadas si confía en que ese estado de sesión vaya a persistir en las transacciones. Por ejemplo, RDS Proxy no es compatible actualmente con un procedimiento almacenado que crea una tabla temporal que persiste a través de todas las transacciones.