Procedimientos recomendados para un rendimiento óptimo de Azure Database for MySQL con servidor flexible
Aprenda a obtener el mejor rendimiento mientras trabaja con Azure Database for MySQL con servidor flexible. Al agregar nuevas funcionalidades a la plataforma, seguiremos perfeccionando las recomendaciones de esta sección.
Proximidad física
Asegúrese de implementar una aplicación y la base de datos en la misma región. Una comprobación rápida antes de iniciar cualquier ejecución de pruebas comparativas de rendimiento es determinar la latencia de red entre el cliente y la base de datos mediante una consulta SELECT 1 simple.
Cuando los recursos como una aplicación web y su base de datos asociada se ejecutan en regiones diferentes, puede haber una mayor latencia en la comunicación entre esos recursos. Otro efecto secundario posible de tener la aplicación y la base de datos en regiones independientes se relaciona con los costos de transferencia de datos salientes.
Para mejorar el rendimiento y la confiabilidad de una aplicación en una implementación optimizada para costo, se recomienda encarecidamente que el servicio de aplicación web y el recurso Azure Database for MySQL con servidor flexible residan en la misma región y zona de disponibilidad. Esta coubicación es la mejor para las aplicaciones que son sensibles a la latencia y también proporciona el mejor rendimiento, ya que los recursos están estrechamente emparejados.
Redes aceleradas
Use redes aceleradas para el servidor de aplicaciones si usa una máquina virtual de Azure, Azure Kubernetes o App Services. Las redes aceleradas habilitan la virtualización de E/S de raíz única (SR-IOV) en una máquina virtual, lo que mejora considerablemente su rendimiento en la red. Este método de alto rendimiento omite el host de la ruta de acceso de datos, lo que reduce la latencia, la inestabilidad y la utilización de la CPU para usarse con las cargas de trabajo de red más exigentes en los tipos de máquina virtual admitidos.
Eficacia de la conexión
El establecimiento de una nueva conexión siempre es una tarea costosa y que consume mucho tiempo. Cuando una aplicación solicita una conexión de base de datos, da prioridad a la asignación de las conexiones de base de datos inactivas existentes, en lugar de crear una nueva. Estas son algunas opciones para las prácticas de conexión correctas:
ProxySQL: use ProxySQL, que proporciona agrupación de conexiones integrada y equilibrio de carga de la carga de trabajo a varias réplicas de lectura según sea necesario a petición con cualquier cambio en el código de la aplicación.
Proxy de datos de Heimdall: como alternativa, también puede aprovechar el proxy de datos de Heimdall, una solución de proxy patentada independiente del proveedor. Admite el almacenamiento en caché de consultas y la división de lectura/escritura con la detección de retrasos de replicación. También puede consultar cómo acelerar el rendimiento de MySQL con el proxy de Heimdall.
Conexión persistente o de larga duración: si la aplicación tiene transacciones cortas o consultas normalmente con un tiempo de ejecución de < 5-10 ms, reemplace las conexiones cortas por conexiones persistentes. Reemplazar las conexiones cortas por conexiones persistentes solo requiere cambios menores en el código, pero tiene un efecto importante en cuanto a la mejora del rendimiento en muchos escenarios de aplicación típicos. Asegúrese de establecer el tiempo de espera o cerrar la conexión una vez completada la transacción.
Réplica: si usa la réplica, use ProxySQL para equilibrar la carga entre el servidor principal y el servidor de la réplica secundaria legible. Aprenda cómo configurar una instancia de ProxySQL.
Agrupación de conexiones
La agrupación de conexiones es un mecanismo que administra la creación y asignación de conexiones de base de datos y protege una base de datos frente a picos de conexión. Considere la posibilidad de agrupar conexiones si la aplicación abre muchas conexiones en un tiempo relativamente corto y las conexiones son de corta duración. Estos tipos de conexiones pueden producirse, por ejemplo, en una magnitud de cientos o miles por segundo, y el tiempo necesario para establecerlos y cerrarlos es significativo en comparación con la duración total de la conexión.
Si el marco de desarrollo de su aplicación no admite la agrupación de conexiones, use en su lugar un proxy de conexión, como ProxySQL o Heimdall, entre la aplicación y el servidor de base de datos.
Control del escalado de conexiones
Un enfoque común para escalar aplicaciones web para satisfacer la demanda fluctuante es agregar y quitar servidores de aplicaciones. Cada servidor de aplicaciones puede usar un grupo de conexiones con la base de datos. Este enfoque hace que el número total de conexiones en un servidor de bases de datos crezca en relación con el número de servidores de aplicaciones. Por ejemplo, si un servidor de bases de datos tiene 10 servidores de aplicaciones y cada uno está configurado para 100 conexiones de base de datos, esto proporcionaría 1000 conexiones de base de datos. Si la carga de trabajo de la aplicación se escala debido a una actividad de usuario mayor o durante las horas punta y si se agregan 50 servidores de aplicaciones adicionales, las conexiones de base de datos serían 6000 en total. Normalmente, la mayoría de estas conexiones estarán inactivas, después de que los servidores de aplicaciones generen. Dado que las conexiones inactivas consumen recursos (memoria y CPU) para permanecer abiertos, la escalabilidad de la base de datos podría verse afectada.
Los posibles desafíos adicionales implican controlar el número total de conexiones al servidor de bases de datos. Esto viene determinado por el número de servidores de aplicaciones conectados al servidor de bases de datos, cada uno de los cuales crea su propio conjunto de conexiones. En estas situaciones, considere la posibilidad de ajustar los grupos de conexiones en los servidores de aplicaciones. Intente reducir el número de conexiones de cada grupo a un mínimo aceptable para asegurarse de que no haya ningún sobredimensionamiento en las conexiones en el lado del servidor de bases de datos. Considere esto como una solución a corto plazo para contrarrestar los efectos del escalado del servidor de aplicaciones en lugar de una solución permanente para abordar el crecimiento de la aplicación.
Como solución a largo plazo, introduzca un proxy de conexión, como ProxySQL o proxy Heimdall, entre el servidor de bases de datos y el servidor de aplicaciones. Esto ayuda a que el proxy:
- Establezca una conexión con el servidor de bases de datos con un número fijo de conexiones.
- Acepte conexiones de aplicación y actúe como búfer para posibles tormentas de conexión.
Los servidores proxy pueden proporcionar otras características, como el almacenamiento en caché de consultas, el almacenamiento en búfer de conexión, la reescritura y el enrutamiento de consultas y el equilibrio de carga. Para una escalabilidad aún mayor, considere la posibilidad de usar varias instancias de proxy.
Control de conexiones para tolerancia a errores y recuperación más rápida
Al diseñar las aplicaciones y el entorno para la tolerancia a errores y una recuperación más rápida, tenga en cuenta que en un entorno de base de datos, es probable que experimente interrupciones de conexión o errores de hardware. Recuerde también la necesidad de acciones operativas, como el escalado de tamaños de instancia, la aplicación de revisiones y la realización de una conmutación por error manual.
Por ejemplo, considere un escenario en el que el servidor de bases de datos completa la conmutación por error en un minuto, pero la aplicación está inactiva durante varios minutos más debido a que el TTL de DNS es demasiado largo en el lado de la aplicación. En estos casos, simplemente reducir el valor de TTL proporcionará una recuperación más rápida o integrar un proxy de conexión entre la aplicación y el servidor de base de datos puede ayudar a controlar estos errores.
Partition
Cuando la carga de trabajo de producción usa tablas extremadamente grandes, la creación de particiones es un excelente método para mejorar el rendimiento de la base de datos y facilitar el mantenimiento. La creación de particiones facilita la administración de tablas grandes, este enfoque permite agregar y quitar particiones para administrar tablas grandes de forma eficaz. La creación de particiones también puede ayudar a escalar el motor al aliviar la contención de la estructura interna, como bloqueos internos por tabla o por índice (por ejemplo, considere la btr_search_latch en InnoDB).
Al agregar cinco particiones, por ejemplo, básicamente se divide una tabla grande con una gran cantidad de actividad en cinco tablas más pequeñas y eficaces. Esto ayudaría principalmente a los casos en los que la operación principal es búsquedas de clave principal en la tabla, de modo que las consultas pueden aprovechar la "eliminación de particiones". Pero la creación de particiones también puede ayudar en términos de examen de tabla.
Aunque la creación de particiones tiene sus ventajas, también tiene algunas limitaciones, como la falta de compatibilidad con claves externas en tablas con particiones, la falta de caché de consultas, etc. Para obtener una lista completa de estas limitaciones, en el manual de referencia de MySQL, consulte el capítulo Restricciones y limitaciones en la creación de particiones.
Segregar lecturas y escrituras
La mayoría de las aplicaciones se leen principalmente desde la base de datos, con un pequeño porcentaje de las interacciones que implican escrituras. El número de conexiones activas en la base de datos principal que calculamos para los grupos de conexiones probablemente incluye tráfico de lectura. La descarga de tantas consultas para réplicas de lectura como sea posible y conservar el acceso a la instancia de escritura principal aumenta la cantidad de actividad global de la base de datos realizada por los servidores de aplicaciones sin aumentar la carga en la base de datos principal. Si aún no tiene acceso a réplicas de lectura al menos para consultas de ejecución más largas, como informes, debe considerar mover informes o análisis inmediatamente a las réplicas de lectura.
Un uso más amplio de réplicas de lectura podría requerir una consideración más cuidadosa, ya que las réplicas se retrasan ligeramente detrás de la principal debido a la naturaleza asincrónica de la replicación. Busque tantas áreas de la aplicación como sea posible que se puedan servir con lecturas de las réplicas con cambios de código menores. También debe aplicar este método en niveles superiores relativos al almacenamiento en caché: proporcione más contenido de solo lectura o que cambie lentamente el contenido de un nivel de almacenamiento en caché dedicado, como Azure Cache for Redis.
Escalado y particionamiento de escritura
Con el tiempo, las aplicaciones evolucionan y se agrega una nueva funcionalidad. Fuera de comodidad o práctica general, las tablas se agregan a la base de datos principal. Para controlar las cargas de tráfico crecientes en una base de datos, identifique las áreas de la aplicación que se pueden mover fácilmente a bases de datos independientes y considere la posibilidad de particionar horizontalmente o dividir verticalmente la base de datos.
El particionamiento horizontal de una base de datos funciona mediante la creación de varias copias del esquema de la aplicación en bases de datos independientes y la separación de clientes y todos los datos asociados en función del identificador de cliente, la geografía o algún otro atributo por cliente o inquilino. Esto funciona muy bien para las aplicaciones SaaS o B2C en las que los clientes individuales son pequeños y la carga en la aplicación procede del uso agregado de millones de clientes. Sin embargo, es más difícil con las aplicaciones B2B en las que los clientes tienen diferentes tamaños y los clientes grandes individuales pueden dominar la carga de tráfico para una partición determinada.
Dividir verticalmente la carga mediante particionamiento funcional de la base de datos: mover dominios de aplicación independientes (o microservicios) a sus propias bases de datos. Esto distribuye la carga de la base de datos principal a bases de datos por servicio independientes. Algunos ejemplos sencillos incluyen una tabla de registro o información de configuración del sitio que no necesita estar en la misma base de datos que la tabla de pedidos con mucha carga. Entre los ejemplos más complicados se incluyen la interrupción de los dominios de cliente y cuenta, aparte de los dominios de pedidos o de suministro. En algunos casos, esto podría requerir cambios en la aplicación, por ejemplo, modificar las colas de trabajos en segundo plano o correo electrónico para que sean independientes y no confiar en las combinaciones a una tabla de clientes o pedidos. El traslado de tablas y datos existentes a una nueva base de datos principal se puede realizar con réplicas de lectura de Azure Database for MySQL con servidor flexible y promover la réplica y apuntar partes de la aplicación a la base de datos grabable recién creada. La base de datos recién creada debe limitar el acceso con grupos de conexiones, optimizar las consultas y distribuir la carga con sus propias réplicas igual que la principal original.
Configuraciones de importación de datos
- Puede escalar temporalmente la instancia a un mayor tamaño de SKU antes de iniciar una operación de importación de datos y luego reducirla verticalmente cuando la importación sea correcta.
- Puede importar los datos con un tiempo de inactividad mínimo mediante Migrar MySQL localmente a Azure Database for MySQL para migraciones en línea o sin conexión.
Recomendaciones de memoria para Azure Database for MySQL con servidor flexible
Un procedimiento recomendado de rendimiento de Azure Database for MySQL con servidor flexible es asignar suficiente RAM para que el conjunto de trabajo resida casi completamente en la memoria.
- Compruebe si el porcentaje de memoria se está utilizando para alcanzar los límites con las métricas de Azure Database for MySQL con servidor flexible.
- Configure alertas con tales números para asegurarse de que, a medida que los servidores alcanzan los límites, puede realizar acciones rápidas para corregirlo. En función de los límites definidos, compruebe si se escala verticalmente la SKU de la base de datos, ya sea para un mayor tamaño de proceso o para mejorar el plan de tarifa, lo que da lugar a un aumento considerable del rendimiento.
- Escale verticalmente hasta que los números de rendimiento dejen de caer drásticamente después de una operación de escalado. Para más información sobre la supervisión de las métricas de una instancia de base de datos, consulte Métricas de base de datos de Azure Database for MySQL con servidor flexible.
Uso de la preparación del grupo de búferes de InnoDB
Después de que se reinicia la instancia de Azure Database for MySQL con servidor flexible, las páginas de datos que residen en el almacenamiento se cargan cuando se consultan las tablas, lo que conduce a una mayor latencia y un menor rendimiento en la primera ejecución de las consultas. Esto puede no ser aceptable para cargas de trabajo sensibles a la latencia.
El uso de la preparación del grupo de búferes de InnoDB acorta el período de preparación mediante la recarga de las páginas del disco que estaban en el grupo de búferes antes del reinicio, en lugar de esperar a que las operaciones DML o SELECT accedan a las filas correspondientes.
Puede reducir el período de preparación después de reiniciar la instancia de Azure Database for MySQL con servidor flexible, lo que representa una ventaja de rendimiento mediante la configuración de los parámetros del servidor del grupo de búferes de InnoDB. InnoDB guarda un porcentaje de las páginas usadas más recientemente para cada grupo de búferes al cerrar el servidor y restaura estas páginas al iniciar el servidor.
También es importante tener en cuenta que el rendimiento mejorado se produce a costa del tiempo de inicio más largo para el servidor. Cuando este parámetro está habilitado, se espera que el tiempo de inicio y reinicio del servidor aumente en función de las IOPS aprovisionadas en dicho servidor.
Se recomienda probar y supervisar el tiempo de reinicio para garantizar que el rendimiento de inicio y reinicio es aceptable, ya que el servidor no está disponible durante ese tiempo. No se recomienda usar este parámetro con menos de 1000 IOPS aprovisionadas (es decir, cuando el almacenamiento aprovisionado es inferior a 335 GB).
Para guardar el estado del grupo de búferes al cerrar el servidor, establezca el parámetro de servidor innodb_buffer_pool_dump_at_shutdown en ON. Del mismo modo, establezca el parámetro de servidor innodb_buffer_pool_load_at_startup en ON para restaurar el estado del grupo de búferes al iniciar el servidor. Puede controlar el impacto del tiempo de inicio o reinicio si reduce y ajusta el valor del parámetro de servidor innodb_buffer_pool_dump_pct. De manera predeterminada, este parámetro está establecido en 25.
Nota
Los parámetros de preparación del grupo de búferes de InnoDB solo se admiten en servidores de almacenamiento de uso general con un almacenamiento de hasta 16 TB. Para más información, consulte Opciones de almacenamiento de Azure Database for MySQL con servidor flexible.