Major version upgrades of production databases can be stressful and a significantly time-consuming and costly project if you are dealing with a fleet of database servers to upgrade. You are expected to deal with a daunting list of tasks to plan and execute a seamless upgrade with minimal impact to the business. The tasks are daunting not because they are complex but because the stakes are high. You will need to practice and practice until you get perfection and confidence to execute upgrade of your production environment flawlessly in the acceptable downtime window. Some of these tasks can be automated but generally each environment is a bit different (for e.g. Ubuntu 16 vs Ubuntu 18) and often heavily customized for the application or business it is running. This makes automation of the task a bit challenging. The practice session may involve building production like environment, testing the application for compatibility, simulating the workload, practicing the steps multiple times, and documenting it to ensure all the dependencies or customizations are taken care of. This makes the upgrade process stressful as it involves multiple manual steps and error prone when you are working under pressure towards a tight deadline. We are trying to make this process a bit easy for you with our new major version upgrade feature in Azure Database for MySQL service.
With the release of Major Version Upgrades in Azure Database for MySQL, you can now upgrade your MySQL v5.6 servers to MySQL v5.7 with a click of a button.
In Azure portal, on the Overview blade, you will now see an Upgrade button for MySQL v5.6 servers that can use to upgrade your existing MySQL servers.
You can learn more about how to upgrade using this feature in our documentation.
While this feature doesn’t promise to take all your problems away :smiling_face_with_smiling_eyes: (I wish we had that magic wand) but together with managed service value proposition, it does promise to simplify some of the tasks for you. For instance –
Simulating a production like environment – This is easy with managed service as you can use point in time restore feature (another turnkey solution) to clone your production environment.
Practicing upgrades – With multiple manual steps taken out from your upgrade document and replaced with a single step of a click of a button, this becomes a simplified experience which can be further be automated using Azure CLI.
Managing upgrades for a fleet of servers – You can use Azure CLI to automate restore and upgrade operations which can then be used to run across the fleet of servers with ease.
No dealing of customized environments – With standardization and restricted access to a managed service, you do not need to worry about customized environment which is often the common causes of failed upgrades as there is heavy customization at the underlying OS and filesystem.
While the above challenges are addressed and simplified with this feature, you can focus your energy on
Understanding the changes in MySQL 5.7 to drive clarity to your business and development team on what will break or behave differently in MySQL 5.7.
Test your application compatibility to ensure it works as intended and the compatibilities are addressed.
Estimate and plan for the downtime required for the upgrades and execute the upgrade operation during your planned maintenance window.
Sometimes testing the application compatibility and upgrading the application code is the most challenging task of the upgrade and time/effort consuming too so can we afford to not be under the gun for upgrade timelines. The answer to that is: Yes.
We have updated our retirement policies for Azure Database for MySQL where we have clearly documented the restrictions if you chose to run your servers after retirement date and what you can expect.
It is now time for you to plan your upgrades of MySQL v5.6 servers as the end of support is approaching soon on February 5, 2021.