Choosing how to upgrade a MySQL database is rarely just a question of source and target versions.

The best approach can depend on database size, storage engines, replication topology, available infrastructure, acceptable downtime, backup readiness, application compatibility, and rollback requirements. A small standalone database with a long maintenance window may be a good candidate for an in-place upgrade. A multi-terabyte production system with strict availability requirements may need a replica-first, Clone-seeded, backup-seeded, or logical migration instead.

To help navigate those decisions, I have been developing the MySQL Upgrade Advisor, an open-source Python plugin for MySQL Shell.

Important: This project is my personal contribution to the MySQL community. It is not an Oracle product, is not part of MySQL Enterprise Edition, and is not supported by Oracle Support. The recommendations it produces are advisory and must be independently reviewed and validated before use.

github.com/mfrankmysql/mysql-upgrade-advisor

Development disclosure: This project was entirely “vibe coded” with OpenAI’s ChatGPT. I provided the requirements, domain knowledge, testing feedback, and design direction, while ChatGPT generated and iteratively revised the implementation, tests, documentation, and packaging. The code is being shared for community testing and should be reviewed as experimental software.

What the advisor does

The advisor connects read-only to the source MySQL instance and collects information it can determine automatically, including:

  • Exact MySQL version and edition
  • Database size, table count, largest tables, and storage-engine usage
  • Standalone, asynchronous replication, Group Replication, InnoDB ReplicaSet, InnoDB Cluster, or InnoDB ClusterSet topology
  • GTID, binary logging, replication, and Clone-related information
  • MySQL Enterprise Backup history when the metadata is available
  • MySQL Shell Upgrade Checker results for the requested target version

It then asks guided questions about information that cannot be discovered reliably from the server, such as:

  • Maximum acceptable write downtime
  • Availability of a second server or full database copy
  • Application and connector certification
  • Traffic-switching capability
  • Backup restore testing
  • Data-validation plans
  • Rollback requirements
  • Whether the upgrade has been rehearsed at production scale

Questions support y, n, and h. Selecting h explains why the question matters, what evidence to look for, and how to determine the appropriate answer.

The result is an upgrade recipe

The goal is not simply to produce a PASS or FAIL result.

Based on the discovered environment and the operator’s answers, the advisor generates a detailed upgrade recipe containing:

  • The recommended upgrade method and why it fits the environment
  • The exact version stages required
  • Alternative methods considered
  • Reasons other methods were rejected or ranked lower
  • Preparation and infrastructure requirements
  • Upgrade Checker findings
  • Backup, seeding, synchronization, and cutover steps
  • Validation and monitoring guidance
  • Abort criteria and rollback considerations
  • The point at which rollback is no longer a simple traffic switch
  • Remediation options and command templates for failed readiness gates

The current rules can evaluate approaches such as:

  • Direct in-place upgrade
  • Staged in-place upgrade
  • MySQL Shell logical dump and load
  • Replica-first rolling upgrade
  • Clone-seeded side-by-side in-place upgrade
  • Physical-backup-seeded side-by-side upgrade

Current testing scope

The initial testing release focuses on Oracle MySQL environments involving:

  • MySQL 5.7
  • MySQL 8.0
  • MySQL 8.4 LTS
  • MySQL 9.7 LTS
  • MySQL 26.7 and later Innovation-release planning targets

Topology discovery currently covers:

  • Standalone MySQL
  • Traditional asynchronous replication
  • Group Replication
  • InnoDB ReplicaSet
  • InnoDB Cluster
  • InnoDB ClusterSet

Exact upgrade-path support remains version-specific. The advisor distinguishes between a path it can evaluate, support recognized by the installed Upgrade Checker, and the additional evidence required before an upgrade should be approved for production.

I need your help testing it

I am looking for SEs, DBAs, partners, and members of the MySQL community who can test the advisor against different versions, database sizes, platforms, and topologies.

The most useful feedback includes:

  • Did it correctly discover the source version, edition, topology, and database size?
  • Did it ask questions whose answers it should already have known?
  • Were the questions and help text understandable?
  • Was the recommended upgrade method appropriate?
  • Were important alternatives or prerequisites missing?
  • Were the cutover, validation, abort, and rollback steps useful?
  • Did any Upgrade Checker, AdminAPI, backup-discovery, or report-generation operation fail?

Even feedback such as “this question was confusing” or “this recipe would not work for this topology” is valuable.

The project repository and testing releases are available at:

github.com/mfrankmysql/mysql-upgrade-advisor

Please begin with a disposable, development, or test environment, follow the installation and testing instructions in the repository, and sanitize generated reports before attaching them to a public GitHub issue.

Safety and support boundary

The MySQL Upgrade Advisor is currently advisory and read-only. It does not perform the upgrade, modify schemas or data, change replication, execute Clone operations, install software, restart servers, perform backups or restores, promote replicas, or switch application traffic.

Commands included in a generated recipe are templates for operator review; the advisor does not execute them.

This project:

  • Is a personal open-source contribution
  • Is not an Oracle product
  • Is not an officially supported MySQL utility
  • Is not covered by Oracle Support
  • Does not replace official MySQL documentation or support guidance
  • Is provided without a guarantee that its recommendations are correct or complete for every environment

Before acting on a generated recommendation, verify the proposed path against the official documentation for the exact MySQL versions involved. Test application compatibility, confirm that backups can be restored, validate rollback procedures, and rehearse the complete upgrade using production-representative data and workloads.

The project is under active development and is released under the Universal Permissive License.

I look forward to the feedback—and to seeing how the advisor behaves across the wide variety of MySQL environments in use today.

As always, thanks for using MySQL!