Mise à niveau vers Aurora MySQL version 8.4

Migrez les plugins d'authentification. Passez en revue tous les utilisateurs de la base de données et migrez tous les utilisateurs utilisant mysql_native_password verscaching_sha2_password. Dans la version 8.4 d'Aurora MySQL, le mysql_native_password plugin est toujours pris en charge mais il est obsolète. La valeur par défaut authentication_policy est*:caching_sha2_password, donc les nouveaux utilisateurs sont créés caching_sha2_password par défaut.

-- 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';

Mettez à jour les instructions SQL de réplication. Si vos applications ou scripts utilisent des instructions de réplication obsolètes (telles que SHOW SLAVE STATUS ouCHANGE MASTER TO), mettez-les à jour pour utiliser les instructions de remplacement. Ces anciennes instructions renvoient des erreurs de syntaxe dans la version 8.4. Pour obtenir la liste complète, consultez Comparaison entre Aurora MySQL version 3 et Aurora MySQL version 8.4.

Vérifiez les paramètres supprimés. Si vos groupes de paramètres personnalisés utilisent des paramètres supprimés dans la version 8.4 (tels que expire_logs_days oudefault_authentication_plugin), créez de nouveaux groupes de paramètres compatibles avec MySQL 8.4 avec les paramètres de remplacement. Appliquez toutes les valeurs de paramètres personnalisés nécessaires aux nouveaux groupes de paramètres. Pour en savoir plus, consultez Comparaison entre Aurora MySQL version 3 et Aurora MySQL version 8.4.

Vérifiez qu'il n'y a pas de syntaxe SQL incompatible. Vérifiez le code de votre application pour détecter toute syntaxe supprimée, telle que « LOW_PRIORITY avec »LOCK TABLES ... WRITE, « AUTO_INCREMENT sur » FLOAT ou « DOUBLE colonnes ».

Vérifiez les contraintes liées aux clés étrangères. Si votre schéma utilise des clés étrangères qui font référence à des clés non uniques, notez que la création de nouvelles clés étrangères de ce type est bloquée par défaut dans la version 8.4. Les clés étrangères existantes continuent de fonctionner, mais les nouvelles doivent être configuréesrestrict_fk_on_non_standard_key=OFF.

Vérifiez les nouveaux mots clés réservés. Vérifiez que les objets de votre base de données n'utilisent aucun des nouveaux mots clés réservés ajoutés dans MySQL 8.4 comme identifiants sans guillemets.

Testez la mise à niveau. Nous vous recommandons de tester la mise à niveau sur un clone de votre cluster de production avant de mettre à niveau le cluster de production lui-même.

Passez en revue les considérations de sécurité. Pour plus de détails sur les modifications du plug-in d'authentification, les modifications du protocole TLS et du chiffrement, les politiques de mot de passe et le validate_password composant, les nouveaux privilèges dynamiques et les prévérifications de mise à niveau telles que deprecatedDefaultAuth etauroraValidatePasswordPluginCheck, voir. Considérations relatives à la sécurité lors de la mise à niveau d'Aurora MySQL version 3 vers la version 8.4