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 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.
Rubriques
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).
-
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'implémentation spécifique à Aurora des jointures de 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 et Indicateurs Aurora MySQL. Pour obtenir des informations générales sur l'utilisation des jointures de hachage, consultez Optimisation des jointures de hachage
dans le manuel de référence MySQL. -
La procédure
mysql.lambda_asyncstockée rendue obsolète dans Aurora MySQL 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 MySQL version 3 est
utf8mb4. Dans Aurora MySQL version 2, le jeu de caractères par défaut étaitlatin1. Pour plus d'informations sur ce jeu de caractères, consultez Jeu de caractères utf8mb4 (encodage Unicode 4 octets en UTF-8)dans 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 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 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'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 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'instances Aurora, consultez Classes d'instances de base de données Aurora.
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 Modèle de privilège basé sur les rôles.
Pour obtenir la liste de tous les paramètres du cluster Aurora MySQL, consultez Paramètres de niveau 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 Paramètres de niveau 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.
Variables de statut
Pour plus d'informations sur les variables de statut non applicables à Aurora MySQL, consultez Variables d'état MySQL ne s'appliquant pas à Aurora MySQL.
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 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 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).
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
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
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.
