Skip to content
Percona Software for MySQL Documentation

Rate this page
☆ ☆ ☆ ☆ ☆
Thanks for your feedback
Thank you! The feedback has been submitted.

For help, click the link below to get free database assistance or contact our experts for personalized support.

Get help from Percona

MySQL 9.x Innovation Series: Technical Migration Overview

Upgrading to the MySQL 9.x Innovation Series introduces stronger security defaults, improved scalability, and continued modernization of server internals. At the same time, legacy authentication methods, plugins, and configuration patterns are removed or retired.

This guide is intended for teams upgrading from MySQL 8.4 LTS to a Percona Server for MySQL release based on MySQL 9.x. It summarizes breaking changes, incompatible features, removed items, and new defaults that can affect compatibility, operations, and performance.

Use this document to identify required pre-upgrade actions and to plan configuration and application changes before moving to MySQL 9.x.

Breaking and incompatible changes

Before upgrading to MySQL 9.x, address the following high-impact changes first. • mysql_native_password authentication plugin removed All accounts and applications using mysql_native_password must be migrated to a supported authentication plugin (for example, caching_sha2_password) before upgrading, or authentication failures will occur. • gtid_mode and enforce_gtid_consistency default to ON Replication topologies that rely on file-based or position-based replication must be reviewed and explicitly configured, or replication may fail to start after the upgrade. • keyring_file plugin removed Servers configured to load the keyring_file plugin must migrate to a supported keyring component before upgrading, or the server may fail to start.

Each section below explains what is affected, what to use instead, and what actions to take.

Authentication and user management (9.0)

Impact • The mysql_native_password authentication plugin is removed as of MySQL 9.0.0. It was deprecated throughout MySQL 8.0. • Accounts configured to use mysql_native_password can no longer authenticate against a 9.x server. • Clients that do not support CLIENT_PLUGIN_AUTH are rejected. • The server options –mysql-native-password, –mysql-native-password-proxy-users, and the default_authentication_plugin system variable are removed. • The removal is on the 9.x server side only. Client-side libraries still support mysql_native_password for connecting to older (8.0 or 5.7) servers.

Replacement • Use caching_sha2_password or another supported authentication plugin. • New user accounts already default to caching_sha2_password in MySQL 8.4 and later.

Action • Identify all accounts and applications using mysql_native_password. • Migrate each account to a supported plugin before upgrading.

Example:

ALTER USER ‘username’@’host.’ IDENTIFIED WITH caching_sha2_password BY ‘new_password’;

•   Remove all references to removed authentication options and variables from configuration files and scripts before upgrading.

GTID and replication defaults (9.0)

For many environments, this is the largest breaking change: replication behavior depends on GTID settings.

Impact • As of MySQL 9.0, gtid_mode defaults to ON. • enforce_gtid_consistency also defaults to ON. • Replication setups that are not GTID-based may fail to start if not explicitly configured. • enforce_gtid_consistency=ON disallows certain non-deterministic statements within transactions. • In some distributions, gtid_mode may default to ON with OFF_PERMISSIVE logic during the upgrade phase. Explicitly setting gtid_mode=OFF (and enforce_gtid_consistency=OFF) if you are not ready for GTID remains the safest best practice.

Replacement • Either migrate to GTID-based replication or explicitly disable GTID before starting the upgraded server.

Action • If you are not ready to migrate to GTID, set the following before upgrading:

gtid_mode=OFF enforce_gtid_consistency=OFF

•   Review application SQL and stored programs for statements that are incompatible with enforce_gtid_consistency=ON.

–early-plugin-load removed (9.1)

Impact • The –early-plugin-load server option is removed in MySQL 9.1. • If present in configuration files, the server may fail to start.

Replacement • Use supported components and the component manifest mechanism (for example, mysqld.my).

Action • Scan configuration files for –early-plugin-load and remove it before upgrading. • Migrate affected functionality to components where applicable.

mysql client parsing of \G and \C (9.1)

Impact • The mysql client now recognizes \G (vertical output) and \C (clear) only at the end of a statement. • Scripts that embed these tokens mid-statement may fail or behave differently.

Replacement • Use \G and \C only at statement boundaries.

Action • Review scripts and automation that use mysql -e or batch input and correct any mid-statement usage.

CREATE DATABASE and DROP DATABASE atomic (9.1)

Impact • CREATE DATABASE and DROP DATABASE are now atomic and crash-safe. • This is a behavior improvement and does not introduce incompatibilities for correct usage.

Action • No action required.

keyring_file plugin removed (9.2)

Migrating from the keyring_file plugin to the component_keyring_file component is not just a configuration change. The component uses a different configuration file format and must be set up via a component manifest.

Impact • The keyring_file plugin binary is no longer included as of MySQL 9.2. • Configurations that attempt to load it will fail.

Replacement • Use the component_keyring_file component for file-based keyring storage. • The component is configured via a JSON manifest (often named component_keyring_file.cnf or defined in the component manifest), not via the same options in my.cnf. You cannot simply change a line in my.cnf; you must add and configure the component through the manifest.

