Azure Database for MySQL Blog

8 MIN READ

Guide to Upgrade Azure Database for MySQL from 8.0 to 8.4

Microsoft

Mar 05, 2026

This guide merges Azure official documentation and best practices from real-world upgrades. Always refer to the latest Azure documentation and portal/CLI for any updates or discrepancies.

1. Background

Why Upgrade?

MySQL 5.7 reached end of community support in October 2023, and will enter extended support in August 2026.
MySQL 8.0 will reach end of community support in April 2026 and will enter extended support in January 2027.
MySQL 8.4 is the first official LTS (Long Term Support) version, officially supported by Oracle until April 2032.
Upgrading ensures security, performance, and continued support.

Supported Upgrade Paths:

5.7 → 8.0 (must be completed first)
8.0 → 8.4
Direct 5.7 → 8.4 is NOT supported.
Downgrades are NOT supported.

Key Notes:

Irreversible: Major version upgrades are irreversible and cannot be rolled back directly.
Downtime: The server is offline during the upgrade. Downtime depends on database size and table count.
HA Limitation: High Availability (HA) servers cannot achieve near-zero downtime during major upgrades due to cross-version replication instability.
Performance: Some workloads may not see performance improvements after upgrade.

2. Key Changes

Authentication Plugin Changes

mysql_native_password is disabled by default in the MySQL 8.4 community version. However, it is enabled by default in Azure MySQL 8.4. Older client versions may not be able to connect using mysql_native_password. If you encounter this issue, upgrade your client version first.
The default_authentication_plugin variable should be removed.
All users should be migrated to the caching_sha2_password plugin.

Foreign Key Constraint Enforcement

Before the upgrade, referenced columns must have a unique key; check all foreign key constraints before upgrade.

Removed Features

FLUSH HOSTS command → use TRUNCATE TABLE performance_schema.host_cache
PASSWORD() function → use ALTER USER
tx_isolation option → use transaction_isolation
expire_logs_days → use binlog_expire_logs_seconds
AUTO_INCREMENT is no longer allowed on FLOAT/DOUBLE columns

New Reserved Keywords

MANUAL, PARALLEL, QUALIFY, TABLESAMPLE — do not use these as unquoted identifiers

Terminology Changes

MASTER/SLAVE terminology updated to SOURCE/REPLICA
Update all scripts and applications using old the terms

InnoDB 8.0 → 8.4 Default Parameter Changes

innodb_adaptive_hash_index: ON → OFF
innodb_change_buffering: All → None
innodb_buffer_pool_in_core_file: ON → OFF
innodb_io_capacity: 200 → 10000
innodb_log_buffer_size: 16MB → 64MB

3. Upgrade Prerequisites

Basic Requirements

Item	Requirement
Deployment Type	Azure Database for MySQL Flexible Server instance only
Region	Region must support MySQL 8.4 in Azure Portal
Current Version	Must be 8.0.x (check via SELECT VERSION(); or Portal)
Server Status	Server must be running, with no ongoing scaling/restart/updates

Read Replica Version

If read replicas exist, upgrade them before upgrading the primary server. Cross-version replication is not guaranteed to be stable. Follow official documentation for handling replicas (stop replication and upgrade separately, or delete and recreate after upgrade).

Create On-Demand Backup

Before upgrading production, create an on-demand backup for rollback if needed: - Azure Portal > Your MySQL Server > Backup & Restore > Backup Now - Backups created before upgrade restore to the old version; backups after upgrade restore to the new version.

XA Transactions

Ensure no active or pending XA transactions:

XA RECOVER;

If any results are returned, roll back these transactions:

XA ROLLBACK 'xid';

SQL Mode

Remove deprecated sql_mode values before upgrade.

Deprecated: NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS - Check current SQL mode:

SELECT @@sql_mode;

In Azure Portal: Go to Server Parameters > Search “sql_mode” > Remove deprecated values > Save

4. Pre-Upgrade Checks

Use Upgrade Check Tool (MySQL Shell)

Check Items

The tool performs 40+ automated checks, mainly including:

