Azure Database for MySQL: niveles de servidor flexible
Puede crear una instancia de servidor flexible de Azure Database for MySQL en uno de los tres niveles de servicio: Ampliable, De uso general y Crítico para la empresa. La SKU de la VM subyacente diferencia los niveles de servicio que se usan en la serie B, la serie D y la serie E. La elección del nivel de procesamiento y del tamaño determina la memoria y los núcleos virtuales disponibles en el servidor. Se usa la misma tecnología de almacenamiento en todos los niveles de servicio. Todos los recursos se aprovisionan en el nivel de instancia de servidor flexible de Azure Database for MySQL. Un servidor puede tener una o varias bases de datos.
| Recurso/nivel | Flexible | Uso general | Crítico para la empresa |
|---|---|---|---|
| Series de máquinas virtuales | Tamaños de las VM ampliables de serie B | Dadsv5-seriesDdsv4-series | Edsv4/Edsv5-series*/Eadsv5-series |
| Núcleos virtuales | 1, 2, 4, 8, 12, 16, 20 | 2, 4, 8, 16, 32, 48, 64 | 2, 4, 8, 16, 32, 48, 64, 80, 96 |
| Memoria por núcleo virtual | Variable | 4 GiB | 8 GiB ** |
| Tamaño de almacenamiento | De 20 GiB a 16 TiB | De 20 GiB a 16 TiB | De 20 GiB a 32 TiB |
| Período de retención de copias de seguridad de base de datos | De 1 a 35 días | De 1 a 35 días | De 1 a 35 días |
** Excepto 64.80 y 96 núcleos virtuales, que tienen 504 GiB, 504 GiB y 672 GiB de memoria, respectivamente.
* El proceso Ev5 obtiene los mejores resultados entre las demás series de máquinas virtuales en cuanto a QPS y latencia. Obtenga más información sobre el rendimiento y la disponibilidad de regiones del proceso Ev5 desde aquí.
Niveles de servicio de servidor flexible
Para elegir un nivel de proceso, use la siguiente tabla como punto de partida.
| Nivel de proceso | Carga de trabajo objetivo |
|---|---|
| Flexible | Ideal para cargas de trabajo que no necesitan continuamente toda la CPU. |
| Uso general | La mayoría de las cargas de trabajo empresariales requieren un equilibrio entre el proceso y memoria con un rendimiento de E/S escalable. Por ejemplo, servidores para hospedar aplicaciones web y móviles, y otras aplicaciones empresariales. |
| Crítico para la empresa | Cargas de trabajo de base de datos de alto rendimiento que requieren rendimiento en memoria para un procesamiento de transacciones más rápido y una mayor simultaneidad. Por ejemplo, servidores para procesar datos en tiempo real y aplicaciones de análisis y transacciones de alto rendimiento. |
Después de crear un servidor, puede cambiar el nivel de proceso, el tamaño de proceso y el tamaño de almacenamiento. El escalado de proceso requiere un reinicio y tarda entre 60 y 120 segundos, mientras que el escalado de almacenamiento no lo requiere. También puede aumentar o reducir de forma independiente el periodo de retención de la copia de seguridad. Consulte la secciónEscalado de recursos para obtener más información.
Niveles de servicio, tamaño y tipos de servidor
Los recursos de proceso se pueden seleccionar en función del nivel y el tamaño. Esto determina los núcleos virtuales y el tamaño de la memoria. Los núcleos virtuales representan la CPU lógica del hardware subyacente.
Flexible
Las especificaciones detalladas de los tipos de servidor disponibles son las siguientes para el nivel de servicio Ampliable.
| Tamaño de proceso | Núcleos virtuales | Tamaño de memoria física (GiB) | Tamaño total de memoria (GiB) | IOPS máximas admitidas | Conexiones máximas | GiB de almacenamiento temporal (SSD) |
|---|---|---|---|---|---|---|
| Standard_B1ms | 1 | 2 | 2.2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4. | 1280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8.8 | 1700 | 1365 | 0 |
| Standard_B4ms | 4 | 16 | 17.6 | 2400 | 2731 | 0 |
| Standard_B8ms | 8 | 32 | 35.2 | 3100 | 5461 | 0 |
| Standard_B12ms | 12 | 48 | 52,8 | 3800 | 8193 | 0 |
| Standard_B16ms | 16 | 64 | 70.4 | 4300 | 10923 | 0 |
| Standard_B20ms | 20 | 80 | 88 | 5000 | 13653 | 0 |
Uso general
Las especificaciones detalladas de los tipos de servidor disponibles son las siguientes para el nivel de servicio De uso general
| Tamaño de proceso | Núcleos virtuales | Tamaño de memoria física (GiB) | Tamaño total de memoria (GiB) | IOPS máximas admitidas | Conexiones máximas | GiB de almacenamiento temporal (SSD) |
|---|---|---|---|---|---|---|
| Standard_D2ads_v5 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D2ds_v4 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D4ads_v5 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D4ds_v4 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D8ads_v5 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D8ds_v4 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D16ads_v5 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D16ds_v4 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D32ads_v5 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D32ds_v4 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D48ads_v5 | 48 | 192 | 264 | 20000 | 32 768 | 1290 |
| Standard_D48ds_v4 | 48 | 192 | 264 | 20000 | 32 768 | 1290 |
| Standard_D64ads_v5 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
| Standard_D64ds_v4 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
Crítico para la empresa
Las especificaciones detalladas de los tipos de servidor disponibles son las siguientes para el nivel de servicio Crítico para la empresa.
| Tamaño de proceso | Núcleos virtuales | Tamaño de memoria física (GiB) | Tamaño total de memoria (GiB) | IOPS máximas admitidas | Conexiones máximas | GiB de almacenamiento temporal (SSD) |
|---|---|---|---|---|---|---|
| Standard_E2ds_v4 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E2ads_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v4 | 4 | 32 | 44 | 10 000 | 5461 | 75 |
| Standard_E4ads_v5 | 4 | 32 | 44 | 10 000 | 5461 | 75 |
| Standard_E8ds_v4 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E8ads_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v4 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E16ads_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v4 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E20ads_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v4 | 32 | 256 | 352 | 38 000 | 43691 | 604 |
| Standard_E32ads_v5 | 32 | 256 | 352 | 38 000 | 43691 | 604 |
| Standard_E48ds_v4 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E48ads_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v4 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E64ads_v5 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E80ds_v4 | 80 | 504 | 693 | 72 000 | 86016 | 1224 |
| Standard_E2ds_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v5 | 4 | 32 | 44 | 10 000 | 5461 | 75 |
| Standard_E8ds_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v5 | 32 | 256 | 352 | 38 000 | 43691 | 604 |
| Standard_E48ds_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v5 | 64 | 512 | 704 | 64000 | 87383 | 1208 |
| Standard_E96ds_v5 | 96 | 672 | 924 | 80000 | 100000 | 2004 |
Resistencia de zona predeterminada en Azure Database for MySQL(nivel Crítico para la empresa de servidor flexible): a partir de mediados de diciembre de 2024, todos los nuevos servidores aprovisionados en el nivel Crítico para la empresa de servidor flexible de Azure Database for MySQL incluirán resistencia de zona integrada, sin costo adicional. Esto significa que tanto los archivos de datos como los de registro se almacenarán automáticamente en ZRS, lo que garantiza una rápida recuperación en caso de interrupciones zonales. Aunque no esté la alta disponibilidad habilitada, se beneficiará de una protección sin problemas gracias a las copias de seguridad con redundancia de zona. Introducción a la continuidad empresarial con el Servidor flexible de Azure Database for MySQL.
Administración de memoria en el servidor flexible de Azure Database for MySQL
En MySQL, la memoria desempeña un papel fundamental en varias operaciones, incluido el procesamiento de consultas y el almacenamiento en caché. El servidor flexible de Azure Database for MySQL optimiza la asignación de memoria para el proceso del servidor MySQL (mysqld), lo que garantiza que recibe recursos de memoria suficientes para un procesamiento eficaz de consultas, almacenamiento en caché, administración de conexiones de cliente y control de subprocesos. Obtenga más información sobre cómo MySQL usa la memoria.
Tamaño de memoria física (GB)
El tamaño de memoria física (GB) de la tabla siguiente representa la memoria de acceso aleatorio (RAM) disponible en gigabytes (GB) en el servidor flexible de Azure Database for MySQL.
Tamaño total de memoria (GB)
El servidor flexible de Azure Database for MySQL proporciona un tamaño de memoria total (GB). Esto representa la memoria total disponible para el servidor, que es una combinación de memoria física y una cantidad establecida de componente SSD de almacenamiento temporal. Esta vista unificada está diseñada para simplificar la administración de recursos, lo que permite centrarse solo en la memoria total disponible para el proceso de Azure MySQL Server (mysqld). La métrica Porcentaje de memoria (memory_percent) representa el porcentaje de memoria ocupada por el proceso de servidor de Azure MySQL (mysqld). Esta métrica se calcula a partir del Tamaño total de memoria (GB). Por ejemplo, cuando la métrica Porcentaje de memoria muestra un valor de 60, significa que el proceso del servidor de Azure MySQL usa 60 % del tamaño de memoria total (GB) disponible en el servidor flexible de Azure Database for MySQL.
MySQL Server (mysqld)
El proceso del servidor MySQL de Azure, mysqld, es el motor principal para las operaciones de base de datos. Al iniciarse, inicializa los componentes totales, como el grupo de búferes de InnoDB y la memoria caché de subprocesos, usando la memoria basada en las demandas de configuración y carga de trabajo. Por ejemplo, el grupo de búferes de InnoDB almacena en caché los datos y índices a los que se accede con frecuencia para mejorar la velocidad de ejecución de las consultas, mientras que la caché de subprocesos administra los subprocesos de conexión de cliente. Más información.
Motor de almacenamiento de InnoDB
Como motor de almacenamiento predeterminado de MySQL, InnoDB usa memoria para almacenar en caché datos a los que se accede con frecuencia y administrar estructuras internas como el grupo de búferes de innodb y búfer de registro. Grupo de búferes de InnoDB contiene datos de tabla e índices en memoria para minimizar la E/S de disco, lo que mejora el rendimiento. El parámetro InnoDB Buffer Pool Size (Tamaño del grupo de búferes de InnoDB) se calcula en función del tamaño de memoria física (GB) disponible en el servidor. Obtenga más información sobre los tamaños del grupo de búferes de InnoDB disponible en el servidor flexible de Azure Database for MySQL.
Subprocesos
Las conexiones de cliente se administran a través de subprocesos dedicados administrados por el administrador de conexiones. Estos subprocesos controlan la autenticación, la ejecución de consultas y la recuperación de resultados para las interacciones del cliente. Más información.
Para obtener más detalles sobre la serie de proceso disponible, consulte la documentación de máquinas virtuales de Azure para tamaños de máquina virtual ampliables de la serie B, Uso general serie Dadsv5serie Ddsv4y Crítico para la empresa Edsv4/serie Edsv5/serie Eadsv5.
Limitaciones de rendimiento de las instancias de series ampliables
Nota:
Para tamaños de máquina virtual ampliables de la serie B, si la máquina virtual se inicia o se detiene o se reinicia, es posible que se pierdan los créditos. Para más información, consulte Tamaños de las máquinas virtuales ampliables serie B.
El nivel de proceso ampliable está diseñado para proporcionar una solución rentable para cargas de trabajo que no requieren una CPU completa continua continuamente. Este nivel es ideal para cargas de trabajo que no son de producción, como entornos de desarrollo, almacenamiento provisional o pruebas. La característica única del nivel de proceso ampliable es su capacidad de "ráfaga", es decir, usar más que su rendimiento de CPU de línea base usando hasta el 100 % de la vCPU cuando la carga de trabajo lo requiere. Esto es posible mediante un modelo de crédito de CPU, lo que permite a las instancias de la serie B acumular "créditos de CPU" durante períodos de uso bajo de CPU. Estos créditos pueden usarse durante períodos de uso elevado de CPU, lo que permite que la instancia se expanda por encima de su rendimiento de CPU base.
Sin embargo, es importante tener en cuenta que una vez que una instancia ampliable agota sus créditos de CPU, funciona en su rendimiento de CPU base. Por ejemplo, el rendimiento base de la CPU de un Standard_B1ms es del 20 % es decir, 0,2 núcleos virtuales. Supongamos que el servidor de capa ampliable ejecuta una carga de trabajo que requiere más rendimiento de CPU que el nivel base y ha agotado sus créditos de CPU. En ese caso, el servidor podría experimentar limitaciones de rendimiento y, finalmente, podría afectar a varias operaciones del sistema, como Detener/Iniciar/Reiniciar para el servidor.
Nota:
En el caso de los servidores de tamaños de máquina virtual ampliables de la serie B, como Standard_B1s/Standard_B1ms/Standard_B2s, su tamaño de memoria de host relativamente menor puede provocar bloqueos (memoria insuficiente) en cargas de trabajo continuas, incluso si la métrica de memory_percent no ha alcanzado el 100 %.
Debido a esta limitación, es posible que el servidor encuentre problemas de conectividad y que las operaciones del sistema se vean afectadas. En tales situaciones, el curso de acción recomendado es pausar la carga de trabajo en el servidor para acumular créditos según el modelo de banca de crédito de la serie B o considerar la posibilidad de escalar el servidor a niveles superiores, como los niveles de uso general o críticos para la empresa.
Por lo tanto, aunque el nivel de proceso ampliable ofrece importantes ventajas de costo y flexibilidad para determinados tipos de cargas de trabajo, no se recomienda para cargas de trabajo de producción que requieran un rendimiento coherente de la CPU. El nivel Ampliable no admite la funcionalidad de crear las réplicas de lectura en Azure Database for MySQL: servidor flexible y conceptos de alta disponibilidad en la característica Azure Database for MySQL: servidor flexible. Otros niveles de proceso, como el uso general o crítico para la empresa, son más adecuados para estas cargas de trabajo y características.
Para más información sobre el modelo de crédito de CPU de la serie B de Azure, consulte tamaños de máquina virtual ampliables de la serie B y modelo de crédito de CPU de la serie B.
Supervisión de créditos de CPU en el nivel ampliable
La supervisión del saldo de crédito de CPU es fundamental para mantener un rendimiento óptimo en el nivel de proceso ampliable. El servidor flexible de Azure Database for MySQL proporciona dos métricas clave relacionadas con los créditos de CPU. El umbral ideal para desencadenar una alerta depende de los requisitos de rendimiento y carga de trabajo.
Supervisión de Azure Database for MySQL: servidor flexible: esta métrica indica el número de créditos de CPU consumidos por la instancia. La supervisión de esta métrica puede ayudarle a comprender los patrones de uso de CPU de la instancia y a administrar su rendimiento de forma eficaz.
Supervisión de Azure Database for MySQL: servidor flexible: esta métrica muestra el número de créditos de CPU restantes para la instancia. La supervisión de esta métrica puede ayudar a evitar que la instancia se degrada en el rendimiento debido al agotamiento de sus créditos de CPU. Si la métrica Crédito de CPU restante cae por debajo de un determinado nivel (por ejemplo, menos del 30 % del total de créditos disponibles), esto indicaría que la instancia está en riesgo de agotar sus créditos de CPU si la carga de CPU actual continúa.
Para obtener más información sobre cómo configurar alertas en métricas, consulte esta guía.
Storage
El almacenamiento que aprovisiona es la capacidad de almacenamiento disponible para el servidor flexible. El almacenamiento se usa para los archivos de base de datos, los archivos temporales, los registros de transacciones y los registros del servidor MySQL. En el caso de los niveles de servicio de uso general y ampliable, el intervalo de almacenamiento abarca desde un mínimo de 20 GiB hasta un máximo de 16 TiB. Por el contrario, la compatibilidad con el almacenamiento amplía hasta 32 TiB para el nivel de servicio Crítico para la empresa. En todos los niveles de servicio, el almacenamiento se escala en incrementos de 1 GiB y se puede escalar verticalmente después de crear el servidor.
Nota:
El almacenamiento solo se puede escalar verticalmente, no reducir.
Puede supervisar el consumo de almacenamiento en el Azure Portal (con Azure Monitor) mediante el límite de almacenamiento, el porcentaje de almacenamiento y las métricas usadas en el almacenamiento. Consulte el artículo Supervisión para obtener información sobre las métricas.
Alcance el límite de almacenamiento
Cuando el almacenamiento consumido en el servidor está cerca de alcanzar el límite aprovisionado, el servidor se pone en modo de solo lectura para proteger las escrituras perdidas en el servidor. Los servidores con un almacenamiento aprovisionado menor o igual a 100 GiB se marcan como de solo lectura si el almacenamiento disponible es inferior al 5 % del tamaño del almacenamiento aprovisionado. Los servidores con más de 100 GiB aprovisionados se marcan como de solo lectura cuando el almacenamiento libre es inferior a 5 GiB.
Por ejemplo, si ha aprovisionado 110 GiB de almacenamiento y el uso real supera los 105 GiB, el servidor se marca como de solo lectura. También, si ha aprovisionado 5 GiB de almacenamiento, el servidor se marca como de solo lectura cuando quedan menos de 256 MB de almacenamiento disponible.
Mientras el servicio intenta hacer que el servidor sea de solo lectura, se bloquean todas las nuevas solicitudes de transacción de escritura y se siguen ejecutando las transacciones activas existentes. Cuando el servidor está establecido en de solo lectura, se producirá un error en todas las operaciones de escritura y confirmaciones de transacciones posteriores, pero las consultas de lectura seguirán funcionando sin interrupciones.
Para sacar el servidor del modo de solo lectura, debe aumentar el almacenamiento aprovisionado en el servidor. Esto puede hacerse mediante Azure Portal o la CLI de Azure. Después del aumento, el servidor estará listo para aceptar las transacciones de escritura de nuevo.
Recomendamos que configure una alerta que le envíe una notificación cada vez que su almacenamiento en servidor esté cerca del umbral para que pueda evitar entrar en el estado de solo lectura. Para obtener más información, consulte cómo configurar una alerta en la documentación sobre alertas.
Crecimiento automático del almacenamiento
El crecimiento automático del almacenamiento impide que el servidor se quede sin almacenamiento y se vuelva de solo lectura. Si el crecimiento automático del almacenamiento está habilitado, el almacenamiento crece automáticamente sin afectar a la carga de trabajo. El crecimiento automático de almacenamiento está habilitado de forma predeterminada para todas las nuevas creaciones de servidor. En cuanto a los servidores con menos de 100 GB de almacenamiento aprovisionado, el tamaño del almacenamiento aprovisionado se incrementa en 5 GB cuando el almacenamiento disponible es inferior al 10 % del almacenamiento aprovisionado. En los servidores con más de 100 GB de almacenamiento aprovisionado, el tamaño del almacenamiento aprovisionado se incrementa en un 5 % cuando el espacio de almacenamiento disponible está por debajo de 10 GB del tamaño del almacenamiento aprovisionado. Se aplican los límites máximos de almacenamiento según lo especificado anteriormente. Actualice la instancia del servidor para ver el almacenamiento actualizado aprovisionado en Configuración en la página Proceso y almacenamiento.
Por ejemplo, si ha aprovisionado 1000 GB de almacenamiento y el uso real supera los 990 GB, el tamaño de almacenamiento del servidor aumenta a 1050 GB. De forma alternativa, si ha aprovisionado 20 GB de almacenamiento, el tamaño de almacenamiento se incrementa a 25 GB cuando quedan libres menos de 2 GB de almacenamiento.
Recuerde que el almacenamiento una vez escalado automático no se puede reducir verticalmente.
Nota:
El crecimiento automático de almacenamiento está habilitado de forma predeterminada para un servidor configurado de alta disponibilidad y no se puede deshabilitar.
E/S
El servidor flexible de Azure Database for MySQL admite IOPS aprovisionados previamente y IOPS de escalabilidad automática. IOPS de almacenamiento en Azure Database for MySQL: servidor flexible El número mínimo de IOPS es de 360 en todos los tamaños de proceso y el tamaño máximo de proceso viene determinado por el tamaño de proceso seleccionado. Para obtener más información sobre el número máximo de IOPS por tamaño de proceso consulte la tabla.
Importante
**El número mínimo de IOPS es de 360 en todos los tamaños de proceso
**El número de IOPS máximo viene determinado por el tamaño de proceso seleccionado.
Puede supervisar el consumo de E/S en Azure Portal (con Azure Monitor) mediante la métrica Supervisión de Azure Database for MySQL: servidor flexible. Debe escalar el proceso del servidor si necesita más IOPS que el número máximo de IOPS en función del proceso.
IOPS aprovisionadas previamente
El servidor flexible de Azure Database for MySQL ofrece IOPS aprovisionadas previamente, lo que le permite asignar un número específico de IOPS a la instancia de servidor flexible de Azure Database for MySQL. Esta configuración garantiza un rendimiento coherente y predecible para las cargas de trabajo. Con las IOPS aprovisionadas previamente, puede definir un límite de IOPS específico para el volumen de almacenamiento, lo que garantiza la capacidad de controlar algunas solicitudes por segundo. Esto da como resultado un nivel de rendimiento confiable y seguro. Las IOPS aprovisionadas previamente le permiten aprovisionar IOPS adicionales por encima del límite de IOPS. Con esta característica puede aumentar o disminuir el número de IOPS aprovisionadas en función de los requisitos de la carga de trabajo en cualquier momento.
IOPS de escalado automático
La base de Azure Database for MySQL servidor flexible es su capacidad para lograr el mejor rendimiento para las cargas de trabajo de nivel 1. Esto se puede mejorar al permitir que el servidor escale automáticamente el rendimiento de sus servidores de bases de datos (E/S) sin problemas en función de las necesidades de la carga de trabajo. Esta característica de participación permite a los usuarios escalar IOPS a petición sin tener que aprovisionar previamente una determinada cantidad de E/S por segundo. Con las IOPS de escalabilidad automática habilitadas, ahora puede disfrutar de la administración de E/S sin preocupaciones en el servidor flexible de Azure Database for MySQL, ya que el servidor escala o reduce verticalmente las E/S automáticamente en función de las necesidades de carga de trabajo. La escalabilidad automática de IOPS se escala verticalmente automáticamente hasta el "IOPS máximo admitido" para cada nivel de servicio y tamaño de proceso, tal como se especifica en la documentación de los niveles de servicio. Esto garantiza un rendimiento óptimo sin necesidad de realizar esfuerzos de escalado manual.
Con la IOPS de escalabilidad automática, solo paga por la E/S que usa el servidor y ya no necesita aprovisionar y pagar los recursos que no están completamente usando, ahorrando tiempo y dinero. Además, las aplicaciones críticas de nivel 1 pueden lograr un rendimiento coherente haciendo que la E/S adicional esté disponible para la carga de trabajo en cualquier momento. La IOPS de escala automática elimina la administración necesaria para proporcionar el mejor rendimiento al menor para los clientes del servidor flexible de Azure Database for MySQL.
escalado dinámico: el escalado automático de IOPS ajusta dinámicamente el límite de IOPS del servidor de bases de datos en función de la demanda real de la carga de trabajo. Esto garantiza un rendimiento óptimo sin intervención manual ni configuración.
control de picos de carga de trabajo: IOPS de escalabilidad automática permite que la base de datos controle sin problemas los picos o fluctuaciones de la carga de trabajo sin poner en peligro el rendimiento de las aplicaciones. Esta característica garantiza una capacidad de respuesta uniforme incluso durante los períodos de uso máximo.
ahorro de costos: a diferencia de las IOPS aprovisionadas previamente, que especifica un límite fijo de IOPS y se paga por independientemente del uso, IOPS de escalado automático le permite pagar solo por el número de operaciones de E/S que consume.
Backup
El servicio realiza automáticamente una copia de seguridad del servidor. Puede seleccionar un período de retención de 1 a 35 días. Obtenga más información sobre las copias de seguridad en el artículo sobre los conceptos de copia de seguridad y restauración.
Escalado de recursos
Después de crear el servidor, puede cambiar de forma independiente el nivel de proceso, el tamaño de proceso (núcleos virtuales y memoria), la cantidad de almacenamiento y el período de retención de copia de seguridad. El tamaño de proceso se puede escalar o reducir verticalmente y el período de retención de copia de seguridad se puede escalar o reducir verticalmente de 1 a 35 días. El tamaño de almacenamiento solo se puede aumentar. El escalado de los recursos se puede realizar a través del portal o la CLI de Azure.
Nota:
El tamaño de almacenamiento solo se puede aumentar. Tras aplicar el aumento del tamaño de almacenamiento, no puede volver a otro más pequeño.
Al cambiar el nivel de proceso o el tamaño de proceso, el servidor debe reiniciarse para que el nuevo tipo de servidor surta efecto. Cuando el sistema pasa al nuevo servidor, no se pueden establecer nuevas conexiones y se revierten todas las transacciones no confirmadas. Esta ventana varía, pero en la mayoría de los casos, es entre 60 y 120 segundos.
El escalado del almacenamiento y el cambio del período de retención de la copia de seguridad son operaciones en línea y no requieren el reinicio de un servidor.
Precio
Para conocer la información más actualizada sobre precios, consulte la página de precios del servicio. Para ver el coste de la configuración deseada, en Azure Portal se muestra el coste mensual en la pestaña Proceso + Almacenamiento según las opciones que seleccione. Si no tiene una suscripción de Azure, puede usar la calculadora de precios de Azure para obtener un precio estimado. En el sitio web Calculadora de precios de Azure, seleccione Agregar elementos, expanda la categoría Bases de datos y elija Azure Database for MySQL y Servidor flexible como tipo de implementación para personalizar las opciones.
Si desea optimizar el costo del servidor, puede tener en cuenta las siguientes sugerencias:
- Reduzca verticalmente el nivel o el tamaño de proceso (núcleos virtuales) si el proceso está infrautilizado.
- Le recomendamos que cambie al nivel de proceso flexible si la carga de trabajo no necesita la capacidad de proceso completa de forma continua de los niveles De uso general y Crítico para la empresa.
- Detenga el servidor cuando no esté en uso.
- Reduzca el período de retención de la copia de seguridad si no se requiere una retención más larga de la copia de seguridad.