Action • Initialize the component manifest and configure the component_keyring_file component before upgrading. • Migrate keyring data and configuration to the component using the manifest and the component’s required format. • Remove keyring_file plugin load directives from my.cnf (and any other config files) before upgrading.

Impact • FLUSH PRIVILEGES is deprecated and produces warnings. • The FLUSH_PRIVILEGES privilege, mysqladmin flush-privileges, and mysqladmin reload are deprecated.

Replacement • Use the recommended privilege-load behavior documented in the MySQL Reference Manual.

Action • Update scripts, automation, and operational runbooks to remove or replace deprecated commands.

Version Tokens plugin removed (9.3)

Impact • The Version Tokens plugin is deprecated in 9.2 and removed in 9.3. • Related functions, privileges, and system variables are removed.

Replacement • No direct replacement.

Action • Remove all usage of Version Tokens from configuration files and application code before upgrading.

Connection Control plugins deprecated (9.2)

Impact • Both Connection Control plugins are deprecated and may be removed in a future release.

Replacement • Use the Connection Control component (component_connection_control).

Action • Migrate from plugins to the component and update any scripts or monitoring that reference deprecated tables or variables.

Replica parallel workers minimum (9.3)

Impact • replica_parallel_workers can no longer be set to 0; the minimum allowed value is 1. • The default was already changed to 4 in MySQL 8.0.30 and later, so most modern configurations are unaffected unless they explicitly set 0 for single-threaded replica applier behavior.

Replacement • Use replica_parallel_workers = 1 for single-threaded behavior (or leave default if you did not override it).

Action • If you previously set replica_parallel_workers=0, update configuration to 1 (or remove the setting to use the default) before upgrading.

InnoDB variables removed (9.3)

Impact

The following InnoDB variables are removed: • innodb_log_file_size • innodb_log_files_in_group • innodb_undo_tablespaces

Redo and undo configuration is handled using new mechanisms.

Replacement

Removed variable MySQL 9.x approach innodb_log_file_size innodb_redo_log_capacity innodb_log_files_in_group Managed automatically innodb_undo_tablespaces Automatic undo management

Action • Remove variables from configuration files. • Review the current redo and undo configuration model in the MySQL Reference Manual.

IGNORE and scalar subqueries (9.0)

Impact • IGNORE no longer suppresses errors caused by scalar subqueries returning more than one row. • Statements such as INSERT IGNORE, UPDATE IGNORE, or DELETE IGNORE may now fail.

Replacement • Ensure scalar subqueries return at most one row.

Action • Review the application SQL and stored code and correct affected statements.

Inline foreign keys enforced (9.0)

Impact • Inline foreign key specifications that were previously parsed but ignored are now enforced.

Action • Review schema definitions and generated DDL. • Correct any statements that relied on previously ignored syntax.

MD5() and SHA1() deprecated in SQL (9.4)

This change affects the SQL functions MD5() and SHA1(). It often breaks legacy PHP or Java applications that offload hashing to the database.

Impact • The SQL functions MD5() and SHA1() are deprecated as of MySQL 9.4. • They continue to work but may be removed in a future release. • Applications that call these functions from the database layer (for example, legacy PHP or Java code that performs hashing in SQL) are particularly affected and may need changes before or after upgrade.

Replacement • Use the SQL function SHA2() or another supported hashing mechanism in the database, or move hashing to the application layer.

Action • Audit application code, stored procedures, and triggers for use of MD5() and SHA1(), especially in legacy PHP or Java applications that offload hashing to the database. Plan a migration to SHA2() or application-side hashing.

Group Replication and replication variables removed (9.5)

Impact • group_replication_allow_local_lower_version_join is removed. • replica_parallel_type and slave_parallel_type are removed. • The legacy semisynchronous replication plugins (semisync_master.so and semisync_slave.so) and their associated system and status variables (prefixed with rpl_semi_sync_) are removed in MySQL 9.5. Semisynchronous replication itself is not gone; only the old plugin-based implementation is removed.

Replacement • Semisynchronous replication is now provided by the Semisynchronous Replication Source and Replica components. Migrate to these components to keep semisync behavior.

Action • Remove the removed variables from configuration, monitoring, and automation. • Migrate to the Semisynchronous Replication Source and Replica components if you use semisync; update replication configuration to use the new components and supported mechanisms.

Defaults and tuning guidance

Replication defaults (9.0)

Variable New default Previous gtid_mode ON OFF enforce_gtid_consistency ON OFF

InnoDB and binary logging (9.5+)

•   innodb_log_writer_threads default now depends on:
•   Whether binary logging is enabled
•   Number of logical CPUs
•   binlog_transaction_dependency_history_size default increased from 25,000 to 1,000,000; maximum increased to 10,000,000.

Existing explicit settings are preserved.

Pre-upgrade checklist

•   Remove all removed or deprecated variables, options, and plugins.
•   Validate authentication plugins and migrate off mysql_native_password.
•   Review replication topology and GTID strategy.
•   Review InnoDB redo and undo configuration.
•   Test upgrades, replication, and failover in staging before production.