Upgrading to Aurora MySQL version 8.4

Migrate authentication plugins. Review all database users and migrate any users using mysql_native_password to caching_sha2_password. In Aurora MySQL version 8.4, the mysql_native_password plugin is still supported but deprecated. The default authentication_policy is *:caching_sha2_password, so new users are created with caching_sha2_password by default.

-- Find users using mysql_native_password
SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';

-- Migrate a user to caching_sha2_password
ALTER USER 'username'@'host' IDENTIFIED WITH caching_sha2_password BY 'new_password';

Update replication SQL statements. If your applications or scripts use deprecated replication statements (such as SHOW SLAVE STATUS or CHANGE MASTER TO), update them to use the replacement statements. These old statements return syntax errors in version 8.4. For the full list, see Comparing Aurora MySQL version 3 and Aurora MySQL version 8.4.

Check for removed parameters. If your custom parameter groups use any parameters that were removed in version 8.4 (such as expire_logs_days or default_authentication_plugin), create new MySQL 8.4–compatible parameter groups with the replacement parameters. Apply any necessary custom parameter values to the new parameter groups. For details, see Comparing Aurora MySQL version 3 and Aurora MySQL version 8.4.

Check for incompatible SQL syntax. Review your application code for removed syntax such as LOW_PRIORITY with LOCK TABLES ... WRITE, and AUTO_INCREMENT on FLOAT or DOUBLE columns.

Check foreign key constraints. If your schema uses foreign keys that reference non-unique keys, note that creating new such foreign keys is blocked by default in version 8.4. Existing foreign keys continue to work, but new ones require setting restrict_fk_on_non_standard_key=OFF.

Check for new reserved keywords. Verify that your database objects don't use any of the new reserved keywords added in MySQL 8.4 as unquoted identifiers.

Test the upgrade. We recommend testing the upgrade on a clone of your production cluster before upgrading the production cluster itself.

Review security considerations. For details about authentication plugin changes, TLS and cipher changes, password policies and the validate_password component, new dynamic privileges, and upgrade prechecks such as deprecatedDefaultAuth and auroraValidatePasswordPluginCheck, see Security considerations for upgrading from Aurora MySQL version 3 to version 8.4.