Azure Database for MySQL: Características de rendimiento de servidor flexible
Puede crear servidores flexibles de Azure Database for MySQL basados en uno de los tres niveles de servicio: Ampliable, de uso general y crítico para la empresa. Los niveles de servicio proporcionan un nivel creciente de tamaño de proceso y almacenamiento, así como el número admitido de conexiones máximas y operaciones de E/S por segundo (IOPS). Un servidor flexible de MySQL puede hospedar varias bases de datos. Puede supervisar las métricas de rendimiento del servidor flexible de MySQL, como el uso de CPU y memoria, el rendimiento de E/S, las métricas de consulta y mucho más, para tomar decisiones de capacidad informadas.
Tamaño de proceso: RAM y núcleos
Cada uno de los tres niveles de servicio proporciona diferentes SKU de máquina virtual subyacentes. El nivel Ampliable usa máquinas virtuales de la serie B, el nivel de uso general usa máquinas virtuales de la serie D y el nivel Crítico para la empresa usa máquinas virtuales de la serie E. La serie de máquinas virtuales usada determina el número de núcleos virtuales y RAM disponibles en el servidor.
Puede cambiar el nivel de proceso, el tamaño de proceso y el tamaño de almacenamiento después de crear un servidor. Cambiar el nivel de proceso o el tamaño de proceso requiere un reinicio que normalmente tarda entre uno y dos minutos en completarse. No es necesario reiniciar el cambio del tamaño de almacenamiento.
En el caso de cargas de trabajo que no sean de producción (desarrollo, ensayo, pruebas, etc.), considere la posibilidad de usar servidores basados en el nivel Ampliable, que proporciona una solución rentable para cargas de trabajo que no usan continuamente la CPU completa. Durante períodos de uso bajo, los servidores que usan máquinas virtuales de la serie B acumular créditos de CPU que se pueden usar en períodos de uso elevado para "expandir" el rendimiento por encima de la línea base. Si la línea base es demasiado alta o hay demasiadas ráfagas de uso elevadas, considere la posibilidad de actualizar a los niveles de uso General o Crítico para la empresa para evitar la degradación del rendimiento.
Tamaños de proceso de nivel de servicio
Cada uno de los tres niveles de servicio proporciona diferentes niveles de potencia de proceso. Aunque el nivel Ampliable puede admitir hasta 20 núcleos virtuales y el nivel de uso general puede admitir hasta 64 núcleos virtuales, con compatibilidad con hasta 96 núcleos virtuales, el nivel Crítico para la empresa proporciona el nivel de proceso más alto. El nivel Crítico para la empresa también proporciona las máquinas virtuales de la serie Ev5, que hasta un 30 % más QPS y un 50 % menos de latencia que las máquinas virtuales de la serie Ev4.
IOPS: Escalado preaprovisionado frente a escalabilidad automática
El número de operaciones de lectura y escritura que se pueden realizar por segundo se conoce como IOPS de almacenamiento (operaciones de E/S por segundo). Una mayor configuración de IOPS proporciona un mejor rendimiento de almacenamiento: las operaciones de lectura y escritura simultáneas dan lugar a una recuperación de datos más rápida, persistencia de datos, actualizaciones de índice y eficiencia general de la base de datos. Si la configuración de IOPS es demasiado baja, la base de datos podría experimentar retrasos en el procesamiento y un rendimiento degradado. Sin embargo, si la configuración de IOPS es demasiado alta, es posible que los costos aumenten sin que se produzcan mejoras en el rendimiento.
Con el servidor flexible de Azure Database for MySQL, puede aprovisionar previamente IOPS o usar la característica IOPS de escalabilidad automática.
Con IOPS aprovisionadas previamente, asigna un número específico de IOPS para proporcionar un rendimiento coherente y predecible, lo que funciona bien si la carga no se aproxima al umbral en el que las operaciones de E/S se limitan. Aunque siempre puede asignar IOPS adicionales a medida que aumentan las demandas de carga de trabajo, esto requiere intervención manual.
Con la característica Escalabilidad automática IOPS habilitada, la escala de IOPS a petición en función de la actividad de la carga de trabajo y se paga en función del consumo. A medida que aumenta la carga de trabajo, el servidor escala el rendimiento de E/S sin problemas, lo que permite a la instancia controlar los picos de carga de trabajo sin pagar la capacidad sin usar cuando el tráfico es bajo.
En cualquier caso, IOPS no puede superar el máximo del servidor. Para obtener información sobre el número máximo de IOPS por tamaño de proceso, vea el artículo Documentación de proceso y almacenamiento.
Réplicas de lectura
A medida que aumenta el tráfico de la base de datos, puede escalar su capacidad horizontal o "fuera" (número de nodos de proceso) o vertical o "arriba" (tamaño de los nodos de proceso). Las réplicas de lectura proporcionan escalado horizontal.
Una réplica de lectura es una copia de solo lectura de una base de datos que permanece sincronizada mediante la replicación de registros binarios de MySQL (binlog). A medida que crecen las aplicaciones, necesitan escalar los recursos de proceso y almacenamiento (como la base de datos). El escalado de componentes de aplicación se simplifica mediante el aprovisionamiento de nuevas máquinas virtuales mediante Azure Kubernetes Service (AKS), Virtual Machine Scale Sets, y App Service. A medida que estos recursos de proceso escalan y aumentan los datos almacenados, aumentan la carga de la base de datos, lo que a menudo termina siendo un cuello de botella en la arquitectura de la aplicación.
El uso de una réplica de lectura permite desviar las operaciones de solo lectura a las bases de datos secundarias para que el servidor principal admita operaciones de lectura y escritura. Azure Database for MySQL proporciona réplicas de lectura administradas. Puede replicar un servidor de origen en hasta 10 réplicas. Esto puede ayudar en casos de uso como informes y análisis, que a menudo consultan grandes cantidades de datos.
El uso de una réplica de lectura es especialmente útil cuando por un motivo u otra consulta no puede usar índices. Puede ser poco práctico o incluso perjudicial agregar índices para todos los patrones de consulta, ya que coloca una carga adicional en el servidor (procesamiento, E/S de disco, almacenamiento, tiempo de transacción, etc.). Si un almacenamiento de datos no está disponible o necesita datos más recientes que su ciclo de actualización, el uso de una réplica de lectura es una excelente manera de ejecutar consultas "grandes" sin interrumpir las operaciones críticas de lectura y escritura.
Las réplicas de lectura no son sincrónicas inmediatamente de la misma manera que es una configuración de alta disponibilidad. Las réplicas de lectura no presentan la latencia transaccional asociada a una solución de alta disponibilidad, pero puede haber un ligero retraso a medida que los datos llegan a la réplica de la base de datos principal.