Administración de un RDS Proxy - Amazon Aurora

Administración de un RDS Proxy

En esta sección, se proporciona información sobre cómo administrar el funcionamiento y la configuración de RDS Proxy. Estos procedimientos ayudan a su aplicación a hacer más eficiente el uso de las conexiones de base de datos y a lograr la máxima reutilización de la conexión. Cuanto más pueda aprovechar la reutilización de la conexión, más sobrecarga de la CPU y la memoria podrá evitar. Esto, a su vez, reduce la latencia de la aplicación y permite que la base de datos dedique más recursos al procesamiento de solicitudes de la aplicación.

Modificación de un RDS Proxy

Puede cambiar determinadas configuraciones asociadas a un proxy después de crearlos. Para ello, modifique el propio proxy, su grupo de destino asociado o ambos. Cada proxy tiene un grupo de destino asociado.

importante

Los valores de los campos Client authentication type (Tipo de autenticación de cliente) y IAM authentication (Autenticación de IAM) se aplican a todos los secretos de Secrets Manager asociados a este proxy. Para especificar valores diferentes para cada secreto, modifique su proxy mediante la AWS CLI o la API.

Para modificar la configuración de un proxy
  1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

  2. En el panel de navegación, seleccione Proxies.

  3. En la lista de proxies, elija el proxy cuya configuración desea modificar o vaya a su página de detalles.

  4. Para Actions (Acciones), elija Modify (Modificar).

  5. Introduzca o elija las propiedades que desea modificar. Puede modificar lo siguiente:

    • Proxy identifier (Identificador de proxy: escriba un nuevo identificador para cambiar el nombre del proxy.

    • Idle client connection timeout (Tiempo de espera de inactividad de conexión de cliente): especifique un período de tiempo de espera de conexión de cliente inactiva.

    • IAM role (Rol de IAM): cambie el rol de IAM utilizado para recuperar los secretos de Secrets Manager.

    • Secrets Manager secrets (Secretos de Secrets Manager): agregue o elimine secretos de Secrets Manager. Estos secretos corresponden a nombres de usuario y contraseñas de la base de datos.

    • Client authentication type (Tipo de autenticación de cliente): (solo PostgreSQL) cambie el tipo de autenticación de las conexiones del cliente al proxy.

    • IAM Authentication (Autenticación de IAM): requiera o no permita la autenticación de IAM para las conexiones al proxy.

    • Require Transport Layer Security (Requerir Transport Layer Security): active o desactive el requisito de Transport Layer Security (TLS).

    • VPC security group (Grupo de seguridad de VPC): agregue o quite grupos de seguridad de VPC para que los utilice el proxy.

    • Enable enhanced logging (Habilitar el registro optimizado): habilite o deshabilite el registro mejorado.

  6. Elija Modify.

Si no ha encontrado la configuración mostrada que desea cambiar, utilice el procedimiento siguiente para actualizar el grupo de destino del proxy. El grupo de destino asociado con un proxy controla la configuración relacionada con las conexiones de base de datos físicas. Cada proxy tiene un grupo de destino asociado llamado default, que se crea automáticamente junto con el proxy.

Solo puede modificar el grupo de destino desde la página de detalles del proxy, no desde la lista de la página Proxies.

Para modificar la configuración de un grupo de destino de proxy
  1. En la página Proxies, vaya a la página de detalles de un proxy.

  2. En Target groups (Grupos de destino), elija el enlace default. Actualmente, todos los proxies tienen un único grupo de destino denominado default.

  3. En la página de detalles del grupo de destino default (predeterminado) elija Modify (Modificar).

  4. Elija nuevas configuraciones para las propiedades que puede modificar:

    • Base de datos: elija un clúster de Aurora diferente.

    • Connection pool maximum connections (Conexiones máximas de grupo de conexión): ajuste el porcentaje de conexiones disponibles máximas que puede utilizar el proxy.

    • Session pinning filters (Filtros de fijación de sesión): (opcional) elija un filtro de fijación de sesión. De este modo se eluden las medidas de seguridad predeterminadas para multiplexar las conexiones de bases de datos en las conexiones del cliente. Actualmente, la configuración no es compatible con PostgreSQL. La única opción es EXCLUDE_VARIABLE_SETS.

      Si se habilita esta configuración, es posible que las variables de sesión de una conexión afecten a otras conexiones. Esto puede provocar errores o problemas de corrección si las consultas dependen de valores de variables de sesión establecidos fuera de la transacción actual. Considere la posibilidad de utilizar esta opción después de comprobar que sea seguro que sus aplicaciones compartan conexiones de bases de datos en las conexiones del cliente.

      Los siguientes patrones pueden considerarse seguros:

      • Instrucciones SET en las que no hay ningún cambio en el valor de la variable de sesión efectiva, es decir, no hay ningún cambio en la variable de sesión.

      • Cambia el valor de la variable de sesión y ejecuta una instrucción en la misma transacción.

      Para obtener más información, consulte Evitar la fijación.

    • Connection borrow timeout (Tiempo de espera de préstamo de conexión): ajuste el intervalo de tiempo de espera de préstamo de la conexión. Esta configuración se aplica cuando el número máximo de conexiones ya se está utilizando para el proxy. La configuración determina cuánto tiempo espera el proxy a que una conexión esté disponible antes de devolver un error de tiempo de espera.

    • Initialization query (Consulta de inicialización): (opcional) agregue una consulta de inicialización o modifique la actual. Puede especificar una o más instrucciones de SQL para que el proxy se ejecute al abrir cada nueva conexión de base de datos. Normalmente, el ajuste se utiliza con instrucciones SET para asegurarse de que cada conexión tiene una configuración idéntica, como zona horaria y conjunto de caracteres. Para varias instrucciones, utilice punto y coma como separador. Puede incluir también varias variables en una sola instrucción SET, como SET x=1, y=2.

    No puede cambiar ciertas propiedades, como el identificador del grupo de destino y el motor de base de datos.

  5. Elija Modify target group (Modificar grupo de destino).

Para modificar un proxy mediante la AWS CLI, utilice los comandos modify-db-proxy, modify-db-proxy-target-group, deregister-db-proxy-targets y register-db-proxy-targets.

Con el comando modify-db-proxy, puede cambiar propiedades como las siguientes:

  • El conjunto de secretos de Secrets Manager utilizados por el proxy.

  • Si se requiere TLS.

  • El tiempo de espera del cliente inactivo.

  • Si se debe registrar información adicional de instrucciones de SQL para la depuración.

  • El rol de IAM utilizado para recuperar secretos de Secrets Manager.

  • Los grupos de seguridad utilizados por el proxy.

En el ejemplo siguiente se muestra cómo cambiar el nombre de un proxy existente.

aws rds modify-db-proxy --db-proxy-name the-proxy --new-db-proxy-name the_new_name

Para modificar la configuración relacionada con la conexión o cambiar el nombre del grupo de destino, utilice el comando modify-db-proxy-target-group. Actualmente, todos los proxies tienen un único grupo de destino denominado default. Cuando se trabaja con este grupo de destino, se especifica el nombre del proxy y default para el nombre del grupo de destino.

En el ejemplo siguiente se muestra cómo comprobar primero la configuración de MaxIdleConnectionsPercent de un proxy y, a continuación, cambiarla mediante el grupo de destino.

aws rds describe-db-proxy-target-groups --db-proxy-name the-proxy { "TargetGroups": [ { "Status": "available", "UpdatedDate": "2019-11-30T16:49:30.342Z", "ConnectionPoolConfig": { "MaxIdleConnectionsPercent": 50, "ConnectionBorrowTimeout": 120, "MaxConnectionsPercent": 100, "SessionPinningFilters": [] }, "TargetGroupName": "default", "CreatedDate": "2019-11-30T16:49:27.940Z", "DBProxyName": "the-proxy", "IsDefault": true } ] } aws rds modify-db-proxy-target-group --db-proxy-name the-proxy --target-group-name default --connection-pool-config ' { "MaxIdleConnectionsPercent": 75 }' { "DBProxyTargetGroup": { "Status": "available", "UpdatedDate": "2019-12-02T04:09:50.420Z", "ConnectionPoolConfig": { "MaxIdleConnectionsPercent": 75, "ConnectionBorrowTimeout": 120, "MaxConnectionsPercent": 100, "SessionPinningFilters": [] }, "TargetGroupName": "default", "CreatedDate": "2019-11-30T16:49:27.940Z", "DBProxyName": "the-proxy", "IsDefault": true } }

Con los comandos deregister-db-proxy-targets y register-db-proxy-targets, puede cambiar a qué clústeres de bases de datos de Aurora está asociado el proxy a través de su grupo de destino. Actualmente, cada proxy puede conectarse a un clúster de base de datos de Aurora. El grupo de destino realiza un seguimiento de los detalles de conexión de todas las instancias de base de datos en un clúster de Aurora.

El ejemplo siguiente comienza con un proxy asociado a un clúster de Aurora MySQL denominado cluster-56-2020-02-25-1399. El ejemplo muestra cómo cambiar el proxy para que pueda conectarse a un clúster diferente denominado provisioned-cluster.

Cuando se trabaja con un clúster de bases de datos de Aurora, se especifica la opción --db-cluster-identifier.

El siguiente ejemplo modifica un proxy Aurora MySQL. Un proxy Aurora PostgreSQL tiene el puerto 5432.

aws rds describe-db-proxy-targets --db-proxy-name the-proxy { "Targets": [ { "Endpoint": "instance-9814.demo.us-east-1.rds.amazonaws.com", "Type": "RDS_INSTANCE", "Port": 3306, "RdsResourceId": "instance-9814" }, { "Endpoint": "instance-8898.demo.us-east-1.rds.amazonaws.com", "Type": "RDS_INSTANCE", "Port": 3306, "RdsResourceId": "instance-8898" }, { "Endpoint": "instance-1018.demo.us-east-1.rds.amazonaws.com", "Type": "RDS_INSTANCE", "Port": 3306, "RdsResourceId": "instance-1018" }, { "Type": "TRACKED_CLUSTER", "Port": 0, "RdsResourceId": "cluster-56-2020-02-25-1399" }, { "Endpoint": "instance-4330.demo.us-east-1.rds.amazonaws.com", "Type": "RDS_INSTANCE", "Port": 3306, "RdsResourceId": "instance-4330" } ] } aws rds deregister-db-proxy-targets --db-proxy-name the-proxy --db-cluster-identifier cluster-56-2020-02-25-1399 aws rds describe-db-proxy-targets --db-proxy-name the-proxy { "Targets": [] } aws rds register-db-proxy-targets --db-proxy-name the-proxy --db-cluster-identifier provisioned-cluster { "DBProxyTargets": [ { "Type": "TRACKED_CLUSTER", "Port": 0, "RdsResourceId": "provisioned-cluster" }, { "Endpoint": "gkldje.demo.us-east-1.rds.amazonaws.com", "Type": "RDS_INSTANCE", "Port": 3306, "RdsResourceId": "gkldje" }, { "Endpoint": "provisioned-1.demo.us-east-1.rds.amazonaws.com", "Type": "RDS_INSTANCE", "Port": 3306, "RdsResourceId": "provisioned-1" } ] }

Para modificar un proxy mediante la API de RDS, utilice las operaciones ModifyDBProxy, ModifyDBProxyTargetGroup, DeregisterDBProxyTargets y RegisterDBProxyTargets.

Con ModifyDBProxy, puede cambiar propiedades como las siguientes:

  • El conjunto de secretos de Secrets Manager utilizados por el proxy.

  • Si se requiere TLS.

  • El tiempo de espera del cliente inactivo.

  • Si se debe registrar información adicional de instrucciones de SQL para la depuración.

  • El rol de IAM utilizado para recuperar secretos de Secrets Manager.

  • Los grupos de seguridad utilizados por el proxy.

Con ModifyDBProxyTargetGroup, puede modificar la configuración relacionada con la conexión o cambiar el nombre del grupo de destino. Actualmente, todos los proxies tienen un único grupo de destino denominado default. Cuando se trabaja con este grupo de destino, se especifica el nombre del proxy y default para el nombre del grupo de destino.

Con DeregisterDBProxyTargets y RegisterDBProxyTargets, puede cambiar con qué clúster de Aurora está asociado el proxy a través de su grupo de destino. Actualmente, cada proxy puede conectarse a un clúster de bases de datos de Aurora. El grupo de destino hace un seguimiento de los detalles de conexión de las instancias de base de datos en un clúster de Aurora.

Adición de un nuevo usuario de base de datos

En algunos casos, podría agregar un nuevo usuario de base de datos a un clúster de Aurora asociado a un proxy. Si es así, agregue o reutilice un secreto de Secrets Manager para almacenar las credenciales de ese usuario. Para ello, elija una de las siguientes opciones:

  1. Cree un nuevo secreto de Secrets Manager mediante el procedimiento descrito en Configuración de credenciales de base de datos en AWS Secrets Manager.

  2. Actualice el rol de IAM para conceder acceso al RDS Proxy al nuevo secreto de Secrets Manager. Para ello, actualice la sección de recursos de la política del rol de IAM.

  3. Modifique el proxy de RDS para añadir el nuevo secreto de Secrets Manager en Secretos de Secrets Manager.

  4. Si el nuevo usuario toma el lugar de uno existente, actualice las credenciales almacenadas en el secreto de Secrets Manager del proxy para el usuario existente.

Adición de un nuevo usuario de la base de datos de PostgreSQL

Al agregar un nuevo usuario a su base de datos de PostgreSQL, si ha ejecutado el siguiente comando:

REVOKE CONNECT ON DATABASE postgres FROM PUBLIC;

Otorgue al usuario rdsproxyadmin el privilegio CONNECT para que pueda supervisar las conexiones en la base de datos de destino.

GRANT CONNECT ON DATABASE postgres TO rdsproxyadmin;

También puede permitir que otros usuarios de la base de datos de destino realicen comprobaciones de estado cambiando rdsproxyadmin por el usuario de la base de datos del comando anterior.

Cambio de la contraseña de un usuario de base de datos

En algunos casos, puede cambiar la contraseña de un usuario de base de datos en un clúster de Aurora asociado a un proxy. Si es así, actualice el secreto de Secrets Manager correspondiente con la nueva contraseña.

Conexiones de cliente y base de datos

Las conexiones de la aplicación a RDS Proxy se conocen como conexiones de cliente. Las conexiones desde un proxy a la base de datos son conexiones de base de datos. Cuando se utiliza RDS Proxy, las conexiones de cliente terminan en el proxy, mientras que las conexiones de la base de datos se administran en RDS Proxy.

La agrupación de conexiones en la aplicación puede ofrecer la ventaja de reducir el establecimiento de conexiones recurrentes entre la aplicación y RDS Proxy.

Tenga en cuenta los siguientes elementos de configuración antes de implementar un grupo de conexiones en la aplicación:

  • Duración máxima de la conexión del cliente: RDS Proxy impone una vida útil máxima de 24 horas para las conexiones del cliente. Este valor no se puede configurar. Configure su grupo con una vida útil máxima de conexión inferior a 24 horas para evitar caídas inesperadas en la conexión del cliente.

  • Tiempo de espera de inactividad en la conexión de cliente: RDS Proxy impone un tiempo máximo de inactividad para las conexiones del cliente. Configure su grupo con un valor de tiempo de espera de conexión inactiva inferior al tiempo de espera de la conexión de cliente para RDS Proxy, a fin de evitar caídas inesperadas en la conexión.

El número máximo de conexiones del cliente configuradas en el grupo de conexiones de la aplicación no tiene por qué limitarse a la configuración max_connections de RDS Proxy

La agrupación de conexiones de clientes prolonga la vida útil de las conexiones del cliente. Si las conexiones se bloquean, agrupar las conexiones de cliente podría reducir la eficiencia de la multiplexación. Las conexiones del cliente que están bloqueadas pero inactivas en el grupo de conexiones de la aplicación siguen teniendo una conexión de base de datos e impiden que otras conexiones del cliente reutilicen la conexión a la base de datos. Revise los registros de proxy para comprobar si las conexiones se fijan.

nota

RDS Proxy cierra las conexiones de base de datos un poco después de 24 horas, cuando ya no están en uso. El proxy realiza esta acción independientemente del valor de configuración máxima de conexiones inactivas.

Configuración de los valores de conexión

Para ajustar la agrupación de conexiones de RDS Proxy, puede modificar la siguiente configuración:

IdleClientTimeout

Puede especificar cuánto tiempo puede estar inactiva una conexión del cliente antes de que el proxy la cierre. El valor predeterminado es 1800 segundos (30 minutos).

Una conexión de cliente se considera inactiva cuando la aplicación no envía una nueva solicitud dentro del plazo especificado después de completar la solicitud anterior. La conexión de base de datos subyacente permanece abierta y se devuelve al grupo de conexiones. Por lo tanto, está disponible para reutilizarla para nuevas conexiones de cliente. Si quiere que el proxy elimine de forma proactiva las conexiones obsoletas, considere la posibilidad de reducir el tiempo de espera de conexión del cliente inactivo. Si la carga de trabajo establece conexiones frecuentes con el proxy, considere la posibilidad de aumentar el tiempo de espera de la conexión del cliente inactivo para ahorrar el costo del establecimiento de conexiones.

Esta configuración se representa mediante el campo Idle client connection timeout (Tiempo de espera de la conexión de cliente inactivo) en la consola de RDS y la configuración IdleClientTimeout en la AWS CLI y la API. Para obtener información sobre cómo cambiar el valor del campo Idle client connection timeout (Tiempo de espera de la conexión de cliente inactivo) en la consola de RDS, consulte AWS Management Console. Para obtener información sobre cómo cambiar el valor de la configuración IdleClientTimeout, consulte el comando de la CLI modify-db-proxy o la operación de la API ModifyDBProxy.

MaxConnectionsPercent

Puede limitar el número de conexiones que un proxy de RDS puede establecer con la base de datos de destino. Especifique el límite como porcentaje de las conexiones máximas disponibles para la base de datos. Esta configuración se representa mediante el campo Connection pool maximum connections (Conexiones máximas de grupo de conexión) en la consola de RDS y la configuración MaxConnectionsPercent en la AWS CLI y la API.

El valor MaxConnectionsPercent se expresa como un porcentaje de la configuración de max_connections para el clúster de base de datos de Aurora que usa el grupo de destino. El proxy no crea todas estas conexiones por adelantado. Esta configuración permite que el proxy establezca estas conexiones a medida que la carga de trabajo las necesita.

Por ejemplo, en una base de datos registrada donde max_connections está establecido en 1000 y MaxConnectionsPercent está establecido en 95, el proxy de RDS establece 950 conexiones como límite máximo para las conexiones simultáneas a esa base de datos de destino.

Un efecto secundario habitual de que la carga de trabajo alcance el número máximo de conexiones a bases de datos permitidas es el aumento de la latencia general de las consultas, junto con un aumento de la métrica DatabaseConnectionsBorrowLatency. Puede supervisar las conexiones a bases de datos que se utilizan actualmente y el total permitido comparando las métricas DatabaseConnections y MaxDatabaseConnectionsAllowed.

Al configurar este parámetro, tenga en cuenta las siguientes prácticas recomendadas:

  • Deje suficiente margen de conexión para los cambios en el patrón de carga de trabajo. Se recomienda configurar el parámetro al menos un 30 % por encima del uso supervisado máximo reciente. Dado que el proxy de RDS redistribuye las cuotas de conexión a las bases de datos entre varios nodos, los cambios en la capacidad interna pueden requerir al menos un 30 % de margen para conexiones adicionales para evitar un aumento de la latencia de préstamos.

  • El proxy de RDS reserva una cantidad determinada de conexiones para la supervisión activa para facilitar una conmutación por error rápida, el enrutamiento del tráfico y las operaciones internas. La métrica MaxDatabaseConnectionsAllowed no incluye estas conexiones reservadas. Representa el número de conexiones disponibles para atender la carga de trabajo y puede ser inferior al valor derivado de la configuración de MaxConnectionsPercent.

    Los valores MaxConnectionsPercent mínimos recomendados son los siguientes:

    • db.t3.small: 100

    • db.t3.medium: 55

    • db.t3.large: 35

    • db.r3.large o superior: 20

    Si hay varias instancias de destino registradas en el proxy de RDS, como un clúster de Aurora con nodos lectores, defina el valor mínimo en función de la instancia registrada más pequeña.

Para obtener información sobre cómo cambiar el valor del campo Connection pool maximum connections (Conexiones máximas de grupo de conexión) en la consola de RDS, consulte AWS Management Console. Para obtener información sobre cómo cambiar el valor de la configuración de MaxConnectionsPercent, consulte el comando de la CLI modify-db-proxy-target-group o la operación de la API ModifyDBProxyTargetGroup.

importante

Si el clúster de base de datos forma parte de una base de datos global con el reenvío de escritura activado, reduzca el valor MaxConnectionsPercent del proxy según la cuota asignada para el reenvío de escritura. La cuota de reenvío de escritura se establece en el parámetro del clúster de base de datos aurora_fwd_writer_max_connections_pct. Para obtener información sobre el reenvío de escritura, consulte Uso del reenvío de escritura en una base de datos Amazon Aurora global.

Para obtener información sobre los límites de conexión de base de datos, consulte Número máximo de conexiones a una instancia de base de datos Aurora MySQL y Número máximo de conexiones a una instancia de base de datos de Aurora PostgreSQL.

MaxIdleConnectionsPercent

Puede controlar el número de conexiones de base de datos inactivas que RDS Proxy puede mantener en el grupo de conexiones. De forma predeterminada, RDS Proxy considera que una conexión de base de datos en su grupo está inactiva cuando no ha habido actividad en la conexión durante cinco minutos.

El valor MaxIdleConnectionsPercent se expresa como un porcentaje de la configuración de max_connections para el grupo de destino de la instancia de base de datos de RDS. El valor predeterminado es del 50 por ciento de MaxConnectionsPercent y el límite superior es el valor de MaxConnectionsPercent. Por ejemplo, si MaxConnectionsPercent es 80, el valor predeterminado de MaxIdleConnectionsPercent es 40.

Con un valor alto, el proxy deja un alto porcentaje de conexiones de base de datos inactivas abiertas. Con un valor bajo, el proxy cierra un alto porcentaje de conexiones de base de datos inactivas. Si sus cargas de trabajo son impredecibles, considere establecer un valor alto para MaxIdleConnectionsPercent. De este modo, RDS Proxy puede adaptarse a los aumentos de actividad sin abrir muchas conexiones de base de datos nuevas.

Esta configuración se representa mediante la configuración MaxIdleConnectionsPercent de DBProxyTargetGroup en la AWS CLI y la API. Para obtener información sobre cómo cambiar el valor de la configuración de MaxIdleConnectionsPercent, consulte el comando de la CLI modify-db-proxy-target-group o la operación de la API ModifyDBProxyTargetGroup.

Para obtener información sobre los límites de conexión de base de datos, consulte Número máximo de conexiones a una instancia de base de datos Aurora MySQL y Número máximo de conexiones a una instancia de base de datos de Aurora PostgreSQL.

ConnectionBorrowTimeout

Puede elegir cuánto tiempo espera RDS Proxy a que una conexión a la base de datos del grupo de conexiones esté disponible para su uso antes de devolver un error de tiempo de espera. El valor predeterminado es de 120 segundos. Esta configuración se aplica cuando el número de conexiones está al máximo, por lo que no hay conexiones disponibles en el grupo de conexiones. Esto también se aplica si no hay ninguna instancia de base de datos adecuada disponible para gestionar la solicitud, como cuando se esté realizando una operación de conmutación por error. Con esta configuración, puede establecer el mejor periodo de espera para la aplicación sin cambiar el tiempo de espera de la consulta en el código de la aplicación.

Esta configuración se representa mediante el campo Connection borrow timeout (Tiempo de espera de préstamo de conexión) en la consola de RDS o en la configuración de ConnectionBorrowTimeout de DBProxyTargetGroup de la AWS CLI o de la API. Para obtener información sobre cómo cambiar el valor del campo Connection borrow timeout (Tiempo de espera de préstamo de conexión) en la consola de RDS, consulte AWS Management Console. Para obtener información sobre cómo cambiar el valor de la configuración de ConnectionBorrowTimeout, consulte el comando de la CLI modify-db-proxy-target-group o la operación de la API ModifyDBProxyTargetGroup.

Evitar la fijación

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

Eliminación de un RDS Proxy

Puede eliminar un proxy cuando ya no lo necesite. O podría eliminar un proxy si pone la instancia de base de datos o el clúster asociado con él fuera de servicio.

Para eliminar un proxy
  1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

  2. En el panel de navegación, seleccione Proxies.

  3. Elija el proxy que desea eliminar de la lista.

  4. Elija Delete Proxy (Eliminar proxy).

Para eliminar un proxy de base de datos, utilice el comando de la AWS CLI delete-db-proxy. Para quitar asociaciones relacionadas, utilice también el comando deregister-db-proxy-targets.

aws rds delete-db-proxy --name proxy_name
aws rds deregister-db-proxy-targets --db-proxy-name proxy_name [--target-group-name target_group_name] [--target-ids comma_separated_list] # or [--db-instance-identifiers instance_id] # or [--db-cluster-identifiers cluster_id]

Para eliminar un proxy de base de datos, llame a la función de la API de Amazon RDS DeleteDBProxy. Para eliminar elementos relacionados y asociaciones, llame también a las funciones DeleteDBProxyTargetGroup y DeregisterDBProxyTargets.