MySQL 9.0

MySQL 9.0 was an Innovation release rather than a long-term-support baseline. It carried forward the rapid-change release model and the accumulated feature, behavior, and deprecation changes from the Innovation track. A material compatibility change was removal of the mysql_native_password server authentication plugin. Deployments that still depended on accounts using that plugin needed to move to a supported authentication method, commonly caching_sha2_password, and confirm that all client libraries and connection pools could use it. As with other major MySQL release transitions, teams also needed to account for changed defaults, removed deprecated syntax and options, optimizer behavior changes, and replication or tooling compatibility across the upgraded estate.

MySQL 9.0 has reached end of life, so remaining on it means operating without vendor fixes for newly discovered security issues, defects, or compatibility problems. An incident involving the server, replication, backup and recovery tooling, or a connector may therefore require mitigation by configuration change, rollback, or migration rather than a supported maintenance update. The unsupported version also becomes harder to run as operating systems, container bases, TLS libraries, monitoring agents, backup products, and client connectors move their tested support forward. Organizations with patching, audit, or supplier-support requirements may need to carry a documented exception and additional compensating controls while the migration remains incomplete.

Choose a currently supported MySQL target, preferably the vendor-supported long-term-support line if that fits the organization’s upgrade policy, and verify the documented upgrade path from 9.0 to that target. Inventory server configuration, storage engines, plugins, user authentication methods, SQL modes, character sets and collations, replication topology, and every application connector. Run MySQL Shell’s upgrade checker against representative production metadata, resolve all reported errors and warnings, and specifically confirm that no account or client dependency relies on mysql_native_password. Rehearse the migration on production-like data, including backup restore, application regression tests, failover and replication tests, performance checks for important queries, and rollback procedures. Take verified recoverable backups before production work, upgrade replicas and topology components only in an order supported by MySQL’s version-compatibility rules, then validate application traffic, replication health, backups, and monitoring before retiring the 9.0 estate.