Compute and storage options in Azure Database for MySQL - Flexible Server (Preview)

APPLIES TO: Azure Database for MySQL - Flexible Server

Important

Azure Database for MySQL - Flexible Server is currently in public preview.

You can create an Azure Database for MySQL Flexible Server in one of three different compute tiers: Burstable, General Purpose, and Memory Optimized. The compute tiers are differentiated by the underlying VM SKU used B-series, D-series, and E-series. The choice of compute tier and size determines the memory and vCores available on the server. The same storage technology is used across all compute tiers. All resources are provisioned at the MySQL server level. A server can have one or many databases.

Resource / Tier Burstable General Purpose Memory Optimized
VM series B-series Ddsv4-series Edsv4-series
vCores 1, 2 2, 4, 8, 16, 32, 48, 64 2, 4, 8, 16, 32, 48, 64
Memory per vCore Variable 4 GiB 8 GiB *
Storage size 20 GiB to 16 TiB 20 GiB to 16 TiB 20 GiB to 16 TiB
Database backup retention period 1 to 35 days 1 to 35 days 1 to 35 days

* With the exception of E64ds_v4 (Memory Optimized) SKU, which has 504 GB of memory

To choose a compute tier, use the following table as a starting point.

Compute tier Target workloads
Burstable Best for workloads that don’t need the full CPU continuously.
General Purpose Most business workloads that require balanced compute and memory with scalable I/O throughput. Examples include servers for hosting web and mobile apps and other enterprise applications.
Memory Optimized High-performance database workloads that require in-memory performance for faster transaction processing and higher concurrency. Examples include servers for processing real-time data and high-performance transactional or analytical apps.

After you create a server, the compute tier, compute size, and storage size changed. Compute scaling requires a restart and takes between 60-120 seconds, while storage scaling does not require restart. You also can independently adjust the backup retention period up or down. For more information, see the Scale resources section.

Compute tiers, size, and server types

Compute resources can be selected based on the tier and size. This determines the vCores and memory size. vCores represent the logical CPU of the underlying hardware.

The detailed specifications of the available server types are as follows:

Compute size vCores Memory Size (GiB) Max Supported IOPS Max Supported I/O bandwidth (MBps) Max Connections
Burstable
Standard_B1s 1 1 320 10 171
Standard_B1ms 1 2 640 10 341
Standard_B2s 2 4 1280 15 683
General Purpose
Standard_D2ds_v4 2 8 3200 48 1365
Standard_D4ds_v4 4 16 6400 96 2731
Standard_D8ds_v4 8 32 12800 192 5461
Standard_D16ds_v4 16 64 20000 384 10923
Standard_D32ds_v4 32 128 20000 768 21845
Standard_D48ds_v4 48 192 20000 1152 32768
Standard_D64ds_v4 64 256 20000 1200 43691
Memory Optimized
Standard_E2ds_v4 2 16 3200 48 2731
Standard_E4ds_v4 4 32 6400 96 5461
Standard_E8ds_v4 8 64 12800 192 10923
Standard_E16ds_v4 16 128 20000 384 21845
Standard_E32ds_v4 32 256 20000 768 43691
Standard_E48ds_v4 48 384 20000 1152 65536
Standard_E64ds_v4 64 504 20000 1200 86016

To get more details about the compute series available, refer to Azure VM documentation for Burstable (B-series), General Purpose (Ddsv4-series), and Memory Optimized (Edsv4-series).

Note

For Burstable (B-series) compute tier if the VM is started/stopped or restarted, the credits may be lost. For more information, see Burstable (B-Series) FAQ.

Storage

The storage you provision is the amount of storage capacity available to your flexible server. Storage is used for the database files, temporary files, transaction logs, and the MySQL server logs. In all compute tiers, the minimum storage supported is 20 GiB and maximum is 16 TiB. Storage is scaled in 1 GiB increments and can be scaled up after the server is created.

Note

Storage can only be scaled up, not down.

You can monitor your storage consumption in the Azure portal (with Azure Monitor) using the storage limit, storage percentage, and storage used metrics. Refer to the monitoring article to learn about metrics.

Reaching the storage limit

When storage consumed on the server is close to reaching the provisioned limit, the server is put to read-only mode to protect any lost writes on the server. Servers with less than equal to 100 GiB provisioned storage are marked read-only if the free storage is less than 5% of the provisioned storage size. Servers with more than 100 GiB provisioned storage are marked read only when the free storage is less than 5 GiB.

For example, if you have provisioned 110 GiB of storage, and the actual utilization goes over 105 GiB, the server is marked read-only. Alternatively, if you have provisioned 5 GiB of storage, the server is marked read-only when the free storage reaches less than 256 MB.

While the service attempts to make the server read-only, all new write transaction requests are blocked and existing active transactions will continue to execute. When the server is set to read-only, all subsequent write operations and transaction commits fail. Read queries will continue to work uninterrupted.