Check Category	Description
Deprecated Time Types	Checks for old-format time columns
Reserved Keyword Conflicts	Checks for conflicts with reserved keywords in the new version
UTF8MB3 Charset	Checks for objects needing migration to UTF8MB4
Removed System Variables	Checks for configuration items no longer supported
Authentication Plugin Change	Checks for users needing updated authentication methods
Partition Table Restrictions	Checks for partition compatibility
Foreign Key Names	Checks for foreign key name conflicts

Oracle provides util.checkForServerUpgrade() to detect compatibility issues.

Install MySQL Shell 8.4 or higher.
Connect to Azure MySQL server:

mysqlsh --host=<your-server>.mysql.database.azure.com \
  --user=<admin-user> \
  --password \
  --ssl-mode=REQUIRED

Run upgrade check:

util.checkForServerUpgrade()
util.checkForServerUpgrade({"targetVersion": "8.4.0"})

Command-line (recommended):

mysqlsh <admin-user>@<your-server>.mysql.database.azure.com:3306 \
  --ssl-mode=REQUIRED \
  -- util checkForServerUpgrade \
  --target-version=8.4.0 \
  --output-format=JSON

Required privileges: RELOAD, PROCESS, SELECT.

The tool performs 40+ checks (deprecated types, reserved keywords, charset, removed variables, auth plugins, partitioning, FK constraints, etc.).

Review Results

Errors: Must be fixed before upgrade
Warnings: Strongly recommended to fix
Notices: Informational

Additional Compatibility and Validation Checks

Client Library Compatibility:

Some client libraries may be incompatible with MySQL 8.0+ due to outdated drivers. Collect and review all client driver versions and test compatibility in a staging environment before upgrade.

Authentication Changes

After upgrade, applications may fail to connect if not compatible with new authentication plugins. MySQL 8.0 defaults to caching_sha2_password, and MySQL 8.4 disables mysql_native_password by default.

Solution: Upgrade client drivers to versions supporting the new authentication method. If legacy drivers must be used, temporarily set user authentication to mysql_native_password and plan to upgrade drivers as soon as possible.

Charset and Collation Changes:

MySQL 8.0 defaults to utf8mb4 charset and utf8mb4_0900_ai_ci collation, which may cause changes in string comparison, index length limits, sort order, or JOIN-related errors due to charset mismatches.

Recommendations:

- Check if ORM and drivers support utf8mb4.
- Adjust index lengths (utf8mb4 uses up to 4 bytes per character).
- Specify COLLATE explicitly if you need to preserve original sort behavior.
- Standardize charset and collation settings for all tables and columns.

Object Statistics:

Review table and object statistics to estimate upgrade and rollback time.

Performance Considerations:

Most SQL workloads benefit from upgrades, but some queries may experience degraded performance (e.g., queries with ORDER BY, complex JOINs, subqueries, or many bound parameters). The optimizer evolves between versions (e.g., max_length_for_sort_data was deprecated in 8.0.20, execution plan changes, etc.).

Recommendations:

- Use standard SQL tuning methods: review execution plans, optimize queries, and add indexes as needed.

Test in Staging

💡 Strong Recommendation: First perform the upgrade in a staging environment (such as a restored backup copy of the original server) and validate the following:

Whether the upgrade process completes successfully
Estimated downtime
Application compatibility
Performance baseline comparison

5. Upgrade Methods & Scenarios

Upgrade Method Comparison

Method	Pros	Cons	Recommended For
In-Place Upgrade	Simple, no connection string change, no extra cost	Longer downtime, can be hours or even days, rollback only via backup	Dev/test, small prod, downtime allowed
Replica Based Upgrade	Low risk, fast rollback, minimal downtime	Extra cost, more steps, connection string change	Production, downtime sensitive

Method 1: In-Place Upgrade, Azure Portal (In-Place Upgrade, Recommended)

For General Purpose and Memory Optimized SKUs:

Sign in to Azure Portal
Navigate to your MySQL Flexible Server
Select Overview
Find MySQL Version and click Upgrade
Select target version 8.4
Review pre-upgrade validation
Confirm and start upgrade

