MySQL 9.1

MySQL 9.1 was an Innovation release line following MySQL 9.0, not a long-term-support baseline. It carried the then-current set of server, client, packaging, dependency, security, and defect changes from the Innovation train. For migration planning, its important distinction from an LTS line is its short maintenance horizon: it was intended to be superseded by later releases rather than retained as a durable production standard. MySQL 9.1 has reached end of life.

Remaining on MySQL 9.1 means operating without vendor fixes for newly discovered security vulnerabilities, correctness defects, stability problems, or compatibility issues. A database issue that is reproducible on 9.1 may require an upgrade before it can receive a vendor-supported resolution. The longer the installation remains unchanged, the more likely that operating systems, TLS and crypto libraries, backup tooling, monitoring agents, connectors, and application frameworks will be validated primarily against newer MySQL releases. This also increases the eventual migration scope: configuration defaults, deprecated options, authentication settings, plugins, replication behavior, SQL compatibility, and client-library behavior all need to be assessed together rather than incrementally.

Select a currently supported MySQL target, preferably the vendor's current LTS line unless a required feature calls for a supported Innovation release. Confirm the documented upgrade path from 9.1 to that target; do not assume that every version skip is supported for an in-place upgrade. Build a production-like test environment and run the MySQL Shell upgrade checker against representative schemas and configuration. Inventory server options, authentication accounts, plugins, storage engines, character sets and collations, scheduled events, stored programs, replication topology, backup and restore procedures, and every application connector. Test application queries and failover, backup recovery, replication, and rollback procedures on the target version. Take verified backups, rehearse the cutover using a tested upgrade or migration method, and retain a rollback path until the upgraded service has passed functional and performance validation.