Thank you all for an overwhelming response to our Flexible Server release! Your continued feedback is critical to ensure that we invest in the features that are most important for you. Today, I am excited to share some exciting new features that we released last week, driven by your feedback.
MySQL 8.0.21 now available in Flexible Server
With MySQL v8.0, the MySQL Server Team continues to add exciting new features in every minor version release, and it's sometimes difficult to keep up (which is a good problem to have :smiling_face_with_smiling_eyes:). Immediately after Flexible Server release, many of you requested that we prioritize MySQL 8.0 ASAP to unblock your to move Flexible Server, and some of you were looking for MySQL 8.0.20 or later to leverage some exciting improvements from the community. Today, we're happy to share that MySQL 8.0.21 is now available in Flexible Server in all major Azure regions. You can use the Azure portal, the Azure CLI, or Azure Resource Manager templates to provision the MySQL 8.0.21 release as shown below.
Using the Azure portal
Using the Azure CLI
az mysql flexible-server create --resource-group <resourcegroupname> --name <servername> --location <region> --admin-user <username> --admin-password <password> --sku-name Standard_B1ms --version 8.0.21 --public-access <your Client IP address>
Zone Placement – Specify your preferred Availability zone during server creation
One of the highlights of Flexible Server architecture is zone awareness and the ability for you to configure zone redundant high availability. But many of you asked for the flexibility to choose availability zones at server creation, similar to Azure VMs, VM Scale Sets, or Azure Kubernetes Services, which would allow you to collocate your application and database in the same Availability zones to minimize database latency and improve performance. Well, Flexible Server is all about the flexibility and controls that you are looking for. You can now specify your preferred Availability zone at the time of server creation as shown below.
Note: Not all Azure regions support availability zones today, so if you select a region that doesn't yet support multiple availability zones, you might not see this this functionality. You can find Azure regions that support availability zone here and the regions that support Flexible servers here.
Scale IOPs independently of the storage provisioned
When you provision an Azure Database for MySQL server (Single Server or Flexible Server), you get 3 IOPs per GB free for you to consume. When you want to perform migrations or data load operations, the complimentary IOPs can be too small, which can result in significant performance degradation, yet you don’t want to increase storage size as your IOPs scaling requirements are transient. Your feedback strongly indicated that you wanted us to provide the flexibility to scale up or down the IOPs provisioned for the server independently of the storage, which would enable you to scale up IOPs to perform transient operations such as migrations or data loads more quickly. We've now decoupled storage and IOPs, and you can provision additional IOPs beyond the complimentary IOPs (3 IOPs per GB) for operations such as migrations and data loads, and then scale it back down when not required to save cost. In addition, further IOPs scaling is a fully online operation that doesn't require any downtime or restarts. The maximum IOPs you can provision is limited by the Compute VM size you choose. For more details, refer to our documentation.
Known issues and what’s next
As you get ready to test Flexible Server, it's important to call out some of the known issues we are working on as this blog is written.
- SSL\TLS 1.2 can't be disabled – As I mentioned in my release blog post, with Flexible server SSL is enabled with TLS 1.2 encryption enforced, and you can't disable it yourself from the Azure portal. As your preferred cloud service provider, we made this decision intentionally, to keep the security bar high and enforce the right behavior. While we all have the right intent, at times we can tend to adhere to our legacy and complexity. After talking to many of you, we learned that some of your legacy applications don't support SSL and in fact that this serves as an adoption blocker, keeping you from leveraging all the value that Flexible Server has to offer. We're mindful of this, and we'll be allowing you to change the require_secure_transport server parameter by yourself from the Azure portal, the Azure CLI or ARM in the upcoming release. Until then, if you want to disable SSL for your Flexible Server, you can file a ticket from the Azure portal and our awesome support team will assist with this.
[Update April 6th 2021] - Ability to disable SSL and specify TLS version is now available with flexible server. More details refer - Encrypted connectivity using TLS/SSL in Azure Database for MySQL - Flexible Server | Microsoft Docs
- Provisioning failures in some regions and intermittently – Some of you experienced provisioning failures over the past couple of weeks while provisioning servers in East US, West Europe, and Southeast Asia regions. It turns out that we ran out of capacity. As a product manager, I feel thankful for such problems, but I admit that the experience was poor, and we can and will do better here. As it stands now, the problem is fixed and you should easily be able to provision servers in all supported Azure regions. We do, however, still have a known issue in which provisioning a server with private access (virtual network) gets stuck intermittently and deployments run forever. We're working on a fix for this that is expected to rollout in March. Not all end users experience this issue with provisioning a server with private access (VNet), and sometimes the issue can be resolved by retry attempts. Regardless, you should expect this to be fixed after our next rollout planned around end of March. If you're deploying a server for testing, it is recommended to use public access until the fix is rolled out.
[Update April 6th 2021] - All provisioning issues are fixed as of April 6th, 2021. - Ability to force failover – Many of you have asked for the ability to force a manual failover so that you can test failovers and measure application availability and tolerance to failovers. We're mindful of this ask, and we're working on this feature in the high availability area to give you the ability to force a manual failover at your will for testing and then later, if required, to use it in production as well.
We hope you are enjoying the new Flexible Server experience with our Azure Database for MySQL service. If you have any issues, feedback, or requests, please reach out to us using the following channels.
- If something is not working as expected or advertised, please file a ticket from the Azure portal.
- To provide feedback or to request new features without being engaged, search for or create a new entry via UserVoice.
- To provide feedback or request new features in which you would like to be engaged by our product team, please send an email to the Azure Database for MySQL Team (@Ask Azure DB for MySQL).
- To keep up to date with the latest releases and news, we recommend that you follow us on Twitter (@AzureDBMySQL) and subscribe to this blog.