Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Note
This article contains references to the term slave, a term that Microsoft no longer uses. When the term is removed from the software, we'll remove it from this article.
This article describes how to upgrade your MySQL major version in Azure Database for MySQL Flexible Server. This feature enables customers to perform major version upgrades (for example, from MySQL 5.7 to 8.0 or 8.0 to 8.4) without moving data or changing application connection strings.
Important
- Duration of downtime varies based on the size of the database instance and the number of tables it contains.
- When initiating a major version upgrade for Azure Database for MySQL Flexible Server via Rest API or SDK, please avoid modifying other service properties in the same request. Simultaneous changes aren't permitted and might lead to unintended results or request failure. Conduct property modifications in separate operations after the upgrade is completed.
- Some workloads might not exhibit enhanced performance after a major version upgrade. We suggest that you evaluate the performance of your workload by first creating a replica server (as a test server), then promoting it to a standalone server, and then running the workload on the test server before implementing the upgrade in a production environment.
- Upgrading the major MySQL version is irreversible. Your deployment might fail if validation identifies that the server is configured with any features that are removed or deprecated in the target version. You can make the necessary configuration changes on the server and try the upgrade again.
Prerequisites
- Read Replicas with an older MySQL version should be upgraded before the Primary Server for replication to be compatible between different MySQL versions. Read more on Replication Compatibility between MySQL versions.
- Before upgrading your production servers, it's now easier and more efficient with our built-in Validate feature in the Azure portal. This tool prechecks your database schema's compatibility with the target MySQL version, highlighting potential issues. While we offer this convenient option, we also strongly recommend you use the official Oracle MySQL Upgrade checker tool to test your database schema compatibility and perform necessary regression tests to verify application compatibility with features removed/deprecated in the new MySQL version.
- Trigger on-demand backup before you perform a major version upgrade on your production server. Backups taken before the upgrade can be used to roll back to the previous version from the full on-demand backup.
- Before proceeding with the major version upgrade, please ensure there are no active or pending XA transactions on the database, as ongoing XA transactions can potentially cause the upgrade process to fail. First, to avoid this issue, check for any XA transactions in the "prepared" state by running
XA RECOVER;. For any transactions identified, useXA ROLLBACK '{xid}'; to roll back each transaction, replacing {xid} with the transaction ID. Ensure all XA transactions are either committed or rolled back before initiating the upgrade to maintain transaction consistency and reduce the risk of upgrade failures.
Note
When you use Oracle's official tool to check schema compatibility, you might encounter some warnings indicating unexpected tokens in stored procedures, such as:
mysql.az_replication_change_master - at line 3,4255: unexpected token 'REPLICATION'
mysql.az_add_action_history - PROCEDURE uses obsolete NO_AUTO_CREATE_USER sql_mode
You can safely ignore these warnings. They refer to built-in stored procedures prefixed with mysql., which are used to support Azure MySQL features. These warnings don't affect the functionality of your database.
Perform a planned major version upgrade using the Azure portal for Burstable SKU servers
Performing a major version upgrade for an Azure Database for MySQL Burstable SKU compute tier requires a specialized workflow. Major version upgrades are resource-intensive, demanding significant CPU and memory. Burstable SKU instances, being credit-based, might struggle under these requirements, potentially causing the upgrade process to fail. Therefore, when upgrading a Burstable SKU, the system first upgrades the compute tier to a General-Purpose SKU to ensure sufficient resources are available for the upgrade.
To perform a major version upgrade for an Azure Database for MySQL Burstable SKU compute tier using the Azure portal, follow these steps:
In the Azure portal, select your existing Azure Database for MySQL Flexible Server instance.
Important
We recommend performing an upgrade first on a restored server copy rather than upgrading production directly. See how to perform point-in-time restore.
On the Overview page, in the toolbar, select Upgrade.
Important
Before upgrading, visit the link for the list of features removed in the target MySQL version. Verify deprecated sql_mode values and remove/deselect them from your current Azure Database for MySQL Flexible Server using the Server Parameters Blade on your Azure portal to avoid deployment failure. sql_mode with values NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS and NO_TABLE_OPTIONS are no longer supported in MySQL 8.0 and later.
Schema Compatibility Validation
Before proceeding with the upgrade, run Oracle's official MySQL Upgrade checker tool to validate that your current database schema is compatible with the target MySQL version. This step is crucial to ensure a smooth upgrade process.
Pre-Upgrade Decision
Before upgrading, you must choose the compute tier to upgrade to perform the major version upgrade. By default, the system upgrades from Burstable SKU to the most basic General Purpose SKU, but you can upgrade to a higher compute tier if needed. Please note that while your server operates in the "General Purpose" tier during the upgrade, you'll only be charged for the actual "General Purpose" resources used during this period.
Post-Upgrade Decision
After the upgrade, decide whether to retain the General Purpose SKU or revert to Burstable SKU. This choice is prompted during the initial upgrade steps.
The system automatically upgrades your compute tier from Burstable SKU to the selected General Purpose SKU to support the major version upgrade.
Major Version Upgrade
Once the compute tier is upgraded, the system initiates the major version upgrade process. Monitor the upgrade progress through the Azure portal. The upgrade process might take some time, depending on the size and activity of your database. Please note that If the major version upgrade fails, the compute tier won't automatically revert to the previous Burstable SKU. This allows customers to continue the major version upgrade without performing the compute tier upgrade again.
Automatic Reversion
Based on your preupgrade decision, the system either retains the General Purpose SKU or automatically reverts to Burstable SKU after the upgrade. If you automatically revert to Burstable SKU, the system reverts to the B2S SKU by default.
Perform a planned major version upgrade using the Azure portal for general-purpose and business-critical SKU servers
To perform a major version upgrade of an Azure Database for MySQL Flexible Server using the Azure portal, perform the following steps.
In the Azure portal, select your existing Azure Database for MySQL Flexible Server instance.
Important
We recommend performing an upgrade first on a restored server copy rather than upgrading production directly. See how to perform point-in-time restore.
On the Overview page, in the toolbar, select Upgrade.
Important
Before upgrading, visit the link for the list of features removed in the target MySQL version. Verify deprecated sql_mode values and remove/deselect them from your current Azure Database for MySQL Flexible Server using the Server Parameters Blade on your Azure portal to avoid deployment failure. sql_mode with values NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS and NO_TABLE_OPTIONS are no longer supported in MySQL 8.0 and later.
Perform Pre-Upgrade Validation
Before proceeding with the upgrade, select the Validate button to check the compatibility of your server with the target MySQL version.
Note
When using the 'Validate' feature to assess your database schema for compatibility with the target MySQL version, please take note of the following considerations:
- Table Locking During Validation: The validation process involves locking tables to inspect the entire schema accurately. This can lead to query timeouts if the database is under heavy load. Recommendation: Avoid running validation during peak business hours or when the database handles high traffic. Instead, schedule the validation during low-activity periods to reduce the impact on operations.
- Potential for Hanging Due to Large Result Sets: In some instances—particularly with complex databases containing many objects—the validation result might become too large to be processed or displayed within the online workflow. This might result in the 'Validate' operation appearing to hang or remain in progress indefinitely. Recommendation: If you encounter this issue, we suggest performing the validation locally using Oracle's official client-side upgrade checker tool, such as the one included in MySQL Shell. This approach avoids platform-side result size limitations and provides a more detailed and reliable validation output.
- Recommended Use Cases for Online Validation: The online 'Validate' feature is designed for simple or moderately complex schemas. For large-scale production environments—such as those with thousands of tables, views, routines, or other schema objects—we strongly recommend using Oracle's client-side upgrade checker tool to perform the compatibility check. This ensures the full schema is analyzed comprehensively and avoids potential issues related to result size or validation timeouts.
In the Upgrade sidebar, in the MySQL version to upgrade text box, verify the major MySQL version you want to upgrade to (for example, 8.0 or 8.4).
Before you can upgrade your primary server, you must first upgrade any associated read replica servers. Until this is completed, Upgrade is disabled.
On the primary server, select the confirmation message to verify that all replica servers have been upgraded, and then select Upgrade.
Upgrade is enabled by default on read replica and standalone servers.
Perform a planned major version upgrade using the Azure CLI
To perform a major version upgrade of an Azure Database for MySQL Flexible Server using the Azure CLI, perform the following steps.
Install the Azure CLI for Windows or use the Azure CLI in Azure Cloud Shell to run the upgrade commands.
This upgrade requires the Azure CLI version 2.40.0 or later. If you're using Azure Cloud Shell, the latest version is already installed. Run az version to find the version and dependent libraries that are installed. To upgrade to the latest version, run az upgrade.
After you sign in, run the az MySQL server upgrade command.
az mysql flexible-server upgrade --name {your mysql server name} --resource-group {your resource group} --subscription {your subscription id} --version {target major version}Replace
{target major version}with the version you want to upgrade to (for example, 8 or 8.4).Under the confirmation prompt, type y to confirm or n to stop the upgrade process, and then press Enter.
Perform a major version upgrade on a read replica server using the Azure portal
To perform a major version upgrade of an Azure Database for MySQL Flexible Server read replica server using the Azure portal, perform the following steps.
select your existing Azure Database for MySQL Flexible Server and read the replica server in the Azure portal.
On the Overview page, in the toolbar, select Upgrade.
Important
Before upgrading, visit the link for the list of features removed in the target MySQL version. Verify deprecated sql_mode values and remove/deselect them from your current Azure Database for MySQL Flexible Server using the Server Parameters Blade on your Azure portal to avoid deployment failure.
In the Upgrade section, select Upgrade to upgrade an Azure Database for MySQL Flexible Server read replica server to the target major version.A notification appears to confirm that the upgrade is successful.
On the Overview page, confirm that your Azure Database for MySQL Flexible Server read replica server is running the target version.
go to your primary server and perform a major version upgrade.
Perform minimal downtime major version upgrade using read replicas
To perform a major version upgrade of an Azure Database for MySQL Flexible Server with minimal downtime using read replica servers, perform the following steps.
select your existing Azure Database for MySQL Flexible Server instance in the Azure portal.
Create a read replica from your primary server.
Upgrade your read replica to the target major version.
After you confirm that the replica server is running the target version, stop your application from connecting to your primary server.
Check replication status to ensure that the replica has caught up with the primary, so all data is in sync, and no new operations are being performed on the primary.
Confirm with the show replica status command on the replica server to view the replication status.
SHOW SLAVE STATUS\GIf the state of Slave_IO_Running and Slave_SQL_Running is yes and the value of Seconds_Behind_Master is 0, replication works well. Seconds_Behind_Master indicates how late the replica is. If the value isn't 0, then the replica is still processing updates. After you confirm that the value of Seconds_Behind_Master is 0, it's safe to stop replication.
Promote your read replica to primary by stopping replication.
Set Server Parameter read_only to 0 (OFF) to start writing on the promoted primary.
Point your application to the new primary (former replica) running the target version. Each server has a unique connection string. Update your application to point to the (former) replica instead of the source.
Note
This scenario only incurs downtime during steps 4 through 7.