This article is contributed. See the original author and article here.

Thank you all for an overwhelming response to our Flexible Server release. Your continued feedback is critical for us to ensure we invest in the features which are important for you. Today, I am excited to share some of the exciting new features which we released last week driven by your feedback.


 


MySQL 8.0.21 now available in Flexible Server


With MySQL v8.0, the mysqlserverteam is continuing to add exciting new features in every minor version release and it is sometimes difficult to catch-up (which is a good problem to have :smiling_face_with_smiling_eyes:). Immediately after flexible server release, many of you requested us to prioritize MySQL 8.0 ASAP to unblock you to move flexible server and some of you were looking for MySQL 8.0.20 or above to leverage some exciting improvements from the community. Today, we are happy to share MySQL 8.0.21 is now available in Flexible Server in all major Azure regions. You can use Azure portal, Azure CLI or Azure Resource Manager templates to provision MySQL 8.0.21 release as shown below:


 


Using Azure portal:


 


Create a MySQL 8.0 Flexible ServerCreate a MySQL 8.0 Flexible Server


 


Using Azure CLI:


 


 

az mysql flexible-server create --resource-group pariks-pass-demo --name <servername> --location japaneast --admin-user myadmin --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 ability for you to configure zone redundant high availability. But many of you asked for the flexibility for you to chose availability zones at the server creation time similar to Azure VMs, VM Scale Sets or Azure Kubernetes Services so you can 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 which 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 which do not support multiple availability zones yet, you might see no preference. You can find Azure regions that support availability zone here and the regions which support Flexible servers here.


 


Specify your preferred Availability Zone during server creationSpecify your preferred Availability Zone during server creation


Scale IOPs independent of the storage provisioned !!!


When you provision an Azure Database for MySQL server (single server or flexible server), you get 3 IOPs free per GB 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 slowness and you don’t want to increase storage size as your IOPs scaling requirements is transient. One of the strong feedbacks you gave us is to provide flexibility to scale up or down IOPs provisioned for the server independent of the storage so you can scale up IOPs to perform transient operations like migrations or data loads faster. We have now decoupled storage and IOPs, and you can provision additional IOPs beyond the complimentary IOPs (3 IOPs per GB) for operations like migrations, data loads and scale it back down when not required to save cost. Further IOPs scaling is a fully online operation which doesn’t need any downtime or restarts. The maximum IOPs you can provision is limited by the Compute VM size you choose. For more details, you can refer to the documentation.


 


Scale the server IOPs independent of storage provisionedScale the server IOPs independent of storage provisioned


 


Known Issues & What’s Next


As you get ready to test flexible server, I would also like to call out some of the known issues which we are working on as I write this blog:



  • SSLTLS 1.2 cannot be disabled – As I mentioned in my release blog post, SSL is enabled with TLS 1.2 encryption enforced with Flexible server and you cannot disable it yourself from Azure portal. It was an intentional decision which we took as your preferred cloud service provider, to keep the security bar high and enforce the right behavior. While we and you, our end user, have the right intent but at times, we are all slaves of our legacy and complexity. We learned after talking to many of you, some of your legacy applications do not support SSL and it turns out as an adoption blocker for you to leverage all the goodness of flexible server has to offer. We are mindful of this and we will be allowing you to change require_secure_transport server parameter by yourself from Azure portal, Azure CLI or ARM in the upcoming release. Until then, if you would like to disable SSL for your flexible server, please file a ticket from the Azure portal and our awesome support team will assist you go past it.

  • Provisioning failures in some regions and intermittently – Some of you experienced provisioning failures past couple of weeks while provisioning servers in East US, West Europe, and South east Asia regions. It turns out we ran out of capacity. As a product manager, I feel thankful for such problems, but I admit, our experience was poor, and we can do better there. As it stands now, the problem is fixed and you should easily be able to provision servers in all the supported Azure regions. However, we still have a known issue, where provisioning of a server with private access (virtual network) gets stuck intermittently and deployment runs forever. We are working on a fix and the fix is expected to rollout in March. The provisioning stuck with private access (VNet) is not encountered by all the end users and sometimes can be fixed by retry attempts. In either case, you should expect this to be fixed after our next rollout by around end of March. If you are deploying the server for testing, the recommendation would be to use public access until the fix is rolled out.

  • Ability to force failover – Many of you have asked for the ability to do a force manual failover for you to test failovers, and measure application availability and tolerance to failovers. We are mindful of this ask and we are working on this feature in high availability area which gives you the ability to force a manual failover at your will for testing and later to use it in production as well if required.


Hope you are enjoying the new flexible server experience with Azure Database for MySQL service. If you have any issues, feedback or request, please use the following channels to reach out to use


 



  • 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 where you don’t want to be engaged, search for or create a new entry via UserVoice.

  • To provide feedback, request new features where you are willing to be engaged by our product team, please send an email to the Azure Database for MySQL Team (@Ask Azure DB for MySQL)

  • If you want to stay up-to-date with the latest releases and news, we recommend to follow us at (@AzureDBMySQL) on twitter and subscribe to this blog.

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.