# Directrices de configuración
En esta sección se describen las opciones de configuración disponibles en RDS Proxy y se proporcionan las prácticas recomendadas para alinear la configuración en toda la pila de aplicaciones. Estas son directrices combinadas para usar RDS Proxy con Amazon RDS y Amazon Aurora. Las notas específicas de RDS y de Aurora se mencionan cuando corresponde.
A menos que se indique lo contrario, los términos “base de datos” o “destino” hacen referencia a un clúster de Aurora, un clúster de la base de datos de Amazon RDS Multi-AZ o una instancia de Amazon RDS.
**Topics**
+ [Configuración de RDS Proxy](#rds-proxy-best-practices.configuration-settings)
+ [Alineación de la configuración de la aplicación, el proxy y la base de datos](#rds-proxy-best-practices.configuration.alignment)
+ [Configuración de las bases de datos](#rds-proxy-best-practices.configuration.alignment.database)
+ [Configuración de aplicaciones](#rds-proxy-best-practices.configuration.alignment.application)
## Configuración de RDS Proxy
### MaxConnectionsPercent
| Valor mínimo | Valor máximo | Predeterminado |
| --- | --- | --- |
| menor de (1, MaxIdleConnectionsPercent) | 100 | 100 |
Para obtener más información, consulte [MaxConnectionsPercent](rds-proxy-connections.md#rds-proxy-connection-pooling-tuning.maxconnectionspercent).
Este ajuste limita el número de conexiones que RDS Proxy puede establecer con la base de datos de destino, como porcentaje del número máximo de conexiones permitidas por la base de datos. El proxy abre las conexiones backend según sea necesario, por lo que el número real de conexiones en un momento determinado puede ser inferior al máximo configurado.
Dado que el ajuste `MaxConnectionsPercent` es un porcentaje del límite de conexiones de la base de datos, el tamaño del grupo de conexiones del proxy se ajusta automáticamente a la configuración de la base de datos. Esto significa que no es necesario volver a configurar los proxies cada vez que se cambie el tamaño de las instancias de la base de datos o se realicen cambios en la configuración. También significa que debe conocer las situaciones en las que la configuración de la base de datos podría cambiar, ya sea de forma implícita o explícita:
+ Si no ha establecido de forma explícita el límite de conexión (como, por ejemplo, el parámetro `max_connections`) en el grupo de parámetros de la base de datos, Amazon RDS y Aurora lo calcularán automáticamente en función de la clase de instancia de la base de datos. Como resultado, el límite de conexiones implícito puede cambiar al escalar las instancias de la base de datos, lo que influye en el tamaño máximo del grupo en el proxy. Para obtener más información, consulte [Número máximo de conexiones de base de datos](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html#RDS_Limits.MaxConnections) en la *Guía del usuario de Amazon RDS*, [Número máximo de conexiones a una instancia de base de datos Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Performance.html#AuroraMySQL.Managing.MaxConnections) y [Número máximo de conexiones a una instancia de base de datos Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Managing.html#AuroraPostgreSQL.Managing.MaxConnections) en la *Guía del usuario de Amazon Aurora*.
+ Las instancias de base de datos de Aurora Serverless v2 determinan su límite de conexión en función de la configuración de ACU máxima de la base de datos. Para obtener más información, consulte [Número máximo de conexiones para Aurora Serverless v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.max-connections) en la *Guía del usuario de Amazon Aurora*.
Prácticas recomendadas:
+ La configuración predeterminada del 100 % es adecuada para las bases de datos que reciben todo su tráfico a través del proxy y no necesitan ningún margen de maniobra para el acceso administrativo o para otros clientes.
+ Reduzca este ajuste cuando la base de datos también reciba tráfico directamente de las aplicaciones (sin pasar por el proxy) y no desee que el proxy consuma todas las conexiones, o cuando desee reservar un número determinado de conexiones para otros fines, como, por ejemplo, el acceso directo de los administradores de bases de datos.
+ Al utilizar RDS Proxy con los clústeres de bases de datos globales de Aurora, y si la opción de reenvío de escritura está habilitada, reduzca el valor `MaxConnectionsPercent` del proxy según la cuota asignada para el reenvío de escritura. Para obtener más información, consulte los parámetros de configuración del reenvío de escritura en [Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-write-forwarding-ams.html#aurora-global-database-write-forwarding-params-ams) y [Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-write-forwarding-apg.html#aurora-global-database-write-forwarding-params-apg) en la *Guía del usuario de Amazon Aurora*. Esta recomendación se aplica tanto si el proxy presta servicio a un clúster tanto en la región principal como en la secundaria de la base de datos global. Los clústeres secundarios pueden ascender al rol principal, por lo que es una práctica recomendada mantener la coherencia de la configuración del proxy en toda la topología global. *Puede* utilizar una configuración asimétrica para los proxies que presten servicio a regiones principales frente a regiones secundarias, pero tendrá que ajustarla después de cada conmutación por error o transición global.
+ Si el destino presta servicio a varios proxies, el valor combinado de `MaxConnectionsPercent` en todos esos proxies no debe superar los 100 para evitar que la base de datos tenga un exceso de suscripciones. Recomendamos usar un único proxy por destino para simplificar la configuración y la administración. En concreto, no necesita utilizar varios proxies por base de datos para obtener redundancia. Para obtener más información, consulte [Uso de varios proxies con un objetivo](rds-proxy-best-practices.usage-scenarios.md#rds-proxy-best-practices.multiple-proxies).
Ya sea que utilice el ajuste predeterminado `MaxConnectionsPercent` o un valor personalizado, mantenga al menos un 30 % de margen de maniobra entre el número de conexiones permitidas y el número máximo de conexiones de clientes previstas durante los periodos de mayor actividad. Por ejemplo:
+ Si cree que el proxy necesitará hasta el 50 % del límite de conexiones configurado para la base de datos, establezca el ajuste `MaxConnectionsPercent` en al menos `1.3 * 50% = 65%`.
+ Al utilizar el ajuste predeterminado `MaxConnectionsPercent` de 100, asegúrese de que el propio límite de la base de datos ofrezca suficiente margen de maniobra.
Este margen de maniobra adicional mejora la experiencia del cliente durante los picos inesperados de carga de trabajo y ayuda a RDS Proxy a redistribuir las conexiones en su infraestructura interna para la administración de las actividades y otros fines.
Aunque puede establecer `MaxConnectionsPercent` en un valor tan bajo como 1, le recomendamos los siguientes valores mínimos en función del tipo de instancia:
+ db.t3.small: 100
+ db.t3.medium: 55
+ db.t3.large: 35
+ db.r3.large o superior: 20
### MaxIdleConnectionsPercent
| Valor mínimo | Valor máximo | Valor predeterminado (SQL Server) | Valor predeterminado (otros motores) |
| --- | --- | --- | --- |
| (cero) | MaxConnectionsPercent | 5 % de MaxConnectionsPercent | 50 % de MaxConnectionsPercent |
Para obtener más información, consulte [MaxIdleConnectionsPercent](rds-proxy-connections.md#rds-proxy-connection-pooling-tuning.maxidleconnectionspercent).
Este ajuste limita el número de conexiones de base de datos inactivas que RDS Proxy mantiene en el grupo de conexiones, como porcentaje del número máximo de conexiones permitidas por la base de datos. Una conexión (backend) de base de datos se considera inactiva cuando no ha habido actividad en la conexión durante cinco minutos. Este ajuste se aplica a las conexiones entre el proxy y la base de datos backend.
Tenga en cuenta lo siguiente:
+ Este ajuste limita el número de conexiones inactivas del grupo, pero no obliga al proxy a conservar un número determinado de conexiones inactivas. Si la actividad del cliente es muy baja, el número real de conexiones a la base de datos backend puede ser inferior a `MaxIdleConnectionsPercent`.
+ Las conexiones se consideran inactivas cuando están disponibles para reutilizarlas en el grupo de conexiones del proxy. Las conexiones fijadas no están disponibles para que otros clientes las reutilicen y, por lo tanto, no se consideran inactivas a efectos de aplicar `MaxIdleConnectionsPercent`. Para obtener más información sobre la fijación, consulte [Cómo evitar la fijación de RDS Proxy](rds-proxy-pinning.md).
+ El número de conexiones inactivas que indican los metadatos de la base de datos suele ser superior al número de conexiones inactivas registradas por las métricas de RDS Proxy. Esto puede deberse a que las conexiones directas de los clientes pasan por alto el proxy, así como a las conexiones internas utilizadas por la automatización de Aurora y Amazon RDS.
**nota**
El tiempo de inactividad de la conexión observado y aplicado en la capa de proxy puede ser diferente del tiempo de inactividad registrado por las herramientas de bases de datos, como, por ejemplo, la lista de procesos de MySQL o las tablas de estadísticas de actividad de PostgreSQL. RDS Proxy hace ping a las conexiones backend de vez en cuando, lo que restablece los temporizadores de inactividad de la base de datos, aunque la conexión permanezca inactiva debido a la actividad del cliente.
Prácticas recomendadas:
El ajuste predeterminado de 50 es adecuado y también es el recomendado para la mayoría de las cargas de trabajo. Cambiar el ajuste tiene el siguiente efecto:
+ Cuando se aumente el valor de `MaxIdleConnectionsPercent`, la base de datos observará un mayor número de conexiones inactivas, lo que puede aumentar el consumo de recursos de la base de datos fuera de las horas de mayor actividad. Por otro lado, los picos de conexión administrados a través del proxy tienen una latencia de préstamo inferior, ya que hay más conexiones disponibles en el grupo.
+ Cuando se disminuya el valor de `MaxIdleConnectionsPercent`, el proxy cerrará las conexiones inactivas de forma más agresiva, lo que podría reducir la contención y el consumo de recursos que provocan esas conexiones. Sin embargo, los picos de conexión que pasan por el proxy pueden experimentar tiempos de préstamo más prolongados. Dado que hay menos conexiones disponibles en el grupo, el proxy debe dedicar más tiempo a abrir nuevas conexiones backend en caso de picos de actividad.
Es posible que el consumo de recursos de las conexiones inactivas no sea un problema importante en las bases de datos que utilizan tipos de instancias aprovisionadas, pero las bases de datos de Aurora que utilizan el tipo de instancia de Serverless v2 pueden preferir la optimización del consumo de recursos inactivos para reducir los costos.
### IdleClientTimeout
| Valor mínimo | Valor máximo | Predeterminado |
| --- | --- | --- |
| 1 minuto | 8 horas | 30 minutos |
Para obtener más información, consulte [IdleClientTimeout](rds-proxy-connections.md#rds-proxy-connection-pooling-tuning.idleclienttimeout).
Este ajuste determina cuánto tiempo puede estar inactiva una conexión del cliente antes de que el proxy la cierre. Tenga en cuenta que RDS Proxy exige una vida útil máxima de la conexión de 24 horas, independientemente de si la conexión está inactiva. Por ejemplo, si establece `IdleClientTimeout` en 30 minutos (valor predeterminado) y hace ping a la base de datos cada minuto, la conexión nunca superará el tiempo de espera por inactividad, pero no permanecerá abierta indefinidamente. RDS Proxy cierra la conexión una vez transcurridas 24 horas, incluso si no se considera inactiva.
El ajuste `IdleClientTimeout` se aplica a la conexión entre un cliente (aplicaciones o usuarios interactivos) y RDS Proxy. Para entender el comportamiento inactivo de las conexiones backend entre RDS Proxy y la base de datos, consulte [MaxIdleConnectionsPercent](#rds-proxy-best-practices.configuration.maxidleconnectionspercent).
Prácticas recomendadas:
+ El tiempo de espera por inactividad debe ser lo suficientemente prolongado como para dar cabida a las pausas normales de la actividad de SQL dentro de una conexión o transacción de un cliente. No debe ser tan prolongado como para permitir que un cliente conserve recursos que, de forma razonable, ya no necesite, pero que podrían ser necesarios para otros clientes. Esto es especialmente importante si se observa una fijación de la conexión, ya que otros clientes no pueden reutilizar una conexión fijada por un cliente específico.
+ Para que RDS Proxy aplique correctamente el tiempo de espera, la conexión del cliente debe estar realmente inactiva sin enviar consultas (ni siquiera comprobaciones de estado sencillas, como, por ejemplo, `SELECT 1;`) ni pings de protocolo (como, por ejemplo, `COM_PING` en MySQL). Si observa que las conexiones no se cierran a pesar de superar el tiempo de espera, compruebe la lógica de conexión de los controladores de la aplicación. Es especialmente probable que los grupos de conexiones de aplicaciones realicen sus propias comprobaciones de actividad, lo que interfiere con `IdleClientTimeout`.
### ConnectionBorrowTimeout
| Valor mínimo | Valor máximo | Predeterminado |
| --- | --- | --- |
| (cero) | 5 minutos | 2 minutos |
Para obtener más información, consulte [ConnectionBorrowTimeout](rds-proxy-connections.md#rds-proxy-connection-pooling-tuning.connectionborrowtimeout).
Cuando un cliente se conecta a RDS Proxy, el proxy debe tomar prestada una conexión existente disponible del grupo o abrir una nueva conexión de base de datos. Este ajuste define cuánto tiempo espera RDS Proxy a que se tome prestada o se abra una conexión antes de devolver un error.
Tenga en cuenta lo siguiente:
+ Un valor `ConnectionBorrowTimeout` de cero provoca errores de tiempo de espera cuando el grupo de conexiones aún no incluye ninguna conexión disponible. Esto es cierto incluso si el grupo está por debajo de su capacidad máxima y podría abrir una nueva conexión backend.
+ Incluso si el valor `MaxIdleConnectionsPercent` es igual a `MaxConnectionsPercent`, el número real de conexiones del grupo puede ser inferior al máximo configurado. Dicho de otro modo, `MaxIdleConnectionsPercent` limita la cantidad de conexiones inactivas, pero no obliga a las conexiones a permanecer abiertas.
Es normal que un grupo de conexiones funcione por debajo de su capacidad máxima. En esta situación, el uso del valor `ConnectionBorrowTimeout` establecido en cero puede impedir que el grupo aumente, ya que no se le permite esperar a que se abra una nueva conexión. Como resultado, debe utilizar los valores `ConnectionBorrowTimeout` que no sean cero para todas las cargas de trabajo, a menos que se prefiera el comportamiento que se ha descrito anteriormente.
**nota**
Este ajuste también se aplica cuando la base de datos no está preparada para aceptar conexiones, como, por ejemplo, durante las operaciones de mantenimiento sin conexión y las conmutaciones por error. La lógica para aplicar el valor `ConnectionBorrowTimeout` es la misma, independientemente de si la base de datos está activa o inactiva.
### Consultas de inicialización y filtros de fijación
RDS Proxy admite características adicionales que pueden reducir la fijación de conexiones y, en consecuencia, mejorar la eficiencia de la multiplexación.
Una **consulta de inicialización** consiste en ejecutar una o más instrucciones cada vez que el proxy configura una nueva conexión de base de datos backend. Si los clientes utilizan instrucciones idénticas para configurar los parámetros de la sesión, puede trasladarlas a la consulta de inicialización del proxy. Esto ayuda a reducir la probabilidad de fijación y también mejora la eficiencia: una determinada conexión de base de datos backend ejecuta su consulta de inicialización una vez durante la configuración, pero es posible que muchos clientes la reutilicen más adelante. Tenga en cuenta que incluir instrucciones de SQL en la consulta de inicialización no las filtra del tráfico de clientes. Aún necesita eliminar dichas instrucciones del código de la aplicación para que no interfieran con la multiplexación.
Los **filtros de fijación de sesiones** son una propiedad de configuración que impide que el proxy fije determinados estados de la sesión. La única opción de filtro disponible actualmente, `EXCLUDE_VARIABLE_SETS`, indica al proxy que ignore todas las instrucciones de `SET` al determinar si se debe fijar una sesión. Las instrucciones de `SET` se siguen transmitiendo a la base de datos y pueden afectar al estado de la sesión, por lo que esta opción solo es segura en las siguientes situaciones:
1. Las instrucciones de `SET` son del tipo no-op, como, por ejemplo, establecer una variable del sistema en un valor idéntico al predeterminado del servidor.
1. Las instrucciones de `SET` y las consultas posteriores forman parte de la misma transacción, y cada transacción establece su propio estado de forma totalmente independiente para que no se vea afectada por las variables establecidas por otras transacciones.
**nota**
El filtro de fijación `EXCLUDE_VARIABLE_SETS` es un ajuste de “todo o nada” y no se puede elegir de forma selectiva las instrucciones de `SET` que se van a ignorar. No utilice este filtro como una solución general para la fijación, a menos que su caso de uso se incluya en una de las categorías descritas en la lista anterior.
Para obtener los mejores resultados, elimine las instrucciones innecesarias del código de la aplicación siempre que sea posible y utilice filtros únicamente si no es posible modificar la aplicación. Esto promueve un entorno entre cliente y servidor menos ruidoso y más predecible, en lugar de aplicar un tratamiento especial a las instrucciones que no son necesarias en primer lugar.
**importante**
Ni las consultas de inicialización ni los filtros de fijación provocan que RDS Proxy modifique el tráfico de consultas entre el cliente y el servidor. Las instrucciones que llegan de los clientes se siguen transmitiendo a la base de datos, independientemente de la configuración de la consulta de inicialización o del filtro de fijación.
Para obtener más información, consulte:
+ [Creación de un proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-creating.html) y [Modificación de un proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-modifying-proxy.html) para Amazon RDS.
+ [Creación de un proxy](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy-creating.html) y [Modificación de un proxy](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy-modifying-proxy.html) para Amazon Aurora.
Para las conexiones de PostgreSQL, también puede incluir los parámetros de conexión compatibles en el mensaje de inicio que se intercambia entre el controlador del cliente y el proxy. Esto evita el envío de comandos `SET` independientes, lo que reduce el número de idas y vueltas y evita que las conexiones se fijen debido a instrucciones de `SET` explícitas. Para obtener más información, consulte [Consideraciones para conectarse a PostgreSQL](rds-proxy-connecting.md#rds-proxy-connecting-postgresql).
## Alineación de la configuración de la aplicación, el proxy y la base de datos
Tal y como se ha explicado en la sección anterior, RDS Proxy admite una serie de parámetros que lo ayudan a alinear el comportamiento del proxy con las necesidades de la aplicación. Sin embargo, elegir los valores de configuración correctos es una tarea que abarca todas las capas de la pila: la aplicación, el proxy y la propia base de datos. La configuración de todos estos componentes debe estar en consonancia con los siguientes objetivos en mente:
1. Proporcionar el nivel previsto de rendimiento y escalabilidad durante las operaciones normales.
1. Promover la claridad y la facilidad de la solución de problemas durante los problemas de carga de trabajo.
1. Ayudar a la pila a hacer frente a eventos imprevistos (como, por ejemplo, picos de carga de trabajo) con un impacto mínimo en la aplicación.
Al elegir y establecer los ajustes en un entorno con varias capas, intente alinear los valores de configuración de forma que los límites y los tiempos de espera de una capa inferior sean iguales o superiores a los límites y tiempos de espera correspondientes de una capa superior. Dicho de otra manera, trate los ajustes de una capa como un sobre que debe encajar dentro del sobre definido por la configuración del nivel inferior en la pila.
Por ejemplo, supongamos que la aplicación es la capa superior, el proxy es la capa intermedia y la base de datos es la capa inferior. Si los tiempos de espera y los límites del proxy son inferiores a los límites de la aplicación, los límites del proxy prevalecen sobre los límites de la aplicación. La aplicación no puede probar sus ajustes y experimenta comportamientos que su propia configuración no puede explicar.
Considere el ajuste del proxy `IdleClientTimeout` como ejemplo. Si los controladores de aplicaciones o los grupos de clientes imponen sus propios tiempos de espera por inactividad, el tiempo de espera por inactividad del proxy es una red de seguridad sobre la configuración de la aplicación. Esto significa que `IdleClientTimeout` debe ser al menos igual a cualquier tiempo de espera por inactividad de la aplicación para evitar confusiones:
+ Cuando el tiempo de espera por inactividad de la aplicación es inferior al tiempo de espera del proxy, se espera que la aplicación cierre sus conexiones según lo configurado. Si la aplicación no cierra las conexiones inactivas a tiempo, el proxy actuará como respaldo.
+ Cuando el tiempo de espera por inactividad de la aplicación es mayor que el tiempo de espera del proxy, es posible que la aplicación experimente cierres de conexión que se consideren prematuros. Esto puede generar confusión en la aplicación.
La misma lógica se aplica a otros ajustes, como, por ejemplo, los límites de conexiones: los ajustes de cada capa deben encajar dentro del sobre definido por la configuración de la próxima capa.
Para obtener los mejores resultados, los ajustes de configuración deben incluir algún relleno entre una capa y la siguiente. Por ejemplo, puede hacer que el tiempo de espera del proxy sea unos segundos más prolongado que el tiempo de espera de la aplicación para evitar errores esporádicos debidos a la desviación del reloj entre el cliente y el servidor, o en caso de que el cliente necesite más tiempo para cerrar la conexión sin problemas.
Dicho de otro modo, alinee la configuración de la siguiente manera:
`client timeout < proxy timeout < database timeout`
En lugar de hacer esto:
`client timeout = proxy timeout = database timeout`
Y evite esto:
`client timeout > proxy timeout > database timeout`
## Configuración de las bases de datos
### Límites de conexión
RDS Proxy utiliza el ajuste `MaxConnectionsPercent` para determinar el tamaño máximo de su grupo de conexiones, lo que significa que el tamaño del grupo de conexiones del proxy depende del límite de conexiones de la base de datos. Al cambiar el límite de conexiones de la base de datos, el tamaño del grupo del proxy se ajustará automáticamente. Si desea que la base de datos reserve una parte del límite de conexiones para los usuarios que no utilizan el proxy, debería reducir el valor del ajuste `MaxConnectionsPercent` del proxy en lugar de aumentar el límite de la base de datos.
RDS Proxy no elimina la necesidad de configurar correctamente los límites de conexiones de la base de datos. Una conexión de proxy única no es intrínsecamente más ligera que una conexión directa del cliente única, por lo que no debe aumentar los límites de la base de datos por el solo hecho de utilizar un proxy. Un proxy no reduce la cantidad de trabajo que la base de datos debe realizar para gestionar las consultas, pero le ayuda a gestionar la misma carga de trabajo con menos conexiones.
### Tiempos de espera por inactividad
Las bases de datos pueden imponer sus propios tiempos de espera por inactividad, por ejemplo, mediante los ajustes `wait_timeout` y `interactive_timeout` de MySQL o los ajustes `transaction_timeout` y `idle_in_transaction_session_timeout` de PostgreSQL. Es poco probable que los valores predeterminados de estos ajustes interfieran con la configuración del proxy, pero si utiliza tiempos de espera personalizados de la base de datos, asegúrese de que sean al menos tan prolongados como los tiempos de espera del proxy correspondientes o, de lo contrario, el proxy experimentará errores de conexión debido a tiempos de espera prematuros.
La misma lógica se aplica a los entornos de bases de datos que utilizan bloqueadores de conexiones, que son scripts o procesos que supervisan el estado de la sesión y finalizan de forma activa las conexiones en función de determinados criterios. Si el entorno utiliza estas técnicas, asegúrese de que la lógica de finalización de la conexión esté en consonancia con la configuración del proxy.
Las bases de datos que gestionan toda la carga de trabajo a través del proxy suelen depender de la configuración del proxy para los tiempos de espera por inactividad y dejan la configuración de la base de datos en sus valores predeterminados.
## Configuración de aplicaciones
### Administración del estado de la sesión
Un gran número de controladores de bases de datos, marcos de aplicaciones y herramientas de asignación relacional de objetos (ORM) utilizan variables de sesión o instrucciones de `SET` para configurar las conexiones antes de enviar el tráfico de consultas. El uso de instrucciones de inicialización de conexiones y transacciones puede no resultar obvio si se analiza únicamente el código de la aplicación, y puede haber varios niveles de abstracción entre la propia base de datos y las instrucciones de SQL y la lógica de la aplicación. Puede utilizar la característica de registro mejorado de RDS Proxy para registrar los motivos por los que se fija la conexión, y los registros de consultas a la base de datos pueden proporcionar más información sobre todas las instrucciones enviadas a través de las conexiones de la base de datos.
Tenga en cuenta las siguientes prácticas recomendadas:
1. Configure los parámetros de conexión solo cuando sean diferentes de los valores predeterminados de la base de datos y la sesión del cliente deba desviarse de dichos valores. La eliminación de las instrucciones de inicialización innecesarias no solo ayuda a la multiplexación, sino que también reduce el número de idas y vueltas entre el cliente y el servidor por cada nueva conexión a la base de datos.
1. Establezca variables y parámetros de configuración de forma coherente en todas las conexiones.
1. Evite una configuración de la sesión que también se pueda aplicar en el tiempo de ejecución de la consulta. Por ejemplo, si distintos clientes necesitan ver los datos en distintas zonas horarias, plantéese utilizar funciones de conversión de zonas horarias para la consulta en lugar de establecer la zona horaria para la sesión.
1. Si es posible, traslade las instrucciones de configuración de la sesión a la capa de proxy mediante la característica de consulta de inicialización. Para obtener más información, consulte [Consultas de inicialización y filtros de fijación](#rds-proxy-best-practices.configuration.pinning-filters).
### Comprobaciones de actividad
Si la aplicación utiliza una agrupación de conexiones o controladores avanzados, busque configuraciones relacionadas con las comprobaciones de actividad, como, por ejemplo, los pings de protocolo, las instrucciones de comprobación de estado o las consultas de keep-alive. RDS Proxy trata todas las solicitudes de los clientes por igual, por lo que, aunque una consulta de `SELECT 1;` o una solicitud de `COM_PING` sea no-op desde el punto de vista de la aplicación, impide que el proxy imponga tiempos de espera de los clientes inactivos y administre el tamaño del grupo de conexiones en función de `MaxIdleConnectionsPercent`.
**nota**
RDS Proxy impone una vida útil máxima de conexión de 24 horas, independientemente de la actividad de la conexión.
En la mayoría de los casos, puede ser adecuado deshabilitar las comprobaciones de actividad del cliente para reducir el ruido del protocolo y ayudar a RDS Proxy a administrar las conexiones inactivas. De todos modos, hay casos extremos en los que es posible que desee ejecutar esas comprobaciones de estado:
+ Quiere evitar deliberadamente que se agote el tiempo de espera de determinadas conexiones en la capa de proxy.
+ Desea permitir que el controlador o el grupo de aplicaciones detecten de forma proactiva cuando el proxy interrumpe una conexión. Por ejemplo, es posible que las conexiones backend fijadas se cierren debido al reinicio de la base de datos y que las conexiones de los clientes superen la vida útil máxima de 24 horas.
Plantéese deshabilitar las comprobaciones de actividad de la aplicación o realícelas únicamente para aquellas conexiones para las que desee evitar que se agote el tiempo de espera.
### Seguimiento del estado de la sesión
Algunos controladores de bases de datos de MySQL, como, por ejemplo, el controlador MariaDB, utilizan variables `session_track_*` para permitir el seguimiento del estado de la sesión. Con esta característica habilitada, cada vez que el cliente realice un cambio en el estado de la sesión al que el servidor puede realizar un seguimiento, el servidor incluirá la información de dicho cambio en sus paquetes de respuesta. Esto permite que el servidor informe al controlador sobre el estado de la sesión.
Este tipo de seguimiento del estado de la sesión puede resultar útil cuando el cliente interactúa directamente con el servidor e implementa sus propias características de administración de sesiones, como, por ejemplo, la migración de sesiones en entornos con varios servidores. RDS Proxy implementa sus propios mecanismos de seguimiento del estado y no utiliza la información habilitada por las variables `session_track_*`; sin embargo, la configuración de dichas variables, provoca la fijación de la sesión.
Si el controlador de la base de datos establece estas variables, puede buscar formas de deshabilitar la funcionalidad de seguimiento en el controlador, cambiar a otro controlador o utilizar filtros de fijación de sesiones para ignorar las instrucciones, en el caso de que sea seguro hacerlo. Para obtener más información, consulte [Consultas de inicialización y filtros de fijación](#rds-proxy-best-practices.configuration.pinning-filters).