Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Administración de conexiones
A medida que crece la demanda de su aplicación, aumenta el tráfico de frontend. En un escenario típico, se configura el escalado automático en el nivel de la aplicación para manejar esa ráfaga de tráfico entrante. Como resultado, el nivel de aplicación comienza a escalarse automáticamente y se agregan más servidores de aplicaciones (instancias) para hacer frente al aumento del tráfico. Como todos los servidores de aplicaciones tienen una configuración de grupo de conexiones de base de datos preconfigurada, el número de conexiones entrantes a la base de datos aumenta en proporción a las instancias recién implementadas.
Por ejemplo, 20 servidores de aplicaciones configurados con 200 conexiones de base de datos cada uno abrirían un total de 4000 conexiones de base de datos. Si el grupo de aplicaciones se escala verticalmente hasta 200 instancias (por ejemplo, durante las horas pico), el número total de conexiones alcanzará las 40 000. En una carga de trabajo típica, es probable que la mayoría de estas conexiones estén inactivas. Sin embargo, el aumento de las conexiones podría limitar la capacidad de escalar de la base de datos de Amazon Aurora MySQL-Compatible Edition. Esto se debe a que incluso las conexiones inactivas utilizan memoria y otros recursos del servidor, como los descriptores de archivos. Aurora, compatible con MySQL, suele utilizar menos memoria que MySQL Community Edition para mantener el mismo número de conexiones. Sin embargo, el uso de memoria para las conexiones inactivas aún no es cero.
Variables de configuración
Puede controlar el número de conexiones entrantes permitidas a la base de datos con dos variables principales de configuración del servidor: max_connections y max_connect_errors.
Variable de configuración max_connections
La variable de configuración max_connections limita el número de conexiones a bases de datos para cada instancia de MySQL. La práctica recomendada es establecerlo un poco por encima del número máximo de conexiones que se espera abrir en cada instancia de base de datos.
Si también ha activado performance_schema, tenga mucho cuidado con la configuración de max_connections. Las estructuras de memoria del esquema de rendimiento se dimensionan automáticamente en función de las variables de configuración del servidor, entre las que se incluyen max_connections. Cuanto más alta establezca la variable, más memoria utilizará Performance Schema. En casos extremos, esto puede provocar out-of-memory problemas en tipos de instancias más pequeñas. Tenga en cuenta que al habilitar Performance Insights, se habilitará Performance Schema automáticamente.
Variable de configuración max_connect_errors
La variable de configuración max_connect_errors determina cuántas solicitudes de conexión interrumpidas sucesivas se permiten desde un host cliente determinado. Si el host cliente supera el número especificado de intentos de conexión sucesivos fallidos, el servidor lo bloquea. Los intentos de conexión posteriores de ese cliente producen un error.
Host 'host_name' is blocked because of many connection errors. Unblock with
'mysqladmin flush-hosts'
Si se produce el error «el host está bloqueado», evite aumentar el valor de la max_connect_errors variable. En cambio, investigue los contadores de diagnóstico del servidor en la variable de estado aborted_connects y la tabla host_cach. Utilice la información recopilada para identificar y corregir los clientes que tengan problemas de conexión. Además, tenga en cuenta que este parámetro no tiene ningún efecto si skip_name_resolve está configurado en 1 (predeterminado).
Consulte el manual de referencia de MySQL para obtener más información sobre lo siguiente:
Implementar la agrupación de conexiones
Un evento de escalado podría agregar más servidores de aplicaciones, lo que, a su vez, podría provocar que el servidor de base de datos supere el número de conexiones activas completamente cargadas. La adición de un grupo de conexiones o una capa de proxy entre los servidores de aplicaciones y la base de datos actúa como un cuello de botella, ya que reduce el número total de conexiones de la base de datos. El objetivo principal de un proxy es volver a utilizar las conexiones de bases de datos mediante la multiplexación.
Por un lado, el proxy se conecta a la base de datos con un número controlado de conexiones. Por otro lado, el proxy acepta conexiones de aplicaciones. También ofrece características adicionales, como el almacenamiento en caché de consultas, el almacenamiento en búfer de conexiones, la reescritura y el enrutamiento de consultas y el equilibrio de carga. La capa del grupo de conexiones debe configurarse para mantener el número máximo de conexiones a la base de datos por debajo del número de conexiones completamente cargadas. Amazon RDS Proxy
También puede explorar los siguientes proxy de terceros que se pueden usar con Aurora MySQL-Compatible:
Evite las tormentas de conexiones
Tenga en cuenta cómo se comporta su grupo de conexiones en caso de que una base de datos esté sobrecargada o una réplica quede demasiado alejada del nodo principal. Al configurar el servidor proxy o los grupos de conexiones, asegúrese de no restablecer todo el grupo de conexiones en función de las respuestas lentas de la base de datos (causadas por problemas de equipo o almacenamiento o por limitaciones de recursos de la base de datos).
El inicio repentino de cientos de conexiones genera una tormenta de conexiones porque un gran número de solicitudes de nuevas conexiones a la base de datos se inician todas al mismo tiempo. La tormenta consume muchos recursos. Crear una nueva conexión de base de datos en MySQL es una operación costosa, porque el backend intercambia varios paquetes de red para la conexión inicial, genera un nuevo proceso, asigna memoria, gestiona la autenticación, etc. Si se recibe una gran cantidad de solicitudes en un periodo corto, puede parecer que la base de datos no responde.
MySQL tiene un mecanismo para protegerse contra este aumento en las solicitudes de conexión. La variable back_log se puede establecer en el número de solicitudes que se pueden acumular durante un breve periodo antes de que MySQL deje de responder de forma temporal a las nuevas solicitudes. El valor lo impone un subproceso de administración de conexiones, que a su vez podría verse abrumado por una tormenta de conexiones. Para obtener más información, consulte el MySQL Reference Manual
Si la conexión está configurada para restablecerse cuando la base de datos es lenta, iniciará el ciclo una y otra vez. Del mismo modo, si prevé un aumento repentino del tráfico de la base de datos en determinados momentos del día (por ejemplo, al abrir el mercado de valores), prepare previamente el grupo de conexiones para no tener que abrir muchas conexiones cuando se inicia una gran carga de tráfico.