For Burstable SKU: May require temporary SKU change to General Purpose before upgrade, then revert after.

Method 2: Azure CLI (In-Place Upgrade)

az cloud set --name AzureCloud
az login
az mysql flexible-server upgrade \
  --name <your-server-name> \
  --resource-group <your-resource-group> \
  --version 8.4

Method 3: Minimal Downtime (Read Replica)

For production environments sensitive to downtime:

Create read replica (Portal > Replication > Add Replica)
Wait for replica sync (check SHOW REPLICA STATUS\G, ensure Seconds_Behind_Master = 0)
Upgrade replica to 8.4 (Portal or CLI)
Validate replica upgrade (SELECT VERSION();)
Promote replica to primary (Portal > Replication > Stop Replication)
Update application connection strings to new primary
(Optional) Delete old primary

This approach is an architecture migration + failover, not the same as in-place upgrade. Cross-version replication stability is not guaranteed. Fully test in staging and communicate risks to stakeholders.

6. Post-Upgrade Validation

Check MySQL version:

SELECT VERSION();

Check database and table status:

SHOW DATABASES;
USE your_database;
SHOW TABLE STATUS;
CHECK TABLE your_table;

Validate application connectivity and key business functions
Monitor metrics for 24-48 hours: CPU, memory, I/O, query latency, error logs

7. Rollback Strategy

Major version upgrades are irreversible. Rollback requires restoring from backup:

Azure Portal > MySQL Server > Backup & Restore > Select pre-upgrade backup > Restore
Specify new server name
Wait for restore to complete
Update application connection strings to restored server

💡 The restored server is a new, independent server. The original server remains.

Business Rollback Advice:

- Confirm data loss/replay strategy for changes between upgrade and rollback
- Assess impact on dependent systems (reports, ETL, etc.)
- After rollback, point applications to old server, clean up new objects, and re-validate key functions

8. FAQs

Q1: Can I upgrade directly from MySQL 5.7 to 8.4?

No. Upgrade must be sequential: 5.7 → 8.0 → 8.4

Q2: How long does the upgrade take?

Downtime depends on database size, storage, and table count. Test in staging to estimate.

Q3: Can HA servers achieve zero downtime?

No. Major upgrades cannot use HA for near-zero downtime due to cross-version replication instability.

Q4: Will performance improve after upgrade?

Not guaranteed. Some workloads may see no change or slight decrease. Benchmark before and after.

Q5: Can I change other server properties during upgrade?

Not recommended. Avoid changing other properties via REST API or SDK during upgrade.

Q6: How to estimate downtime?

The number of objects contained in the database is related to the upgrade time; the larger the number, the longer it takes. The most accurate way to assess this is as follows. 1. Restore a test server from backup 2. Perform upgrade on test server 3. Record actual upgrade time 4. Add buffer for production

Q7: What happens to backups during/after upgrade?

Backups before upgrade restore to old version; after upgrade, to 8.4. Confirm retention and PITR settings before upgrade.

Q8: Is upgrade downtime included in SLA?

Planned downtime for upgrade is not counted in availability SLA. Schedule during maintenance window and communicate with stakeholders.

Q9: Charset and collation issues after upgrade?

MySQL 8.0+ defaults to utf8mb4 and utf8mb4_0900_ai_ci. Check ORM/driver support, adjust index length, specify COLLATE if needed, and unify charset settings.

Q10: Performance issues after upgrade?

Some queries may slow down due to optimizer changes. Use EXPLAIN/ANALYZE, add/optimize indexes, use query hints, and review execution plans.

Q11: Authentication issues after upgrade?

MySQL 8.0+ defaults to caching_sha2_password. Upgrade client drivers. If needed, temporarily revert user auth to mysql_native_password (not recommended for 8.4).

Q12: Client library compatibility?

Test all client libraries in staging. Upgrade outdated connectors/ORMs.

Q13: What is Azure Extended Support?

Azure provides paid extended support for MySQL versions after community EOL. See Extended Support for MySQL.