Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Comparaison d’Aurora MySQL version 2 et Aurora MySQL version 3
Utilisez les éléments suivants pour en savoir plus sur les modifications à prendre en compte lorsque vous mettez à niveau le cluster Aurora MySQL version 2 vers la version 3.
**Topics**
+ [Prise en charge du langage de définition des données (DDL) atomiques](#AuroraMySQL.Compare-v2-v3-atomic-ddl)
+ [Différences de fonctions entre Aurora MySQL version 2 et 3](#AuroraMySQL.Compare-v2-v3-features)
+ [Assistance pour les classes d’instance](#AuroraMySQL.mysql80-instance-classes)
+ [Modifications des paramètres d’Aurora MySQL version 3](#AuroraMySQL.mysql80-parameter-changes)
+ [Variables d’état](#AuroraMySQL.mysql80-status-vars)
+ [Changements linguistiques inclusifs pour Aurora MySQL version 3](#AuroraMySQL.8.0-inclusive-language)
+ [Valeurs AUTO\_INCREMENT](#AuroraMySQL.mysql80-autoincrement)
+ [Réplication de journaux binaires](#AuroraMySQL.mysql80-binlog)
## Prise en charge du langage de définition des données (DDL) atomiques
L’un des changements les plus importants entre MySQL 5.7 et 8.0 est l’introduction de l’[Atomic Data Dictionary](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html). Avant MySQL 8.0, le dictionnaire de données MySQL utilisait une approche basée sur des fichiers pour stocker les métadonnées telles que les définitions de tables (.frm), les déclencheurs (.trg) et les fonctions séparément des métadonnées du moteur de stockage (telles que celles d’InnoDB). Cela posait certains problèmes, y compris le risque que les tables deviennent « [orphelines](https://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html) » si un événement inattendu se produisait au cours d’une opération DDL, entraînant une désynchronisation des métadonnées basées sur les fichiers et des métadonnées du moteur de stockage.
Pour résoudre ce problème, MySQL 8.0 inclut l’Atomic Data Dictionary, qui stocke toutes les métadonnées dans un ensemble de tables InnoDB internes dans le schéma `mysql`. Cette nouvelle architecture fournit une méthode transactionnelle conforme à l’[ACID](https://en.wikipedia.org/wiki/ACID) pour gérer les métadonnées des bases de données, résolvant ainsi le problème de « DDL atomique » rencontré par l’ancienne approche basée sur les fichiers. Pour plus d’informations sur l’Atomic Data Dictionary, consultez [Suppression du stockage de métadonnées basé sur des fichiers](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) et [Prise en charge des instructions de définition de données atomiques](https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html) dans le *manuel de référence MySQL*.
En raison de cette modification d’architecture, vous devez tenir compte des points suivants lors de la mise à niveau d’Aurora MySQL version 2 vers la version 3 :
+ Les métadonnées basées sur les fichiers dans la version 2 doivent être migrées vers les nouvelles tables du dictionnaire de données lors du processus de mise à niveau vers la version 3. Selon le nombre d’objets de base de données migrés, cela peut prendre un certain temps.
+ Les modifications ont également introduit de nouvelles incompatibilités qui devront peut-être être corrigées avant de pouvoir passer de MySQL 5.7 à 8.0. Par exemple, la version 8.0 contient de nouveaux mots clés réservés susceptibles d’entrer en conflit avec les noms d’objets de base de données existants.
Pour vous aider à identifier ces incompatibilités avant de mettre à niveau le moteur, Aurora MySQL exécute une série de vérification de la compatibilité des mises à niveau (vérifications préalables) afin de déterminer s’il existe des objets incompatibles dans votre dictionnaire de base de données, avant d’effectuer la mise à niveau du dictionnaire de données. Pour plus d’informations sur ces vérifications préalables, consultez [Vérifications préalables aux mises à niveau de version majeure pour Aurora MySQL](AuroraMySQL.upgrade-prechecks.md).
## Différences de fonctions entre Aurora MySQL version 2 et 3
Les fonctions Amazon Aurora MySQL suivantes sont prises en charge dans Aurora MySQL pour MySQL 5.7, mais pas dans Aurora MySQL pour MySQL 8.0 :
+ Vous ne pouvez pas utiliser Aurora MySQL version 3 pour les clusters Aurora Serverless v1. Aurora MySQL version 3 fonctionne avec Aurora Serverless v2.
+ Le mode laboratoire ne s’applique pas à Aurora MySQL version 3. Il n’existe aucune fonctionnalité de mode laboratoire dans Aurora MySQL version 3. Le DDL instantané remplace la fonction DDL en ligne rapide qui était précédemment disponible en mode laboratoire. Pour obtenir un exemple, consultez [Instant DDL (Aurora MySQL version 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl).
+ Le cache de requêtes est supprimé de MySQL 8.0 version communautaire et d’Aurora MySQL version 3.
+ Aurora MySQL version 3 est compatible avec la fonction Joindre par hachage de MySQL version communautaire. L' Aurora-specific implémentation des jointures par hachage dans Aurora MySQL version 2 n'est pas utilisée. Pour plus d’informations sur l’utilisation des jointures de hachage avec une requête parallèle Aurora, consultez [Activation de la jointure par hachage pour les clusters de requête parallèle](aurora-mysql-parallel-query-enabling.md#aurora-mysql-parallel-query-enabling-hash-join) et [Indicateurs Aurora MySQL](AuroraMySQL.Reference.Hints.md). Pour obtenir des informations générales sur l’utilisation des jointures de hachage, consultez [Optimisation des jointures de hachage](https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html) dans le *manuel de référence MySQL*.
+ La procédure `mysql.lambda_async` stockée rendue obsolète dans Aurora MySQL version 2 est supprimée dans la version 3. Pour la version 3, utilisez la fonction asynchrone `lambda_async` à la place.
+ Le jeu de caractères par défaut dans Aurora MySQL version 3 est `utf8mb4`. Dans Aurora MySQL version 2, le jeu de caractères par défaut était `latin1`. *Pour plus d'informations sur ce jeu de caractères, consultez [le jeu de caractères utf8mb4 (encodage UTF-8 Unicode 4 octets) dans](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html) le manuel de référence MySQL.*
Certaines fonctionnalités d'Aurora MySQL sont disponibles pour certaines combinaisons de AWS régions et de versions du moteur de base de données. Pour en savoir plus, consultez [Fonctionnalités prises en charge dans Amazon Aurora by Région AWS et dans le moteur de base de données Aurora](Concepts.AuroraFeaturesRegionsDBEngines.grids.md).
## Assistance pour les classes d’instance
Aurora MySQL version 3 prend en charge un ensemble de classes d’instance différent de celui d’Aurora MySQL version 2 :
+ Pour les instances plus volumineuses, vous pouvez utiliser les classes d’instance modernes telles que `db.r5`, `db.r6g` et `db.x2g`.
+ Pour les instances plus petites, vous pouvez utiliser les classes d’instance modernes telles que `db.t3` et `db.t4g`.
**Note**
Nous recommandons d’utiliser les classes d’instance de base de données T uniquement pour les serveurs de développement et de test, ou pour d’autres serveurs non dédiés à la production. Pour plus de détails sur les classes d’instance T, consultez [Utilisation de classes d’instance T pour le développement et les tests](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium).
Les classes d’instance suivantes d’Aurora MySQL version 2 ne sont pas disponibles pour Aurora MySQL version 3 :
+ `db.r4`
+ `db.r3`
+ `db.t3.small`
+ `db.t2`
Dans vos scripts d’administration, vérifiez les instructions CLI qui créent des instances de base de données Aurora MySQL. Codez en dur les noms de classes d’instance non disponibles pour Aurora MySQL version 3. Si nécessaire, modifiez les noms de classes d’instance par ceux pris en charge par Aurora MySQL version 3.
**Astuce**
Pour vérifier les classes d'instance que vous pouvez utiliser pour une combinaison spécifique de version et de AWS région d'Aurora MySQL, utilisez la `describe-orderable-db-instance-options` AWS CLI commande.
Pour plus d’informations sur les classes d’instance Aurora, consultez [Classes d'instances de base de données Amazon Aurora](Concepts.DBInstanceClass.md).
## Modifications des paramètres d’Aurora MySQL version 3
Aurora MySQL version 3 inclut de nouveaux paramètres de configuration au niveau du cluster et de l’instance. Aurora MySQL version 3 supprime également certains paramètres présents dans Aurora MySQL version 2. Certains noms de paramètres sont modifiés suite à l’initiative visant un langage inclusif. Pour des raisons de compatibilité ascendante, vous pouvez toujours récupérer les valeurs des paramètres à l’aide des anciens noms ou des nouveaux noms. Toutefois, vous devez utiliser les nouveaux noms pour spécifier des valeurs de paramètres dans un groupe de paramètres personnalisés.
Dans Aurora MySQL version 3, la valeur du paramètre `lower_case_table_names` est définie de façon permanente au moment de la création du cluster. Si vous utilisez une autre valeur que la valeur par défaut pour cette option, configurez votre groupe de paramètres personnalisés Aurora MySQL version 3 avant la mise à niveau. Spécifiez ensuite le groupe de paramètres pendant l’opération de création de cluster ou de restauration d’instantanés.
**Note**
Avec une base de données globale Aurora basée sur Aurora MySQL, vous ne pouvez pas effectuer une mise à niveau sur place d’Aurora MySQL version 2 vers la version 3 si le paramètre `lower_case_table_names` est activé. Utilisez plutôt la méthode de restauration des instantanés.
Dans Aurora MySQL version 3, les paramètres `init_connect` et `read_only` ne s’appliquent pas aux utilisateurs disposant du privilège `CONNECTION_ADMIN`. Cela inclut l’utilisateur principal d’Aurora. Pour plus d’informations, consultez [Role-based modèle de privilège](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model).
Pour obtenir la liste de tous les paramètres du cluster Aurora MySQL, consultez [Cluster-level paramètres](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Cluster). Le tableau couvre tous les paramètres d’Aurora MySQL versions 2 et 3. Le tableau contient des notes indiquant les nouveaux paramètres dans Aurora MySQL version 3 ou ceux qui ont été supprimés d’Aurora MySQL version 3.
Pour obtenir la liste complète de tous les paramètres de l’instance Aurora MySQL, consultez [Instance-level paramètres](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Instance). Le tableau couvre tous les paramètres d’Aurora MySQL versions 2 et 3. Le tableau contient des notes indiquant les nouveaux paramètres dans Aurora MySQL version 3 et ceux qui ont été supprimés d’Aurora MySQL version 3. Il contient également des notes indiquant les paramètres modifiables dans les versions antérieures, mais pas Aurora MySQL version 3.
Pour plus d’informations sur les noms de paramètres modifiés, consultez [Changements linguistiques inclusifs pour Aurora MySQL version 3](#AuroraMySQL.8.0-inclusive-language).
## Variables d’état
Pour plus d’informations sur les variables d’état non applicables à Aurora MySQL, consultez [Variables d’état MySQL ne s’appliquant pas à Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md#AuroraMySQL.Reference.StatusVars.Inapplicable).
## Changements linguistiques inclusifs pour Aurora MySQL version 3
Aurora MySQL version 3 est compatible avec la version 8.0.23 de MySQL Community Edition. Aurora MySQL version 3 inclut également des modifications depuis MySQL 8.0.26 liées aux mots-clés et aux schémas de système pour un langage inclusif. Par exemple, il est préférable d’utiliser la commande `SHOW REPLICA STATUS` plutôt que la commande `SHOW SLAVE STATUS`.
Les CloudWatch métriques Amazon suivantes ont de nouveaux noms dans la version 3 d'Aurora MySQL.
Dans Aurora MySQL version 3, seuls les nouveaux noms de métriques sont disponibles. Assurez-vous de mettre à jour toutes les alarmes ou autres automatisations qui reposent sur des noms de métriques lorsque vous effectuez une mise à niveau vers Aurora MySQL version 3.
| Ancien nom | Nouveau nom |
| --- | --- |
| ForwardingMasterDMLLatency | ForwardingWriterDMLLatency |
| ForwardingMasterOpenSessions | ForwardingWriterOpenSessions |
| AuroraDMLRejectedMasterFull | AuroraDMLRejectedWriterFull |
| ForwardingMasterDMLThroughput | ForwardingWriterDMLThroughput |
Les variables d’état suivantes portent de nouveaux noms dans Aurora MySQL version 3.
Pour des raisons de compatibilité, vous pouvez utiliser l’un ou l’autre des noms dans la version initiale d’Aurora MySQL version 3. Les anciens noms de variables d’état seront supprimés dans une version ultérieure.
| Nom à supprimer | Nom nouveau ou préféré |
| --- | --- |
| Aurora\_fwd\_master\_dml\_stmt\_duration | Aurora\_fwd\_writer\_dml\_stmt\_duration |
| Aurora\_fwd\_master\_dml\_stmt\_count | Aurora\_fwd\_writer\_dml\_stmt\_count |
| Aurora\_fwd\_master\_select\_stmt\_duration | Aurora\_fwd\_writer\_select\_stmt\_duration |
| Aurora\_fwd\_master\_select\_stmt\_count | Aurora\_fwd\_writer\_select\_stmt\_count |
| Aurora\_fwd\_master\_errors\_session\_timeout | Aurora\_fwd\_writer\_errors\_session\_timeout |
| Aurora\_fwd\_master\_open\_sessions | Aurora\_fwd\_writer\_open\_sessions |
| Aurora\_fwd\_master\_errors\_session\_limit | Aurora\_fwd\_writer\_errors\_session\_limit |
| Aurora\_fwd\_master\_errors\_rpc\_timeout | Aurora\_fwd\_writer\_errors\_rpc\_timeout |
Les paramètres de configuration suivants portent de nouveaux noms dans Aurora MySQL version 3.
Pour des raisons de compatibilité, vous pouvez vérifier les valeurs des paramètres dans le client `mysql` en utilisant l’un ou l’autre des noms dans la version initiale d’Aurora MySQL version 3. Vous pouvez uniquement utiliser les nouveaux noms lorsque vous modifiez les valeurs dans un groupe de paramètres personnalisés. Les anciens noms de paramètres seront supprimés dans une version ultérieure.
| Nom à supprimer | Nom nouveau ou préféré |
| --- | --- |
| aurora\_fwd\_master\_idle\_timeout | aurora\_fwd\_writer\_idle\_timeout |
| aurora\_fwd\_master\_max\_connections\_pct | aurora\_fwd\_writer\_max\_connections\_pct |
| master\_verify\_checksum | source\_verify\_checksum |
| sync\_master\_info | sync\_source\_info |
| init\_slave | init\_replica |
| rpl\_stop\_slave\_timeout | rpl\_stop\_replica\_timeout |
| log\_slow\_slave\_statements | log\_slow\_replica\_statements |
| slave\_max\_allowed\_packet | replica\_max\_allowed\_packet |
| slave\_compressed\_protocol | replica\_compressed\_protocol |
| slave\_exec\_mode | replica\_exec\_mode |
| slave\_type\_conversions | replica\_type\_conversions |
| slave\_sql\_verify\_checksum | replica\_sql\_verify\_checksum |
| slave\_parallel\_type | replica\_parallel\_type |
| slave\_preserve\_commit\_order | replica\_preserve\_commit\_order |
| log\_slave\_updates | log\_replica\_updates |
| slave\_allow\_batching | replica\_allow\_batching |
| slave\_load\_tmpdir | replica\_load\_tmpdir |
| slave\_net\_timeout | replica\_net\_timeout |
| sql\_slave\_skip\_counter | sql\_replica\_skip\_counter |
| slave\_skip\_errors | replica\_skip\_errors |
| slave\_checkpoint\_period | replica\_checkpoint\_period |
| slave\_checkpoint\_group | replica\_checkpoint\_group |
| slave\_transaction\_retries | replica\_transaction\_retries |
| slave\_parallel\_workers | replica\_parallel\_workers |
| slave\_pending\_jobs\_size\_max | replica\_pending\_jobs\_size\_max |
| pseudo\_slave\_mode | pseudo\_replica\_mode |
Les procédures enregistrées suivantes portent de nouveaux noms dans Aurora MySQL version 3.
Pour des raisons de compatibilité, vous pouvez utiliser l’un ou l’autre des noms dans la version initiale d’Aurora MySQL version 3. Les anciens noms de procédures seront supprimés dans une version ultérieure.
| Nom à supprimer | Nom nouveau ou préféré |
| --- | --- |
| mysql.rds\_set\_master\_auto\_position | mysql.rds\_set\_source\_auto\_position |
| mysql.rds\_set\_external\_master | mysql.rds\_set\_external\_source |
| mysql.rds\_set\_external\_master\_with\_auto\_position | mysql.rds\_set\_external\_source\_with\_auto\_position |
| mysql.rds\_reset\_external\_master | mysql.rds\_reset\_external\_source |
| mysql.rds\_next\_master\_log | mysql.rds\_next\_source\_log |
## Valeurs AUTO\_INCREMENT
Dans Aurora MySQL version 3, Aurora conserve la valeur `AUTO_INCREMENT` pour chaque table lorsqu’elle redémarre chaque instance de base de données. Dans Aurora MySQL version 2, la valeur `AUTO_INCREMENT` n’était pas conservée après un redémarrage.
La valeur `AUTO_INCREMENT` n’est pas conservée lorsque vous configurez un nouveau cluster en effectuant une restauration à partir d’un instantané ou une reprise ponctuelle et en clonant un cluster. Le cas échéant, la valeur `AUTO_INCREMENT` est initialisée en fonction de la valeur reposant sur la plus grande valeur de colonne de la table au moment de la création de l’instantané. Ce comportement est différent de celui de RDS pour MySQL 8.0, où la valeur `AUTO_INCREMENT` est conservée pendant ces opérations.
## Réplication de journaux binaires
Dans la version 8.0 de MySQL Community Edition, la réplication des journaux binaires est activée par défaut. Dans Aurora MySQL version 3, la réplication des journaux binaires est désactivée par défaut.
**Astuce**
Si vos exigences en matière de haute disponibilité sont satisfaites par les fonctions de réplication intégrées à Aurora, vous pouvez laisser la réplication des journaux binaires désactivée. De cette façon, vous pouvez éviter la surcharge de performances de la réplication des journaux binaires. Vous pouvez également éviter la surveillance et le dépannage associés nécessaires à la gestion de la réplication des journaux binaires.
Aurora prend en charge la réplication de journaux binaires depuis une source compatible MySQL 5.7 vers Aurora MySQL version 3. Le système source peut être un cluster de bases de données Aurora MySQL, une instance de base de données RDS pour MySQL ou une instance MySQL sur site.
Tout comme MySQL version communautaire, Aurora MySQL prend en charge la réplication depuis une source exécutant une version spécifique vers une cible exécutant la même version majeure ou une version majeure supérieure. Par exemple, la réplication depuis un système compatible MySQL 5.6 vers Aurora MySQL version 3 n’est pas prise en charge. La réplication depuis Aurora MySQL version 3 vers un système compatible MySQL 5.7 ou MySQL 5.6 n’est pas prise en charge. Pour plus d’informations sur l’utilisation de la réplication des journaux binaires, consultez [Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires)](AuroraMySQL.Replication.MySQL.md).
Aurora MySQL version 3 inclut des améliorations apportées à la réplication des journaux binaires dans MySQL 8.0 version communautaire, comme la réplication filtrée. Pour plus d’informations sur les améliorations apportées à MySQL 8.0 version communautaire, consultez [Comment les serveurs évaluent les règles de filtrage de réplication](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html) dans le *manuel de référence MySQL*.
### Compression des transactions pour la réplication des journaux binaires
Pour plus d’informations sur l’utilisation de la compression des journaux binaires, consultez [Compression des transactions de journaux binaires](https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compression.html)dans le manuel de référence MySQL.
Les limitations suivantes s’appliquent à la compression des journaux binaires dans Aurora MySQL version 3 :
+ Les transactions dont les données de journaux binaires sont supérieures à la taille de paquet maximale autorisée ne sont pas compressées. Ceci est vrai, que le paramètre de compression des journaux binaires Aurora MySQL soit activé ou non. Ces transactions sont répliquées sans être compressées.
+ Si vous utilisez un connecteur CDC (Change Data Capture) qui ne prend pas encore en charge MySQL 8.0, vous ne pouvez pas utiliser cette fonction. Nous vous recommandons de tester minutieusement tous les connecteurs tiers avec une compression de journaux binaires. Nous vous recommandons également de le faire avant d’activer la compression des journaux binaires sur les systèmes qui utilisent la réplication des journaux binaires pour CDC.