View a markdown version of this page

Directrices de configuración - Amazon Aurora
Configuración de RDS ProxyAlineación de la configuración de la aplicación, el proxy y la base de datosConfiguración de las bases de datosConfiguración de aplicaciones

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.

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.

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:

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 y Aurora PostgreSQL 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.

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.

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.

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

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.

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.

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.

  2. 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:

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.

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.

  2. Promover la claridad y la facilidad de la solución de problemas durante los problemas de carga de trabajo.

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

  2. Establezca variables y parámetros de configuración de forma coherente en todas las conexiones.

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

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

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.