To get the server out of read-only mode, you should increase the provisioned storage on the server. This can be done using the Azure portal or Azure CLI. Once increased, the server will be ready to accept write transactions again.

We recommend that you set up an alert to notify you when your server storage is approaching the threshold so you can avoid getting into the read-only state. Refer to the monitoring article to learn about metrics available.

We recommend that you set up an alert to notify you when your server storage is approaching the threshold so you can avoid getting into the read-only state. For more information, see the documentation on alert documentation how to set up an alert.

Storage auto-grow

Storage auto-grow prevents your server from running out of storage and becoming read-only. If storage auto-grow is enabled, the storage automatically grows without impacting the workload. Storage auto-grow is enabled by default for all new server creates. For servers with less than equal to 100 GB provisioned storage, the provisioned storage size is increased by 5 GB when the free storage is below 10% of the provisioned storage. For servers with more than 100 GB of provisioned storage, the provisioned storage size is increased by 5% when the free storage space is below 10 GB of the provisioned storage size. Maximum storage limits as specified above apply.

For example, if you have provisioned 1000 GB of storage, and the actual utilization goes over 990 GB, the server storage size is increased to 1050 GB. Alternatively, if you have provisioned 10 GB of storage, the storage size is increase to 15 GB when less than 1 GB of storage is free.

Remember that storage can only be scaled up, not down

IOPS

Azure Database for MySQL – Flexible Server supports the provisioning of additional IOPS. This feature enables you to provision additional IOPS above the complimentary IOPS limit. Using this feature, you can increase or decrease the number of IOPS provisioned based on your workload requirements at any time.

The minimum IOPS is 360 across all compute sizes and the maximum IOPS is determined by the selected compute size. In preview, the maximum IOPS supported is 20,000 IOPS.

To learn more about the maximum IOPS per compute size is shown below:

Compute size Maximum IOPS
Burstable
Standard_B1s 320
Standard_B1ms 640
Standard_B2s 1280
General Purpose
Standard_D2ds_v4 3200
Standard_D4ds_v4 6400
Standard_D8ds_v4 12800
Standard_D16ds_v4 20000
Standard_D32ds_v4 20000
Standard_D48ds_v4 20000
Standard_D64ds_v4 20000
Memory Optimized
Standard_E2ds_v4 3200
Standard_E4ds_v4 6400
Standard_ E8ds_v4 12800
Standard_ E16ds_v4 20000
Standard_E32ds_v4 20000
Standard_E48ds_v4 20000
Standard_E64ds_v4 20000

The maximum IOPS is dependent on the maximum available IOPS per compute size. Refer to the column Max uncached disk throughput: IOPS/MBps in the B-series, Ddsv4-series, and Edsv4-series documentation.

Important

Complimentary IOPS are equal to MINIMUM("Max uncached disk throughput: IOPS/MBps" of compute size, 300 + storage provisioned in GiB * 3)
Minimum IOPS is 360 across all compute sizes
Maximum IOPS is determined by the selected compute size. In preview, the maximum IOPS supported is 20,000 IOPS.

You can monitor your I/O consumption in the Azure portal (with Azure Monitor) using IO percent metric. If you need more IOPS then the max IOPS based on compute then you need to scale your server's compute.

Backup

The service automatically takes backups of your server. You can select a retention period from a range of 1 to 35 days. Learn more about backups in the backup and restore concepts article.

Scale resources

After you create your server, you can independently change the compute tier, compute size (vCores and memory), and the amount of storage, and the backup retention period. The compute size can be scaled up or down. The backup retention period can be scaled up or down from 1 to 35 days. The storage size can only be increased. Scaling of the resources can be done through the portal or Azure CLI.

Note

The storage size can only be increased. You cannot go back to a smaller storage size after the increase.

When you change the compute tier or compute size, the server is restarted for the new server type to take effect. During the moment when the system switches over to the new server, no new connections can be established, and all uncommitted transactions are rolled back. This window varies, but in most cases, is between 60-120 seconds.

Scaling storage and changing the backup retention period are online operations and do not require a server restart.

Pricing

For the most up-to-date pricing information, see the service pricing page. To see the cost for the configuration you want, the Azure portal shows the monthly cost on the Compute + storage tab based on the options you select. If you don't have an Azure subscription, you can use the Azure pricing calculator to get an estimated price. On the Azure pricing calculator website, select Add items, expand the Databases category, choose Azure Database for MySQL, and Flexible Server as the deployment type to customize the options.

If you would like to optimize server cost, you can consider following tips:

  • Scale down your compute tier or compute size (vCores) if compute is underutilized.
  • Consider switching to the Burstable compute tier if your workload doesn't need the full compute capacity continuously from the General Purpose and Memory Optimized tiers.
  • Stop the server when not in use.
  • Reduce the backup retention period if a longer retention of backup is not required.

Next steps