Compartir a través de


Azure Database for MySQL: niveles de servidor flexible

SE APLICA A: Azure Database for MySQL - Servidor flexible

Puede crear una instancia del Servidor flexible de Azure Database for MySQL en uno de los tres niveles de servicio: Ampliable, Uso general y Crítico para la empresa. La SKU de máquina virtual 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. La tecnología de almacenamiento exacta se usa 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 máquinas virtualese ampliable de la serie B Serie Dadsv5Serie Ddsv4 Edsv4/Serie Edsv5*/Serie Eadsv5
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 copia 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 funciona mejor entre otras series de máquinas virtuales con respecto 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 tabla siguiente como punto de partida.

Nivel de proceso Carga de trabajo objetivo
Flexible Lo mejor para las cargas de trabajo que no necesitan continuamente la CPU completa.
De uso general La mayoría de las cargas de trabajo empresariales requieren una computación equilibrada y memoria con 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 un rendimiento en memoria para un procesamiento de transacciones más rápido y una mayor simultaneidad. Algunos ejemplos son los servidores para procesar datos en tiempo real y aplicaciones transaccionales o analíticas 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 ajustar de forma independiente el período de retención de copia de seguridad hacia arriba o hacia abajo. Consulte la sección Escalado 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 cinco mil 13653 0

Nota: El nivel de proceso ampliable está diseñado para cargas de trabajo que no son de producción, como entornos de desarrollo, ensayo o pruebas, y por lo tanto no cumple los requisitos para la compatibilidad con 24/7 o el análisis de causa principal (RCA).

De 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 48000 32768 1290
Standard_D48ds_v4 48 192 264 48000 32768 1290
Standard_D64ads_v5 64 256 352 48000 43691 1720
Standard_D64ds_v4 64 256 352 48000 43691 1720
Standard_D96ds_v5 96 384 528 48000 65536 2580

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 cinco mil 2731 37
Standard_E2ads_v5, Standard_E2ds_v5 2 16 22 cinco mil 2731 37
Standard_E4ds_v4 4 32 44 10000 5461 75
Standard_E4ads_v5, Standard_E4ds_v5 4 32 44 10000 5461 75
Standard_E8ds_v4 8 64 88 18000 10923 151
Standard_E8ads_v5, Standard_E8ds_v5 8 64 88 18000 10923 151
Standard_E16ds_v4 16 128 176 28000 21845 302
Standard_E16ads_v5, Standard_E16ds_v5 16 128 176 28000 21845 302
Standard_E20ds_v4 20 160 220 28000 27306 377
Standard_E20ads_v5, Standard_E20ds_v5 20 160 220 28000 27306 377
Standard_E32ds_v4 32 256 352 38000 43691 604
Standard_E32ads_v5, Standard_E32ds_v5 32 256 352 38000 43691 604
Standard_E48ds_v4 48 384 528 48000 65536 906
Standard_E48ads_v5, Standard_E48ds_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_E64ds_v5 64 512 704 64000 87383 1208
Standard_E80ids_v4 80 504 693 72 000 86016 1224
Standard_E96ads_v5 96 672 924 80000 100000 2004

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 total de memoria (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 de operaciones de base de datos principal. 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é los datos a los que se accede con frecuencia y administrar estructuras internas, como el grupo de búferes de innodb y el búfer de registro. El grupo de búferes de InnoDB contiene datos de tabla e índices en memoria para minimizar la E/S del 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 las series de cómputo disponibles, consulte la documentación de Azure sobre tamaños de máquina virtual ampliables de la serie B, las series de uso general Dadsv5 y Ddsv4, y las series críticas para el negocio Edsv4, /, y Eadsv5.

Limitaciones de rendimiento de las instancias de series ampliables

Nota

En el caso de los 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 pasarse 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 Stop/Start/Restart 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ítico 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 los tamaños de máquina virtual ampliables de la serie B y el 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.

Almacenamiento

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 de 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 de menos de 100 GiB se marcan como de solo lectura si el almacenamiento libre es inferior al 5 % del tamaño de 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. Como alternativa, si ha aprovisionado 5 GiB de almacenamiento, el servidor se marca como de solo lectura cuando el almacenamiento libre alcanza menos de 256 MB.

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 se puede hacer mediante Azure Portal o la CLI de Azure. Después del aumento, el servidor estará listo para aceptar las transacciones de escritura de nuevo.

Se recomienda activar el crecimiento automático del almacenamiento o configurar una alerta para notificarle cuando el almacenamiento del servidor se aproxima al umbral para evitar entrar en el estado de solo lectura. Para obtener más información, consulte la documentación sobre cómo configurar una alerta.

Crecimiento automático del almacenamiento

El crecimiento automático del almacenamiento impide que el servidor se quede sin almacenamiento y se convierta en 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 el caso de los servidores con menos de 100 GB de almacenamiento aprovisionado, el tamaño de almacenamiento aprovisionado aumenta en 5 GB cuando el almacenamiento libre está por debajo del 10 % del almacenamiento aprovisionado. En el caso de los servidores con más de 100 GB de almacenamiento aprovisionado, el tamaño de almacenamiento aprovisionado aumenta en un 5 % cuando el espacio de almacenamiento disponible está por debajo de 10 GB del tamaño de almacenamiento aprovisionado. Se aplican los límites máximos de almacenamiento especificados 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 los servidores habilitados para registros acelerados y no se puede deshabilitar.

IOPS

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 La IOPS mínima es de 360 en todos los tamaños de proceso y la IOPS máxima viene determinada por el tamaño de proceso seleccionado. Para más información sobre el tamaño máximo de IOPS por proceso, consulte la tabla.

Importante

**Las IOPS mínimas son 360 en todos los tamaños de proceso
**El tamaño de proceso seleccionado determina el número máximo de IOPS.

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 del 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. El resultado es un nivel de rendimiento fiable y garantizado. 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 aprovisionados en función de los requisitos de carga de trabajo en cualquier momento.

IOPS de escalabilidad automática

La piedra angular del servidor flexible de Azure Database for MySQL es su capacidad de 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 la función de IOPS de escalado automático habilitada, ahora puede disfrutar de una gestión de IOPS sin preocupaciones en el Servidor Flexible de Azure Database for MySQL, ya que el servidor escala las IOPS hacia arriba o hacia abajo automáticamente según las necesidades de carga de trabajo. El escalado automático de IOPS ajusta automáticamente hasta el "IOPS máximo admitido" para cada nivel de servicio y tamaño de computación, según lo especificado 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. El escalado automático de IOPS elimina la administración necesaria para proporcionar el mejor rendimiento al menor costo para los clientes de Azure Database for MySQL Flexible Server.

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: la IOPS de escalado automático permite a la base de datos controlar sin problemas los picos de carga de trabajo o las fluctuaciones sin poner en peligro el rendimiento de las aplicaciones. Esta característica garantiza una capacidad de respuesta coherente 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, la IOPS de escalado automático le permite pagar solo por el número de operaciones de E/S que consume.

Copia de seguridad

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 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. No puede volver a un tamaño de almacenamiento menor después del aumento.

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 copia de seguridad son operaciones en línea y no requieren un reinicio del servidor.

Precio

Para conocer la información más actualizada sobre precios, consulte la página de precios del servicio. Para ver el costo de la configuración que desea, Azure Portal muestra el costo mensual en la pestaña Proceso y almacenamiento en función de 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 de la calculadora de precios de Azure , seleccione Agregar elementos, expanda la categoría Bases de datos , 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 copia de seguridad si no se requiere una retención más larga de la copia de seguridad.