MySQL Flexible Server 5.7 → 8.0 upgrade fails (VersionUpgradeFailed) — blocked by built-in mysql.az_replication_* procedures

Question

MySQL Flexible Server 5.7 → 8.0 upgrade fails (VersionUpgradeFailed) — blocked by built-in mysql.az_replication_* procedures

Claudia Visca 0

The in-place major version upgrade (5.7 → 8.0) of my Azure Database for MySQL Flexible Server fails with:

VersionUpgradeFailed — An error occurred while upgrading your Azure MySQL Flexible server
from 5.7 to 8.0, please use Oracle official MySQL upgrade checker to check whether your
server is ready for upgrade.

I ran util.checkForServerUpgrade() (MySQL Shell). The only Error-level findings are 4 stored procedures in the mysql system schema:

mysql.az_replication_change_master
mysql.az_replication_change_master_with_gtid
mysql.az_replication_remove_master
mysql.az_update_replica_information

All four fail the 8.0 syntax check with unexpected token 'REPLICATION'. Their definitions contain FLUSH REPLICATION;, which is invalid in MySQL 8.0.

Key points:

These are Azure-managed objects (DEFINER=azure_superuser@localhost), so I cannot modify them — any DDL on the mysql schema returns ERROR 1044: Access denied ... to database 'mysql'.
Replication is not even configured (SHOW SLAVE STATUS is empty).
They've existed unchanged since provisioning (CREATED = LAST_ALTERED = 2024-09-05).
Every other checker finding is Warning/Notice only (utf8mb3, etc.) — not the blocker.

Question: Has anyone hit this 5.7→8.0 upgrade block caused by the built-in az_replication_* procedures? Is there a supported way to get these system procedures fixed/recreated, or is a support ticket the only path? Target version chosen by the platform is 8.0.

Thanks!

0 comments

2 answers

Your answer

Answer 1

Welcome to Microsoft Q&A

Hello @Claudia Visca hope you are doing well,

What is actually happening is that the warnings regarding the mysql.a``z_replication_* procedures from the upgrade checker can be safely ignored because they are built-in Azure features and do not affect functionality or block the upgrade. The actual VersionUpgradeFailed error is typically caused by deprecated server parameters, such as sql_mode containing NO_AUTO_CREATE_USER, which are no longer supported in MySQL 8.0 and will silently block the deployment.

Check please the following things:

Update sql_mode: Go to the Server parameters pane in the Azure portal and remove obsolete values from sql_mode (such as NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, and NO_TABLE_OPTIONS) to avoid deployment failure.

Avoid simultaneous changes: Do not modify other properties of the service in the same request as the major version upgrade.

Retry the upgrade: After making the necessary configuration changes on the server, try the upgrade again.

References

Major Version Upgrade - Azure Database for MySQL | Microsoft Learn

MySql Flexible server upgrade from 5.7 to 8.0 fails without error information - Microsoft Learn
Performing a major version upgrade from MySQL 5.7 to 8.0 This visual walk-through demonstrates the exact portal steps required to execute the MySQL 5.7 to 8.0 version upgrade and verify pre-upgrade compatibility.

If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find solutions more easily. Thanks!

Claudia Visca 0 Reputation points

2026-06-23T14:27:31.46+00:00

Hello @Jose Benjamin Solis Nolasco and @SAI JAGADEESH KUDIPUDI ,

Thank you very much for your response.

I checked the database I'm trying to upgrade, but I don't see any value in sql_mode, so I don't believe that's the problem.

If there are no other known issues, I will open a ticket to request an analysis of the error logs.

Thank you for your help!

Answer 2

SAI JAGADEESH KUDIPUDI 3,645 Microsoft External Staff Moderator

Hi @Claudia Visca ,

Thank you for the detailed information.

The az_replication_* procedures are not the blocker. Those four mysql.-prefixed objects are built-in, Azure-managed stored procedures. The unexpected token 'REPLICATION' errors from Oracle's checker are expected false positives and can be safely ignored — they don't affect functionality, which is also why you correctly cannot modify them (ERROR 1044 is by design).

The real cause of VersionUpgradeFailed is usually a deprecated sql_mode value. Please do the following:

Go to Server parameters in the Azure portal and remove these values from sql_mode if present: NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS (removed in MySQL 8.0).
Take an on-demand backup (the upgrade is irreversible).
Check for pending XA transactions — run XA RECOVER; and roll back any with XA ROLLBACK '{xid}';.
Retry from Overview → Upgrade, confirm target version 8.0, and select Upgrade.

If it still fails after clearing the deprecated sql_mode values, a support ticket is the right next step so the backend upgrade logs can be reviewed.

Reference links:

Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.

SAI JAGADEESH KUDIPUDI 3,645 Reputation points Microsoft External Staff Moderator

2026-06-23T21:27:46.49+00:00

Hi @Claudia Visca ,
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
Claudia Visca 0 Reputation points

2026-06-24T17:13:48.7133333+00:00
Hi @SAI JAGADEESH KUDIPUDI ,

thank you very much for your response, really appreciated.

I verified the sql_mode suggestion: SELECT @@global.sql_mode returns empty on the server, so none of the deprecated values (NO_AUTO_CREATE_USER, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS) are set. So I don't think that's the cause in our case.

I also checked the other point:

XA RECOVER; returns no rows → no pending/in-doubt XA transactions.

Good to have confirmation that the mysql.az_replication_* errors are expected false positives.

So all the client-side causes I can diagnose appear to be ruled out, yet the upgrade still fails with the generic VersionUpgradeFailed.

Do you have any other suggestions I could check? Otherwise, I'll open a support ticket with Microsoft so the backend upgrade pre-check logs can be reviewed to identify the exact blocking condition.

Thanks again!
SAI JAGADEESH KUDIPUDI 3,645 Reputation points Microsoft External Staff Moderator

2026-06-26T04:03:29.3+00:00

Hi @Claudia Visca ,
Thank you very much for the detailed update and for verifying these points, It's good to confirm the sql_mode deprecated values aren't set and there are no pending XA transactions, which helps rule out the client-side causes. Since the upgrade still fails with the generic VersionUpgradeFailed error, the backend pre-check logs would need to be reviewed to identify the exact blocking condition.
Could you please share the requested details in a private message so we can take a closer look and assist you further?
SAI JAGADEESH KUDIPUDI 3,645 Reputation points Microsoft External Staff Moderator

2026-06-30T01:48:35.7766667+00:00

Hi @Claudia Visca ,
Could you please share the requested details in a private message ?
Claudia Visca 0 Reputation points

2026-06-30T09:29:11.2833333+00:00

Hi @SAI JAGADEESH KUDIPUDI ,

Thank you again for your support!

We've identified the root cause of the upgrade-validation errors and resolved it on our side.

A few tables were flagged as non-existent, even though they appeared in SHOW TABLES. Investigation showed these were orphan tables with missing InnoDB tablespaces: the table definitions existed in the data dictionary, but the underlying tablespace files were not present, so the tables could not be opened (error 1146). I believe that this originated from the restore process used to create this test instance, where some tablespaces were not carried over.

As this is a disposable test-upgrade environment, we cleaned up the affected objects, and the upgrade was successful.

Thank you!