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 entre Aurora My SQL version 2 et Aurora My SQL version 3
Utilisez ce qui suit pour en savoir plus sur les modifications à prendre en compte lors de la mise à niveau de votre cluster Aurora My SQL version 2 vers la version 3.
Rubriques
Support du langage de définition des données atomiques (DDL)
L'un des changements les plus importants entre My SQL 5.7 et 8.0 est l'introduction du dictionnaire de données atomiques
Pour résoudre ce problème, My SQL 8.0 a introduit l'Atomic Data Dictionary, qui stocke toutes les métadonnées dans un ensemble de tables InnoDB internes du mysql schéma. Cette nouvelle architecture fournit un moyen transactionnel ACID
En raison de cette modification architecturale, vous devez prendre en compte les points suivants lors de la mise à niveau d'Aurora My SQL version 2 vers la version 3 :
-
Les métadonnées basées sur des fichiers de 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 My SQL 5.7 à la version 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 My SQL exécute une série de contrôles de compatibilité des mises à niveau (prévérifications) afin de déterminer s'il existe des objets incompatibles dans votre dictionnaire de base de données, avant de procéder à la mise à niveau du dictionnaire de données. Pour plus d'informations sur les prévérifications, consultez Prévérifications de mise à niveau des versions majeures pour Aurora My SQL.
Différences de fonctionnalités entre les SQL versions 2 et 3 d'Aurora My
Les SQL fonctionnalités Amazon Aurora My suivantes sont prises en charge dans Aurora My SQL for My SQL 5.7, mais elles ne le sont pas dans Aurora My SQL for My SQL 8.0 :
-
Vous ne pouvez pas utiliser Aurora My SQL version 3 pour Aurora Serverless clusters v1. Aurora My SQL version 3 fonctionne avec Aurora Serverless v2.
-
Le mode Lab ne s'applique pas à Aurora My SQL version 3. La SQL version 3 d'Aurora My ne comporte aucune fonctionnalité en mode laboratoire. Instant DDL remplace la DDL fonctionnalité en ligne rapide qui était auparavant disponible en mode laboratoire. Pour obtenir un exemple, consultez Instant DDL (Aurora MySQL version 3).
-
Le cache de requêtes est supprimé de la communauté My SQL 8.0 ainsi que d'Aurora My SQL version 3.
-
SQLLa version 3 d'Aurora My est compatible avec la fonctionnalité communautaire My SQL hash join. L'implémentation spécifique à Aurora des jointures par hachage dans Aurora My SQL 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 et Aurora Mes SQL conseils. Pour obtenir des informations générales sur l'utilisation des jointures par hachage, consultez la section Optimisation des jointures par hachage
dans le manuel My SQL Reference Manual. -
La procédure
mysql.lambda_asyncstockée qui était obsolète dans Aurora My SQL version 2 est supprimée dans la version 3. Pour la version 3, utilisez la fonction asynchronelambda_asyncà la place. -
Le jeu de caractères par défaut dans Aurora My SQL version 3 est
utf8mb4. Dans Aurora My SQL version 2, le jeu de caractères par défaut étaitlatin1. Pour plus d'informations sur ce jeu de caractères, voir Le jeu de caractères utf8mb4 (codage Unicode 4 octets UTF -8)dans le manuel My Reference Manual. SQL
Certaines SQL fonctionnalités d'Aurora My sont disponibles pour certaines combinaisons de AWS régions et de versions du moteur de base de données. Pour plus de détails, consultez Fonctionnalités prises en charge dans Amazon Aurora by Région AWS et dans le moteur de base de données Aurora.
Assistance pour les classes d'instance
Aurora My SQL version 3 prend en charge un ensemble de classes d'instance différent de celui d'Aurora My SQL version 2 :
-
Pour les instances plus volumineuses, vous pouvez utiliser les classes d'instances modernes telles que
db.r5,db.r6getdb.x2g. -
Pour les instances plus petites, vous pouvez utiliser les classes d'instances modernes telles que
db.t3etdb.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'instances T pour le développement et les tests.
Les classes d'instance suivantes d'Aurora My SQL version 2 ne sont pas disponibles pour Aurora My SQL version 3 :
-
db.r4 -
db.r3 -
db.t3.small -
db.t2
Vérifiez que vos scripts d'administration ne contiennent aucune CLI instruction susceptible de créer des instances Aurora My SQL DB. Noms de classes d'instance codés en dur qui ne sont pas disponibles pour Aurora My SQL version 3. Si nécessaire, remplacez les noms des classes d'instance par ceux pris en charge par Aurora My SQL version 3.
Astuce
Pour vérifier les classes d'instance que vous pouvez utiliser pour une combinaison spécifique d'Aurora My SQL version et de AWS Region, utilisez la describe-orderable-db-instance-options AWS CLI commande.
Pour plus d'informations sur les classes d'instances Aurora, consultez Classes d'instances de base de données Amazon Aurora.
Changements de paramètres pour Aurora My SQL version 3
Aurora My SQL version 3 inclut de nouveaux paramètres de configuration au niveau du cluster et au niveau de l'instance. Aurora My SQL version 3 supprime également certains paramètres présents dans Aurora My SQL 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 My SQL version 3, la valeur du lower_case_table_names paramètre est définie de façon permanente au moment de la création du cluster. Si vous utilisez une valeur autre que celle par défaut pour cette option, configurez votre groupe de paramètres personnalisés Aurora My SQL version 3 avant de procéder à 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 de mise à niveau sur place de la SQL version 2 vers la version 3 d'Aurora My si le lower_case_table_names paramètre est activé. Utilisez plutôt la méthode de restauration des instantanés.
Dans Aurora My SQL version 3, les read_only paramètres init_connect et ne s'appliquent pas aux utilisateurs disposant de CONNECTION_ADMIN ce privilège. Cela inclut l'utilisateur principal d'Aurora. Pour de plus amples informations, veuillez consulter Modèle de privilège basé sur les rôles.
Pour obtenir la liste complète des paramètres du SQL cluster Aurora My, consultezParamètres de niveau cluster. Le tableau couvre tous les paramètres des SQL versions 2 et 3 d'Aurora My. Le tableau inclut des notes indiquant quels paramètres sont nouveaux dans Aurora My SQL version 3 ou ont été supprimés d'Aurora My SQL version 3.
Pour obtenir la liste complète des paramètres de l'SQLinstance Aurora My, consultezParamètres de niveau instance. Le tableau couvre tous les paramètres des SQL versions 2 et 3 d'Aurora My. Le tableau inclut des notes indiquant quels paramètres sont nouveaux dans Aurora My SQL version 3 et quels paramètres ont été supprimés d'Aurora My SQL version 3. Il inclut également des notes indiquant quels paramètres étaient modifiables dans les versions antérieures, mais pas dans Aurora My SQL version 3.
Pour plus d'informations sur les noms de paramètres modifiés, consultez Changements linguistiques inclusifs pour la SQL version 3 d'Aurora My.
Variables de statut
Pour plus d'informations sur les variables d'état qui ne s'appliquent pas à Aurora MySQL, consultezMes variables SQL d'état qui ne s'appliquent pas à Aurora My SQL.
Changements linguistiques inclusifs pour la SQL version 3 d'Aurora My
SQLLa version 3 d'Aurora My est compatible avec la version 8.0.23 de l'édition My SQL community. SQLLa version 3 d'Aurora My inclut également des modifications par rapport à My SQL 8.0.26 relatives aux mots clés et aux schémas du 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 Aurora My SQL version 3.
Dans Aurora My SQL version 3, seuls les nouveaux noms de métriques sont disponibles. Assurez-vous de mettre à jour toutes les alarmes ou autres automatismes qui reposent sur des noms de métriques lors de la mise à niveau vers Aurora My SQL version 3.
| Ancien nom | Nouveau nom |
|---|---|
ForwardingMasterDMLLatency
|
ForwardingWriterDMLLatency
|
ForwardingMasterOpenSessions
|
ForwardingWriterOpenSessions
|
AuroraDMLRejectedMasterFull
|
AuroraDMLRejectedWriterFull
|
ForwardingMasterDMLThroughput
|
ForwardingWriterDMLThroughput
|
Les variables d'état suivantes ont de nouveaux noms dans Aurora My SQL version 3.
Pour des raisons de compatibilité, vous pouvez utiliser l'un ou l'autre nom dans la version initiale d'Aurora My SQL 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 ont de nouveaux noms dans Aurora My SQL version 3.
Pour des raisons de compatibilité, vous pouvez vérifier les valeurs des paramètres dans le mysql client en utilisant l'un ou l'autre des noms dans la version initiale d'Aurora My SQL 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 stockées suivantes ont de nouveaux noms dans Aurora My SQL version 3.
Pour des raisons de compatibilité, vous pouvez utiliser l'un ou l'autre nom dans la version initiale d'Aurora My SQL 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
|
AUTO_ INCREMENT valeurs
Dans Aurora My SQL version 3, Aurora conserve la AUTO_INCREMENT valeur de chaque table lorsqu'elle redémarre chaque instance de base de données. Dans Aurora My SQL version 2, la AUTO_INCREMENT valeur n'était pas conservée après un redémarrage.
La AUTO_INCREMENT valeur n'est pas préservée lorsque vous configurez un nouveau cluster en effectuant une restauration à partir d'un instantané, en effectuant une point-in-time restauration 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 RDS de My SQL 8.0, où la AUTO_INCREMENT valeur est préservée pendant ces opérations.
Réplication de journaux binaires
Dans l'édition communautaire My SQL 8.0, la réplication des journaux binaires est activée par défaut. Dans Aurora My SQL 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 SQL compatible avec My 5.7 vers Aurora My SQL version 3. Le système source peut être un cluster Aurora My SQL DB, une instance RDS for My SQL DB ou une SQL instance My sur site.
Tout comme Community MySQL, Aurora My SQL 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 d'un système SQL compatible My 5.6 vers Aurora My SQL version 3 n'est pas prise en charge. La réplication d'Aurora My SQL version 3 vers un système SQL compatible My 5.7 ou My SQL 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 My SQL ou entre Aurora et un autre cluster de base de données Aurora (réplication de journaux binaires).
SQLLa version 3 d'Aurora My inclut des améliorations apportées à la réplication des journaux binaires dans Community My SQL 8.0, telles que la réplication filtrée. Pour en savoir plus sur les améliorations apportées à My SQL 8.0 par la communauté, consultez la section Comment les serveurs évaluent les règles de filtrage de réplication
Compression des transactions pour la réplication des journaux binaires
Pour plus d'informations sur l'utilisation de la compression des journaux binaires, consultez la section Compression des transactions des journaux binaires
Les limitations suivantes s'appliquent à la compression des journaux binaires dans Aurora My SQL 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. Cela est vrai que le paramètre de compression des journaux SQL binaires Aurora My soit activé ou non. Ces transactions sont répliquées sans être compressées.
-
Si vous utilisez un connecteur pour la capture des données de modification (CDC) qui n'est pas encore compatible avec My SQL 8.0, vous ne pouvez pas utiliser cette fonctionnalité. 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
