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. # Référence Amazon Aurora MySQL Cette référence inclut des informations sur les paramètres Aurora MySQL, les variables d’état et les extensions SQL générales ou les différences avec le moteur de base de données MySQL de la communauté. **Topics** + [Paramètres de configuration d’Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md) + [Variables d’état globales Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md) + [Événements d’attente Aurora MySQL](AuroraMySQL.Reference.Waitevents.md) + [États de thread Aurora MySQL](AuroraMySQL.Reference.thread-states.md) + [Niveaux d’isolement Aurora MySQL](AuroraMySQL.Reference.IsolationLevels.md) + [Indicateurs Aurora MySQL](AuroraMySQL.Reference.Hints.md) + [Référence des procédures stockées Aurora MySQL](AuroraMySQL.Reference.StoredProcs.md) + [Tables information\$1schema spécifiques à Aurora MySQL](AuroraMySQL.Reference.ISTables.md) # Paramètres de configuration d’Aurora MySQL Vous gérez votre cluster de bases de données Amazon Aurora MySQL de la même façon que les autres instances de base de données Amazon RDS, en utilisant les paramètres d’un groupe de paramètres de base de données. Amazon Aurora diffère des autres moteurs de base de données en ce sens que vous avez un cluster de bases de données qui contient plusieurs instances de base de données. En conséquence, certains des paramètres que vous utilisez pour gérer votre cluster de bases de données Aurora MySQL s’appliquent à l’ensemble du cluster. D’autres paramètres s’appliquent uniquement à une instance de base de données spécifique du cluster de bases de données. Pour gérer les paramètres de niveau cluster, utilisez des groupes de paramètres de cluster de bases de données. Pour gérer les paramètres de niveau instance, utilisez des groupes de paramètres de base de données. Chaque instance de base de données d’un cluster de bases de données Aurora MySQL est compatible avec le moteur de base de données MySQL. Toutefois, vous devez appliquer certains paramètres du moteur de base de données MySQL au niveau du cluster et gérer ces paramètres à l’aide de groupes de paramètres de cluster de bases de données. Pour une instance située dans un cluster de bases de données Aurora, vous ne pouvez pas trouver les paramètres de niveau cluster dans le groupe de paramètres de base de données. Plus loin dans cette rubrique, vous trouverez une liste des paramètres de niveau cluster. Vous pouvez gérer les paramètres de niveau cluster et de niveau instance à l’aide de l’AWS Management Console, de l’AWS CLI ou de l’API Amazon RDS. Vous pouvez utiliser des commandes distinctes pour gérer les paramètres de niveau cluster et les paramètres de niveau instance. Par exemple, vous pouvez utiliser la commande CLI [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html) pour gérer les paramètres de niveau cluster dans un groupe de paramètres de cluster de bases de données. Vous pouvez utiliser la commande [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) de l’interface de ligne de commande (CLI) pour gérer les paramètres de niveau instance dans un groupe de paramètres de cluster de bases de données dans un cluster de bases de données. Vous pouvez afficher les paramètres de niveau cluster et de niveau instance dans la console, à l’aide de l’interface de ligne de commande (CLI) ou de l’API RDS. Par exemple, vous pouvez utiliser la commande de l’AWS CLI [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) pour afficher les paramètres de niveau cluster dans un groupe de paramètres de cluster de bases de données. Vous pouvez utiliser la commande [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) de l’interface de ligne de commande (CLI) pour afficher les paramètres de niveau instance dans un groupe de paramètres de cluster de bases de données dans un cluster de bases de données. **Note** Chaque [groupe de paramètres par défaut ](USER_WorkingWithParamGroups.md) contient les valeurs par défaut de tous les paramètres du groupe de paramètres. Si le paramètre est « engine default » (moteur par défaut) pour cette valeur, consultez la documentation MySQL ou PostgreSQL spécifique à la version pour connaître la valeur par défaut réelle. Sauf indication contraire, les paramètres répertoriés dans les tables suivantes sont valides pour Aurora MySQL versions 2 et 3. Pour plus d’informations sur les groupes de paramètres DB, consultez [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md). Pour obtenir les règles et les instructions pour les clusters Aurora Serverless v1, consultez [Groupes de paramètres pour Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups). **Topics** + [Paramètres de niveau cluster](#AuroraMySQL.Reference.Parameters.Cluster) + [Paramètres de niveau instance](#AuroraMySQL.Reference.Parameters.Instance) + [Paramètres MySQL ne s’appliquant pas à Aurora MySQL](#AuroraMySQL.Reference.Parameters.Inapplicable) ## Paramètres de niveau cluster Le tableau suivant affiche tous les paramètres qui s’appliquent à la totalité du cluster de bases de données Aurora MySQL. | Nom du paramètre | Adaptabilité | Remarques | | --- | --- | --- | | `aurora_binlog_read_buffer_size` | Oui | Affecte uniquement les clusters qui utilisent la réplication de journal binaire (binlog). Pour plus d’informations sur la réplication de journal binaire, 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). Supprimé d’Aurora MySQL version 3. | | `aurora_binlog_replication_max_yield_seconds` | Oui | Affecte uniquement les clusters qui utilisent la réplication de journal binaire (binlog). Pour plus d’informations sur la réplication de journal binaire, 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_binlog_replication_sec_index_parallel_workers` | Oui | Définit le nombre total de threads parallèles disponibles pour appliquer les modifications d’index secondaires lors de la réplication de transactions pour de grandes tables comportant plusieurs index secondaires. Par défaut, ce paramètre est défini sur `0` (désactivé). Ce paramètre est disponible dans Aurora MySQL version 306 et versions ultérieures. Pour plus d’informations, consultez [Optimisation de la réplication des journaux binaires pour Aurora MySQL](binlog-optimization.md). | | `aurora_binlog_use_large_read_buffer` | Oui | Affecte uniquement les clusters qui utilisent la réplication de journal binaire (binlog). Pour plus d’informations sur la réplication de journal binaire, 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). Supprimé d’Aurora MySQL version 3. | | `aurora_disable_hash_join` | Oui | Définissez ce paramètre sur `ON` pour désactiver l’optimisation de jointure par hachage dans Aurora MySQL version 2.09 ou ultérieure. Il n’est pas pris en charge pour la version 3. Pour plus d’informations, consultez [Requêtes parallèles pour Amazon Aurora MySQL](aurora-mysql-parallel-query.md). | | `aurora_enable_replica_log_compression` | Oui | Pour plus d’informations, consultez [Considérations sur les performances pour la réplication Amazon Aurora MySQL](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance). Ne s’applique pas aux clusters qui font partie d’une base de données globale Aurora. Supprimé d’Aurora MySQL version 3. | | `aurora_enable_repl_bin_log_filtering` | Oui | Pour plus d’informations, consultez [Considérations sur les performances pour la réplication Amazon Aurora MySQL](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance). Ne s’applique pas aux clusters qui font partie d’une base de données globale Aurora. Supprimé d’Aurora MySQL version 3. | | `aurora_enable_staggered_replica_restart` | Oui | Ce paramètre est disponible dans Aurora MySQL version 3, mais il n’est pas utilisé. | | `aurora_enable_zdr` | Oui | Ce paramètre est activé par défaut dans Aurora MySQL versions 2.10 et ultérieures. | | `aurora_in_memory_relaylog` | Oui | Définit le mode journal de relais en mémoire. Vous pouvez utiliser cette fonctionnalité sur les réplicas de journaux binaires pour améliorer les performances de réplication des journaux binaires. Pour désactiver cette fonctionnalité, définissez ce paramètre sur OFF. Pour activer cette fonctionnalité, définissez ce paramètre sur ON. | | `aurora_enhanced_binlog` | Oui | Définissez la valeur de ce paramètre sur 1 pour activer le binlog amélioré dans Aurora MySQL versions 3.03.1 et ultérieures. Pour plus d’informations, consultez [Configuration du binlog amélioré pour Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). | | `aurora_full_double_precision_in_json` | Oui | Définissez la valeur de ce paramètre pour permettre l’analyse des nombres à virgule flottante dans les documents JSON avec une précision totale. | | `aurora_jemalloc_background_thread` | Oui | Utilisez ce paramètre pour permettre à un thread d’arrière-plan d’effectuer des opérations de maintenance de la mémoire. Les valeurs autorisées sont `0` (désactivé) et `1` (activé). La valeur par défaut est `0`. Ce paramètre s’applique à Aurora MySQL versions 3.05 et ultérieures. | | `aurora_jemalloc_dirty_decay_ms` | Oui | Utilisez ce paramètre pour conserver la mémoire libérée pendant un certain temps (en millisecondes). La conservation de la mémoire permet une réutilisation plus rapide. Les valeurs autorisées sont `0`–`18446744073709551615`. La valeur par défaut est `10000` (10 secondes). Vous pouvez utiliser un délai plus court pour éviter les problèmes de mémoire insuffisante, au détriment de performances plus lentes. Ce paramètre s’applique à Aurora MySQL versions 3.05 et ultérieures. | | `aurora_jemalloc_tcache_enabled` | Oui | Utilisez ce paramètre pour traiter les faibles demandes de mémoire (jusqu’à 32 Kio) dans un cache local de thread, en contournant les arènes de mémoire. Les valeurs autorisées sont `0` (désactivé) et `1` (activé). La valeur par défaut est `1`. Ce paramètre s’applique à Aurora MySQL versions 3.05 et ultérieures. | | `aurora_load_from_s3_role` | Oui | Pour plus d’informations, consultez [Chargement de données dans un cluster de bases de données Amazon Aurora MySQL à partir de fichiers texte stockés dans un compartiment Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md). Actuellement non disponible dans Aurora MySQL version 3. Utilisez `aws_default_s3_role`. | | `aurora_mask_password_hashes_type` | Oui | Ce paramètre est activé par défaut dans Aurora MySQL versions 2.11 et ultérieures. Utilisez ce paramètre pour masquer les hachages de mot de passe Aurora MySQL dans les journaux de requêtes lentes et d’audit. Les valeurs autorisées sont `0` et `1` (par défaut). Lorsque ce paramètre est défini sur `1`, les mots de passe sont enregistrés comme ``. Lorsque ce paramètre est défini sur `0`, les mots de passe sont enregistrés sous forme de valeurs de hachage (`#`). | | `aurora_select_into_s3_role` | Oui | Pour plus d’informations, consultez [Enregistrement de données d’un cluster de bases de données Amazon Aurora MySQL dans des fichiers texte stockés dans un compartiment Amazon S3](AuroraMySQL.Integrating.SaveIntoS3.md). Actuellement non disponible dans Aurora MySQL version 3. Utilisez `aws_default_s3_role`. | | `authentication_kerberos_caseins_cmp` | Oui | Contrôle la comparaison des noms d’utilisateur sans distinction de casse pour le plug-in `authentication_kerberos`. Définissez-le sur `true` pour une comparaison sans distinction de casse. Par défaut, la comparaison sensible à la casse est utilisée (`false`). Pour plus d’informations, consultez [Utilisation de l'authentification Kerberos pour Aurora MySQL](aurora-mysql-kerberos.md). Ce paramètre est disponible dans Aurora MySQL version 3.03 et versions ultérieures. | | `auto_increment_increment` | Oui | Aucun | | `auto_increment_offset` | Oui | Aucun | | `aws_default_lambda_role` | Oui | Pour plus d’informations, consultez [Appel d’une fonction Lambda à partir d’un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Integrating.Lambda.md). | | `aws_default_s3_role` | Oui | Utilisé lors de l’appel de l’instruction `LOAD DATA FROM S3`, `LOAD XML FROM S3` ou `SELECT INTO OUTFILE S3` à partir de votre cluster de bases de données. Dans Aurora MySQL version 2, le rôle IAM spécifié dans ce paramètre est utilisé si un rôle IAM n’est pas spécifié pour `aurora_load_from_s3_role` ou `aurora_select_into_s3_role` pour l’instruction appropriée. Dans Aurora MySQL version 3, le rôle IAM spécifié pour ce paramètre est toujours utilisé. Pour plus d’informations, consultez [Association d'un rôle IAM à un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Integrating.Authorizing.IAM.AddRoleToDBCluster.md). | | `binlog_backup` | Oui | Définissez la valeur de ce paramètre sur 0 pour activer le binlog amélioré dans Aurora MySQL versions 3.03.1 et ultérieures. Vous ne pouvez désactiver ce paramètre que lorsque vous utilisez le binlog amélioré. Pour plus d’informations, consultez [Configuration du binlog amélioré pour Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). | | `binlog_checksum` | Oui | La AWS CLI et l’API RDS indiquent la valeur `None` si ce paramètre n’est pas défini. Dans ce cas, Aurora MySQL utilise la valeur par défaut du moteur, qui est `CRC32`. Ceci est différent du paramétrage explicite de `NONE`, qui désactive le total de contrôle. | | `binlog-do-db` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `binlog_format` | Oui | Pour plus d’informations, 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). | | `binlog_group_commit_sync_delay` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `binlog_group_commit_sync_no_delay_count` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `binlog-ignore-db` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `binlog_replication_globaldb` | Oui | Définissez la valeur de ce paramètre sur 0 pour activer le binlog amélioré dans Aurora MySQL versions 3.03.1 et ultérieures. Vous ne pouvez désactiver ce paramètre que lorsque vous utilisez le binlog amélioré. Pour plus d’informations, consultez [Configuration du binlog amélioré pour Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). | | `binlog_row_image` | Non | Aucun | | `binlog_row_metadata` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `binlog_row_value_options` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `binlog_rows_query_log_events` | Oui | Aucun | | `binlog_transaction_compression` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `binlog_transaction_compression_level_zstd` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `binlog_transaction_dependency_history_size` | Oui | Ce paramètre définit une limite supérieure du nombre de hachages de ligne conservés en mémoire et utilisés pour rechercher la transaction qui a modifié pour la dernière fois une ligne donnée. Une fois ce nombre de hachages atteint, l’historique est purgé. Ce paramètre s’applique à Aurora MySQL versions 2.12 et ultérieures, et version 3. | | `binlog_transaction_dependency_tracking` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `character-set-client-handshake` | Oui | Aucun | | `character_set_client` | Oui | Aucun | | `character_set_connection` | Oui | Aucun | | `character_set_database` | Oui | Jeu de caractères utilisé par la base de données par défaut. La valeur par défaut est `utf8mb4`. | | `character_set_filesystem` | Oui | Aucun | | `character_set_results` | Oui | Aucun | | `character_set_server` | Oui | Aucun | | `collation_connection` | Oui | Aucun | | `collation_server` | Oui | Aucun | | `completion_type` | Oui | Aucun | | `default_storage_engine` | Non | Les clusters Aurora MySQL utilisent le moteur de stockage InnoDB pour toutes vos données. | | `enforce_gtid_consistency` | Parfois | Modifiable dans Aurora MySQL version 2 et versions ultérieures. | | `event_scheduler` | Oui | Indique l’état du planificateur d’événements. Modifiable uniquement au niveau du cluster dans Aurora MySQL version 3. | | `gtid-mode` | Parfois | Modifiable dans Aurora MySQL version 2 et versions ultérieures. | | `information_schema_stats_expiry` | Oui | Nombre de secondes après lesquelles le serveur de base de données MySQL récupère les données du moteur de stockage et remplace les données du cache. Les valeurs autorisées sont `0`–`31536000`. Ce paramètre s’applique à Aurora MySQL version 3. | | `init_connect` | Oui | La commande à exécuter par le serveur pour chaque client qui se connecte. Utilisez des guillemets (") pour les paramètres afin d’éviter les échecs de connexion, par exemple : 
SET optimizer_switch="hash_join=off"
Dans Aurora MySQL version 3, ce paramètre ne s’applique 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](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). | | `innodb_adaptive_hash_index` | Oui | Vous pouvez modifier ce paramètre au niveau du cluster de bases de données dans Aurora MySQL versions 2 et 3. L’index de hachage adaptatif n’est pas pris en charge par les instances de base de données du lecteur. | | `innodb_aurora_instant_alter_column_allowed` | Oui | Contrôle si l’algorithme `INSTANT` peut être utilisé pour des opérations `ALTER COLUMN` au niveau global. Les valeurs autorisées sont les suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Pour plus d’informations, consultez [Column Operations](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#online-ddl-column-operations) dans la documentation MySQL. Ce paramètre s’applique à Aurora MySQL versions 3.05 et ultérieures. | | `innodb_autoinc_lock_mode` | Oui | Aucun | | `innodb_checksums` | Non | Supprimé d’Aurora MySQL version 3. | | `innodb_cmp_per_index_enabled` | Oui | Aucun | | `innodb_commit_concurrency` | Oui | Aucun | | `innodb_data_home_dir` | Non | Aurora MySQL utilise des instances gérées dans lesquelles vous n’accédez pas directement au système de fichiers. | | `innodb_deadlock_detect` | Oui | Cette option permet de désactiver la détection de blocage dans Aurora MySQL version 2.11 ou ultérieure, ou version 3. Sur les systèmes à concurrence élevée, la détection de blocage peut entraîner un ralentissement lorsque de nombreux threads attendent le même verrouillage. Pour plus d’informations sur ce paramètre, consultez la documentation MySQL. | | `innodb_default_row_format` | Oui | Ce paramètre définit le format de ligne par défaut pour les tables InnoDB (y compris les tables temporaires InnoDB créées par l’utilisateur). Il s’applique aux versions 2 et 3 d’Aurora MySQL. Ses valeurs peuvent être `DYNAMIC`, `COMPACT` ou `REDUNDANT.` | | `innodb_file_per_table` | Oui | Ce paramètre affecte la façon dont le stockage de table est organisé. Pour plus d’informations, consultez [Dimensionnement du stockage](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling). | | `innodb_flush_log_at_trx_commit` | Oui | Nous vous recommandons de conserver la valeur par défaut `1`. Dans Aurora MySQL version 3, avant de pouvoir attribuer à ce paramètre une valeur autre que `1`, vous devez définir la valeur de `innodb_trx_commit_allow_data_loss` sur `1`. Pour plus d’informations, consultez [Configuration de la fréquence à laquelle le tampon du journal est vidé](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). | | `innodb_ft_max_token_size` | Oui | Aucun | | `innodb_ft_min_token_size` | Oui | Aucun | | `innodb_ft_num_word_optimize` | Oui | Aucun | | `innodb_ft_sort_pll_degree` | Oui | Aucun | | `innodb_online_alter_log_max_size` | Oui | Aucun | | `innodb_optimize_fulltext_only` | Oui | Aucun | | `innodb_page_size` | Non | Aucun | | `innodb_print_all_deadlocks` | Oui | Lorsque ce paramètre est activé, les informations relatives à tous les blocages InnoDB sont enregistrées dans le journal des erreurs Aurora MySQL. Pour plus d’informations, consultez [Minimisation et résolution des blocages d’Aurora MySQL](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks). | | `innodb_purge_batch_size` | Oui | Aucun | | `innodb_purge_threads` | Oui | Aucun | | `innodb_rollback_on_timeout` | Oui | Aucun | | `innodb_rollback_segments` | Oui | Aucun | | `innodb_spin_wait_delay` | Oui | Aucun | | `innodb_strict_mode` | Oui | Aucun | | `innodb_support_xa` | Oui | Supprimé d’Aurora MySQL version 3. | | `innodb_sync_array_size` | Oui | Aucun | | `innodb_sync_spin_loops` | Oui | Aucun | | `innodb_stats_include_delete_marked` | Oui | Lorsque ce paramètre est activé, InnoDB inclut les enregistrements marqués pour suppression lors du calcul des statistiques persistantes de l’optimiseur. Ce paramètre s’applique à Aurora MySQL versions 2.12 et ultérieures, et version 3. | | `innodb_table_locks` | Oui | Aucun | | `innodb_trx_commit_allow_data_loss` | Oui | Dans Aurora MySQL version 3, définissez la valeur de ce paramètre sur `1` afin de pouvoir modifier la valeur de `innodb_flush_log_at_trx_commit`. La valeur par défaut de `innodb_trx_commit_allow_data_loss` est `0`. Pour plus d’informations, consultez [Configuration de la fréquence à laquelle le tampon du journal est vidé](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). | | `innodb_undo_directory` | Non | Aurora MySQL utilise des instances gérées dans lesquelles vous n’accédez pas directement au système de fichiers. | | `internal_tmp_disk_storage_engine` | Oui | Contrôle quel moteur de stockage en mémoire est utilisé pour les tables temporaires internes. Les valeurs autorisées sont `INNODB` et `MYISAM`. Ce paramètre s’applique à Aurora MySQL version 2. | | `internal_tmp_mem_storage_engine` | Oui | Contrôle quel moteur de stockage en mémoire est utilisé pour les tables temporaires internes. Les valeurs autorisées sont `MEMORY` et `TempTable`. Ce paramètre s’applique à Aurora MySQL version 3. | | `key_buffer_size` | Oui | Cache de clé pour les tables MyISAM. Pour plus d’informations, consultez [keycache->cache\$1lock mutex](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock). | | `lc_time_names` | Oui | Aucun | | `log_error_suppression_list` | Oui | Spécifie une liste de codes d’erreur qui ne sont pas consignés dans le journal d’erreurs MySQL. Cela vous permet d’ignorer certaines conditions d’erreur non critiques afin de préserver l’intégrité de vos journaux d’erreurs. Pour plus d’informations, consultez [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list) dans la documentation MySQL. Ce paramètre s’applique à Aurora MySQL versions 3.03 et ultérieures. | | `low_priority_updates` | Oui | Les opérations `INSERT`, `UPDATE`, `DELETE` et `LOCK TABLE WRITE` attendent qu’il ne reste aucune opération `SELECT` en attente. Ce paramètre affecte uniquement les moteurs de stockage qui utilisent uniquement le verrouillage au niveau de la table (MyISAM, MEMORY, MERGE). Ce paramètre s’applique à Aurora MySQL version 3. | | `lower_case_table_names` | Oui (Aurora MySQL version 2) Uniquement au moment de la création du cluster (Aurora MySQL version 3) | Dans Aurora MySQL version 2.10 et versions 2.x ultérieures, veillez à redémarrer toutes les instances de lecteur après avoir modifié ce paramètre et redémarré l’instance d’enregistreur. Pour en savoir plus, consultez [Redémarrage d’un cluster Aurora avec disponibilité en lecture](aurora-mysql-survivable-replicas.md). Dans Aurora MySQL version 3, la valeur de ce paramètre est définie de façon permanente au moment de la création du cluster. Si vous utilisez une valeur autre que par défaut pour cette option, configurez votre groupe de paramètres personnalisés Aurora MySQL version 3 avant la mise à niveau, puis spécifiez le groupe de paramètres pendant l’opération de restauration des instantanés qui crée le cluster version 3. 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é. Pour plus d’informations sur les méthodes que vous pouvez utiliser, consultez [Mises à niveau de version majeure.](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major). | | `master-info-repository` | Oui | Supprimé d’Aurora MySQL version 3. | | `master_verify_checksum` | Oui | Aurora MySQL version 2. Utilisez `source_verify_checksum` dans Aurora MySQL version 3. | | `max_delayed_threads` | Oui | Définit le nombre maximal de threads pour gérer les instructions `INSERT DELAYED`. Ce paramètre s’applique à Aurora MySQL version 3. | | `max_error_count` | Oui | Nombre maximal de messages d’erreur, d’avertissement et de note à stocker pour affichage. Ce paramètre s’applique à Aurora MySQL version 3. | | `max_execution_time` | Oui | Délai d’attente pour l’exécution des instructions `SELECT`, en millisecondes. Cette valeur peut être comprise entre `0` et `18446744073709551615`. Lorsqu’elle est définie sur `0`, il n’y a aucun délai d’attente. Pour plus d’informations, consultez [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time) dans la documentation MySQL. | | `min_examined_row_limit` | Oui | Utilisez ce paramètre pour empêcher la journalisation des requêtes examinant un nombre de lignes inférieur au nombre spécifié. | | `partial_revokes` | Non | Ce paramètre s’applique à Aurora MySQL version 3. | | `preload_buffer_size` | Oui | Taille de la mémoire tampon allouée lors du préchargement des index. Ce paramètre s’applique à Aurora MySQL version 3. | | `query_cache_type` | Oui | Supprimé d’Aurora MySQL version 3. | | `read_only` | Oui | Lorsque ce paramètre est activé, le serveur n’autorise aucune mise à jour, à l’exception de celles effectuées par les threads de réplica. Pour Aurora MySQL version 2, les valeurs valides sont les suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Pour Aurora MySQL version 3, les valeurs valides sont les suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Dans Aurora MySQL version 3, ce paramètre ne s’applique 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](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). | | `relay-log-space-limit` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `replica_parallel_type` | Oui | Ce paramètre permet une exécution parallèle sur le réplica de tous les threads non validés déjà en phase de préparation, sans porter atteinte à la cohérence. Il s’applique à Aurora MySQL version 3. Dans les versions 3.03.\$1 et antérieures d’Aurora MySQL, la valeur par défaut est DATABASE. Dans les versions 3.04 et ultérieures d’Aurora MySQL, la valeur par défaut est LOGICAL\$1CLOCK. | | `replica_preserve_commit_order` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `replica_transaction_retries` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `replica_type_conversions` | Oui | Ce paramètre détermine les conversions de type utilisées sur les réplicas. Les valeurs autorisées sont `ALL_LOSSY`, `ALL_NON_LOSSY`, `ALL_SIGNED` et `ALL_UNSIGNED`. Pour plus d’informations, consultez [Réplication avec des définitions de tables différentes sur la source et le réplica](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html) (langue française non garantie) dans la documentation MySQL. Ce paramètre s’applique à Aurora MySQL version 3. | | `replicate-do-db` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `replicate-do-table` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `replicate-ignore-db` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `replicate-ignore-table` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `replicate-wild-do-table` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `replicate-wild-ignore-table` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `require_secure_transport` | Oui | Ce paramètre s’applique à Aurora MySQL versions 2 et 3. Pour plus d’informations, consultez [Connexions TLS aux clusters de bases de données Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). | | `rpl_read_size` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `server_audit_cw_upload` | Non | Ce paramètre est devenu obsolète dans Aurora MySQL. Utilisez `server_audit_logs_upload`. Pour plus d’informations, consultez [Publication de journaux Amazon Aurora MySQL dans Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `server_audit_events` | Oui | Pour plus d’informations, consultez [Utilisation de l’Audit avancé avec un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Auditing.md). | | `server_audit_excl_users` | Oui | Pour plus d’informations, consultez [Utilisation de l’Audit avancé avec un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Auditing.md). | | `server_audit_incl_users` | Oui | Pour plus d’informations, consultez [Utilisation de l’Audit avancé avec un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Auditing.md). | | `server_audit_logging` | Oui | Pour accéder aux instructions concernant le chargement de journaux dans Amazon CloudWatch Logs, consultez [Publication de journaux Amazon Aurora MySQL dans Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `server_audit_logs_upload` | Oui | Vous pouvez publier des journaux d’audit sur CloudWatch Logs en activant Audit avancé et en définissant ce paramètre sur `1`. La valeur par défaut du paramètre `server_audit_logs_upload` est `0`. Pour plus d’informations, consultez [Publication de journaux Amazon Aurora MySQL dans Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `server_id` | Non | Aucun | | `skip-character-set-client-handshake` | Oui | Aucun | | `skip_name_resolve` | Non | Aucun | | `slave-skip-errors` | Oui | S’applique uniquement aux clusters de la version 2 d’Aurora MySQL, avec compatibilité MySQL 5.7. | | `source_verify_checksum` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `sync_frm` | Oui | Supprimé d’Aurora MySQL version 3. | | `thread_cache_size` | Oui | Le nombre de threads à mettre en cache. Ce paramètre s’applique à Aurora MySQL versions 2 et 3. | | `time_zone` | Oui | Par défaut, le fuseau horaire d’un cluster de bases de données Aurora est le fuseau UTC (temps universel). Vous pouvez à la place définir le fuseau horaire des instances de votre cluster de bases de données sur le fuseau horaire local de votre application. Pour plus d’informations, consultez [Fuseau horaire local pour les clusters de bases de données Amazon Aurora](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.LocalTimeZone). | | `tls_version` | Oui | Pour plus d’informations, consultez [Versions TLS pour Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.TLS_Version). | ## Paramètres de niveau instance Le tableau suivant affiche tous les paramètres qui s’appliquent à une instance de base de données spécifique d’un cluster de bases de données Aurora MySQL. | Nom du paramètre | Adaptabilité | Remarques | | --- | --- | --- | | `activate_all_roles_on_login` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `allow-suspicious-udfs` | Non | Aucun | | `aurora_disable_hash_join` | Oui | Définissez ce paramètre sur `ON` pour désactiver l’optimisation de jointure par hachage dans Aurora MySQL version 2.09 ou ultérieure. Il n’est pas pris en charge pour la version 3. Pour plus d’informations, consultez [Requêtes parallèles pour Amazon Aurora MySQL](aurora-mysql-parallel-query.md). | | `aurora_lab_mode` | Oui | Pour plus d’informations, consultez [Mode Lab Amazon Aurora MySQL](AuroraMySQL.Updates.LabMode.md). Supprimé d’Aurora MySQL version 3. | | `aurora_oom_response` | Oui | Ce paramètre est pris en charge pour Aurora MySQL versions 2 et 3. Pour plus d’informations, consultez [Résolution des problèmes de mémoire insuffisante pour les bases de données Aurora MySQL](AuroraMySQLOOM.md). | | `aurora_parallel_query` | Oui | Définissez sur `ON` pour activer la requête parallèle dans Aurora MySQL version 2.09 ou ultérieure. L’ancien paramètre `aurora_pq` n’est pas utilisé dans ces versions. Pour plus d’informations, consultez [Requêtes parallèles pour Amazon Aurora MySQL](aurora-mysql-parallel-query.md). | | `aurora_pq` | Oui | Définissez sur `OFF` pour désactiver la requête parallèle pour des instances de base de données spécifiques dans les versions d’Aurora MySQL antérieures à 2.09. Dans la version 2.09 ou une version ultérieure, activez et désactivez la requête parallèle avec `aurora_parallel_query` à la place. Pour plus d’informations, consultez [Requêtes parallèles pour Amazon Aurora MySQL](aurora-mysql-parallel-query.md). | | `aurora_read_replica_read_committed` | Oui | Active le niveau d’isolement `READ COMMITTED` pour les réplicas Aurora et modifie le comportement d’isolement pour réduire le retard de purge pendant les requêtes de longue durée. N’activez ce paramètre que si vous maîtrisez les modifications de comportement et la façon dont ils affectent les résultats de vos requêtes. Par exemple, ce paramètre utilise un isolement moins strict que l’isolement MySQL par défaut. Lorsque le paramètre est activé, les requêtes de longue durée peuvent voir plusieurs exemplaires d’une même ligne, car Aurora réorganise les données des tables au cours de l’exécution de la requête. Pour plus d’informations, consultez [Niveaux d’isolement Aurora MySQL](AuroraMySQL.Reference.IsolationLevels.md). | | `aurora_tmptable_enable_per_table_limit` | Oui | Détermine si le paramètre `tmp_table_size` contrôle la taille maximale des tables temporaires en mémoire créées par le moteur de stockage `TempTable` dans Aurora MySQL version 3.04 ou ultérieure. Pour plus d’informations, consultez [Limitation de la taille des tables temporaires internes en mémoire](ams3-temptable-behavior.md#ams3-temptable-behavior-limit). | | `aurora_use_vector_instructions` | Oui | Lorsque ce paramètre est activé, Aurora MySQL utilise des instructions de traitement vectoriel optimisé fournies par les processeurs modernes pour améliorer les performances des charges de travail intensives en E/S. Ce paramètre est activé par défaut dans Aurora MySQL 3.05 et versions ultérieures. | | `autocommit` | Oui | Aucun | | `automatic_sp_privileges` | Oui | Aucun | | `back_log` | Oui | Aucun | | `basedir` | Non | Aurora MySQL utilise des instances gérées dans lesquelles vous n’accédez pas directement au système de fichiers. | | `binlog_cache_size` | Oui | Aucun | | `binlog_max_flush_queue_time` | Oui | Aucun | | `binlog_order_commits` | Oui | Aucun | | `binlog_stmt_cache_size` | Oui | Aucun | | `binlog_transaction_compression` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `binlog_transaction_compression_level_zstd` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `bulk_insert_buffer_size` | Oui | Aucun | | `concurrent_insert` | Oui | Aucun | | `connect_timeout` | Oui | Aucun | | `core-file` | Non | Aurora MySQL utilise des instances gérées dans lesquelles vous n’accédez pas directement au système de fichiers. | | `datadir` | Non | Aurora MySQL utilise des instances gérées dans lesquelles vous n’accédez pas directement au système de fichiers. | | `default_authentication_plugin` | Non | Ce paramètre s’applique à Aurora MySQL version 3. | | `default_time_zone` | Non | Aucun | | `default_tmp_storage_engine` | Oui | Le moteur de stockage par défaut pour les tables temporaires. | | `default_week_format` | Oui | Aucun | | `delay_key_write` | Oui | Aucun | | `delayed_insert_limit` | Oui | Aucun | | `delayed_insert_timeout` | Oui | Aucun | | `delayed_queue_size` | Oui | Aucun | | `div_precision_increment` | Oui | Aucun | | `end_markers_in_json` | Oui | Aucun | | `eq_range_index_dive_limit` | Oui | Aucun | | `event_scheduler` | Parfois | Indique l’état du planificateur d’événements. Modifiable uniquement au niveau du cluster dans Aurora MySQL version 3. | | `explicit_defaults_for_timestamp` | Oui | Aucun | | `flush` | Non | Aucun | | `flush_time` | Oui | Aucun | | `ft_boolean_syntax` | Non | Aucun | | `ft_max_word_len` | Oui | Aucun | | `ft_min_word_len` | Oui | Aucun | | `ft_query_expansion_limit` | Oui | Aucun | | `ft_stopword_file` | Oui | Aucun | | `general_log` | Oui | Pour accéder aux instructions concernant le chargement de journaux dans CloudWatch Logs, consultez [Publication de journaux Amazon Aurora MySQL dans Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `general_log_file` | Non | Aurora MySQL utilise des instances gérées dans lesquelles vous n’accédez pas directement au système de fichiers. | | `group_concat_max_len` | Oui | Aucun | | `host_cache_size` | Oui | Aucun | | `init_connect` | Oui | La commande à exécuter par le serveur pour chaque client qui se connecte. Utilisez des guillemets (") pour les paramètres afin d’éviter les échecs de connexion, par exemple : 
SET optimizer_switch="hash_join=off"
Dans Aurora MySQL version 3, ce paramètre ne s’applique pas aux utilisateurs disposant du privilège `CONNECTION_ADMIN`, y compris l’utilisateur principal Aurora. Pour plus d’informations, consultez [Modèle de privilège basé sur les rôles](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). | | `innodb_adaptive_hash_index` | Oui | Vous pouvez modifier ce paramètre au niveau de l’instance de base de données dans Aurora MySQL version 2. Il peut être modifié uniquement au niveau du cluster de bases de données dans Aurora MySQL version 3. L’index de hachage adaptatif n’est pas pris en charge par les instances de base de données du lecteur. | | `innodb_adaptive_max_sleep_delay` | Oui | La modification de ce paramètre n’a aucun effet, car la valeur de `innodb_thread_concurrency` est toujours 0 pour Aurora. | | `innodb_aurora_max_partitions_for_range` | Oui | Si les statistiques persistantes ne sont pas disponibles, vous pouvez utiliser ce paramètre pour améliorer les performances des estimations du nombre de lignes dans les tables partitionnées. Vous pouvez le définir sur une valeur comprise entre 0 et 8192, cette valeur déterminant le nombre de partitions à vérifier lors de l’estimation du nombre de lignes. La valeur par défaut est 0, qui estime l’utilisation de toutes les partitions, conformément au comportement par défaut de MySQL. Ce paramètre est disponible pour Aurora MySQL versions 3.03.1 et ultérieures. | | `innodb_autoextend_increment` | Oui | Aucun | | `innodb_buffer_pool_dump_at_shutdown` | Non | Aucun | | `innodb_buffer_pool_dump_now` | Non | Aucun | | `innodb_buffer_pool_filename` | Non | Aucun | | `innodb_buffer_pool_load_abort` | Non | Aucun | | `innodb_buffer_pool_load_at_startup` | Non | Aucun | | `innodb_buffer_pool_load_now` | Non | Aucun | | `innodb_buffer_pool_size` | Oui | La valeur par défaut est représentée par une formule. Pour plus de détails sur le calcul de la valeur `DBInstanceClassMemory` dans la formule, consultez [Variables de formule de paramètre de bases de données](USER_ParamValuesRef.md#USER_FormulaVariables). | | `innodb_change_buffer_max_size` | Non | Aurora MySQL n’utilise pas du tout le tampon de modification InnoDB. | | `innodb_compression_failure_threshold_pct` | Oui | Aucun | | `innodb_compression_level` | Oui | Aucun | | `innodb_compression_pad_pct_max` | Oui | Aucun | | `innodb_concurrency_tickets` | Oui | La modification de ce paramètre n’a aucun effet, car la valeur de `innodb_thread_concurrency` est toujours 0 pour Aurora. | | `innodb_deadlock_detect` | Oui | Cette option permet de désactiver la détection de blocage dans Aurora MySQL version 2.11 ou ultérieure, ou version 3. Sur les systèmes à concurrence élevée, la détection de blocage peut entraîner un ralentissement lorsque de nombreux threads attendent le même verrouillage. Pour plus d’informations sur ce paramètre, consultez la documentation MySQL. | | `innodb_file_format` | Oui | Supprimé d’Aurora MySQL version 3. | | `innodb_flushing_avg_loops` | Non | Aucun | | `innodb_force_load_corrupted` | Non | Aucun | | `innodb_ft_aux_table` | Oui | Aucun | | `innodb_ft_cache_size` | Oui | Aucun | | `innodb_ft_enable_stopword` | Oui | Aucun | | `innodb_ft_server_stopword_table` | Oui | Aucun | | `innodb_ft_user_stopword_table` | Oui | Aucun | | `innodb_large_prefix` | Oui | Supprimé d’Aurora MySQL version 3. | | `innodb_lock_wait_timeout` | Oui | Aucun | | `innodb_log_compressed_pages` | Non | Aucun | | `innodb_lru_scan_depth` | Oui | Aucun | | `innodb_max_purge_lag` | Oui | Aucun | | `innodb_max_purge_lag_delay` | Oui | Aucun | | `innodb_monitor_disable` | Oui | Aucun | | `innodb_monitor_enable` | Oui | Aucun | | `innodb_monitor_reset` | Oui | Aucun | | `innodb_monitor_reset_all` | Oui | Aucun | | `innodb_old_blocks_pct` | Oui | Aucun | | `innodb_old_blocks_time` | Oui | Aucun | | `innodb_open_files` | Oui | Aucun | | `innodb_print_all_deadlocks` | Oui | Lorsque ce paramètre est activé, les informations relatives à tous les blocages InnoDB sont enregistrées dans le journal des erreurs Aurora MySQL. Pour plus d’informations, consultez [Minimisation et résolution des blocages d’Aurora MySQL](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks). | | `innodb_random_read_ahead` | Oui | Aucun | | `innodb_read_ahead_threshold` | Oui | Aucun | | `innodb_read_io_threads` | Non | Aucun | | `innodb_read_only` | Non | Aurora MySQL gère l’état en lecture seule et en lecture/écriture des instances de base de données en fonction du type de cluster. Par exemple, un cluster alloué a une instance de base de données en lecture/écriture (l’*instance principale*) et toutes les autres instances contenues dans le cluster sont en lecture/écriture (les réplicas Aurora). | | `innodb_replication_delay` | Oui | Aucun | | `innodb_sort_buffer_size` | Oui | Aucun | | `innodb_stats_auto_recalc` | Oui | Aucun | | `innodb_stats_method` | Oui | Aucun | | `innodb_stats_on_metadata` | Oui | Aucun | | `innodb_stats_persistent` | Oui | Aucun | | `innodb_stats_persistent_sample_pages` | Oui | Aucun | | `innodb_stats_transient_sample_pages` | Oui | Aucun | | `innodb_thread_concurrency` | Non | Aucun | | `innodb_thread_sleep_delay` | Oui | La modification de ce paramètre n’a aucun effet, car la valeur de `innodb_thread_concurrency` est toujours 0 pour Aurora. | | `interactive_timeout` | Oui | Aurora évalue la valeur minimale de `interactive_timeout` et `wait_timeout`. Il utilise ensuite ce minimum comme délai pour mettre fin à toutes les sessions inactives, à la fois interactives et non interactives. | | `internal_tmp_disk_storage_engine` | Oui | Contrôle quel moteur de stockage en mémoire est utilisé pour les tables temporaires internes. Les valeurs autorisées sont `INNODB` et `MYISAM`. Ce paramètre s’applique à Aurora MySQL version 2. | | `internal_tmp_mem_storage_engine` | Parfois | Contrôle quel moteur de stockage en mémoire est utilisé pour les tables temporaires internes. Les valeurs autorisées pour les instances de base de données d’enregistreur sont `MEMORY` et `TempTable`. Pour les instances de base de données de lecteur, ce paramètre est défini sur `TempTable` et ne peut pas être modifié. Ce paramètre s’applique à Aurora MySQL version 3. | | `join_buffer_size` | Oui | Aucun | | `keep_files_on_create` | Oui | Aucun | | `key_buffer_size` | Oui | Cache de clé pour les tables MyISAM. Pour plus d’informations, consultez [keycache->cache\$1lock mutex](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock). | | `key_cache_age_threshold` | Oui | Aucun | | `key_cache_block_size` | Oui | Aucun | | `key_cache_division_limit` | Oui | Aucun | | `local_infile` | Oui | Aucun | | `lock_wait_timeout` | Oui | Aucun | | `log-bin` | Non | La définition de `binlog_format` sur `STATEMENT` `MIXED`, ou `ROW` définit automatiquement `log-bin` sur `ON`. La définition de `binlog_format` sur `OFF` définit automatiquement `log-bin` sur `OFF`. Pour plus d’informations, 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). | | `log_bin_trust_function_creators` | Oui | Aucun | | `log_bin_use_v1_row_events` | Oui | Supprimé d’Aurora MySQL version 3. | | `log_error` | Non | Aucun | | `log_error_suppression_list` | Oui | Spécifie une liste de codes d’erreur qui ne sont pas consignés dans le journal d’erreurs MySQL. Cela vous permet d’ignorer certaines conditions d’erreur non critiques afin de préserver l’intégrité de vos journaux d’erreurs. Pour plus d’informations, consultez [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list) dans la documentation MySQL. Ce paramètre s’applique à Aurora MySQL versions 3.03 et ultérieures. | | `log_output` | Oui | Aucun | | `log_queries_not_using_indexes` | Oui | Aucun | | `log_slave_updates` | Non | Aurora MySQL version 2. Utilisez `log_replica_updates` dans Aurora MySQL version 3. | | `log_replica_updates` | Non | Aurora MySQL version 3 | | `log_throttle_queries_not_using_indexes` | Oui | Aucun | | `log_warnings` | Oui | Supprimé d’Aurora MySQL version 3. | | `long_query_time` | Oui | Aucun | | `low_priority_updates` | Oui | Les opérations `INSERT`, `UPDATE`, `DELETE` et `LOCK TABLE WRITE` attendent qu’il ne reste aucune opération `SELECT` en attente. Ce paramètre affecte uniquement les moteurs de stockage qui utilisent uniquement le verrouillage au niveau de la table (MyISAM, MEMORY, MERGE). Ce paramètre s’applique à Aurora MySQL version 3. | | `max_allowed_packet` | Oui | Aucun | | `max_binlog_cache_size` | Oui | Aucun | | `max_binlog_size` | Non | Aucun | | `max_binlog_stmt_cache_size` | Oui | Aucun | | `max_connect_errors` | Oui | Aucun | | `max_connections` | Oui | La valeur par défaut est représentée par une formule. Pour plus de détails sur le calcul de la valeur `DBInstanceClassMemory` dans la formule, consultez [Variables de formule de paramètre de bases de données](USER_ParamValuesRef.md#USER_FormulaVariables). Pour connaître les valeurs par défaut en fonction de la classe d’instance, consultez [Nombre maximal de connexions à une instance de base de données Aurora MySQL](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections). | | `max_delayed_threads` | Oui | Définit le nombre maximal de threads pour gérer les instructions `INSERT DELAYED`. Ce paramètre s’applique à Aurora MySQL version 3. | | `max_error_count` | Oui | Nombre maximal de messages d’erreur, d’avertissement et de note à stocker pour affichage. Ce paramètre s’applique à Aurora MySQL version 3. | | `max_execution_time` | Oui | Délai d’attente pour l’exécution des instructions `SELECT`, en millisecondes. Cette valeur peut être comprise entre `0` et `18446744073709551615`. Lorsqu’elle est définie sur `0`, il n’y a aucun délai d’attente. Pour plus d’informations, consultez [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time) dans la documentation MySQL. | | `max_heap_table_size` | Oui | Aucun | | `max_insert_delayed_threads` | Oui | Aucun | | `max_join_size` | Oui | Aucun | | `max_length_for_sort_data` | Oui | Supprimé d’Aurora MySQL version 3. | | `max_prepared_stmt_count` | Oui | Aucun | | `max_seeks_for_key` | Oui | Aucun | | `max_sort_length` | Oui | Aucun | | `max_sp_recursion_depth` | Oui | Aucun | | `max_tmp_tables` | Oui | Supprimé d’Aurora MySQL version 3. | | `max_user_connections` | Oui | Aucun | | `max_write_lock_count` | Oui | Aucun | | `metadata_locks_cache_size` | Oui | Supprimé d’Aurora MySQL version 3. | | `min_examined_row_limit` | Oui | Utilisez ce paramètre pour empêcher la journalisation des requêtes examinant un nombre de lignes inférieur au nombre spécifié. Ce paramètre s’applique à Aurora MySQL version 3. | | `myisam_data_pointer_size` | Oui | Aucun | | `myisam_max_sort_file_size` | Oui | Aucun | | `myisam_mmap_size` | Oui | Aucun | | `myisam_sort_buffer_size` | Oui | Aucun | | `myisam_stats_method` | Oui | Aucun | | `myisam_use_mmap` | Oui | Aucun | | `net_buffer_length` | Oui | Aucun | | `net_read_timeout` | Oui | Aucun | | `net_retry_count` | Oui | Aucun | | `net_write_timeout` | Oui | Aucun | | `old-style-user-limits` | Oui | Aucun | | `old_passwords` | Oui | Supprimé d’Aurora MySQL version 3. | | `optimizer_prune_level` | Oui | Aucun | | `optimizer_search_depth` | Oui | Aucun | | `optimizer_switch` | Oui | Pour plus d’informations sur les fonctions Aurora MySQL qui utilisent ce basculement, consultez [Bonnes pratiques avec Amazon Aurora MySQL](AuroraMySQL.BestPractices.md). | | `optimizer_trace` | Oui | Aucun | | `optimizer_trace_features` | Oui | Aucun | | `optimizer_trace_limit` | Oui | Aucun | | `optimizer_trace_max_mem_size` | Oui | Aucun | | `optimizer_trace_offset` | Oui | Aucun | | `performance-schema-consumer-events-waits-current` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance-schema-consumer-events-waits-current`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance-schema-instrument` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance-schema-instrument`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema` | Oui | Si la colonne **Source** est définie sur `Modified`, Performance Insights gère automatiquement le schéma de performance. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_accounts_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_accounts_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_global_instrumentation` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_consumer_global_instrumentation`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_thread_instrumentation` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_consumer_thread_instrumentation`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_stages_current` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_consumer_events_stages_current`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_stages_history` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_consumer_events_stages_history`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_stages_history_long` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_consumer_events_stages_history_long`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_statements_current` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_consumer_events_statements_current`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_statements_history` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_consumer_events_statements_history`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_statements_history_long` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_consumer_events_statements_history_long`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_waits_history` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_consumer_events_waits_history`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_events_waits_history_long` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_consumer_events_waits_history_long`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_consumer_statements_digest` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_consumer_statements_digest`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_digests_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_digests_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_stages_history_long_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_events_stages_history_long_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_stages_history_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_events_stages_history_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_statements_history_long_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_events_statements_history_long_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_statements_history_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_events_statements_history_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_transactions_history_long_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_events_transactions_history_long_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_transactions_history_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_events_transactions_history_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_waits_history_long_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_events_waits_history_long_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_events_waits_history_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_events_waits_history_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_hosts_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_hosts_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_cond_classes` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_cond_classes`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_cond_instances` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_cond_instances`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_digest_length` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_digest_length`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_file_classes` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_file_classes`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_file_handles` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_file_handles`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_file_instances` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_file_instances`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_index_stat` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_index_stat`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_memory_classes` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_memory_classes`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_metadata_locks` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_metadata_locks`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_mutex_classes` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_mutex_classes`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_mutex_instances` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_mutex_instances`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_prepared_statements_instances` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_prepared_statements_instances`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_program_instances` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_program_instances`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_rwlock_classes` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_rwlock_classes`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_rwlock_instances` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_rwlock_instances`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_socket_classes` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_socket_classes`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_socket_instances` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_socket_instances`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_sql_text_length` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_sql_text_length`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_stage_classes` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_stage_classes`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_statement_classes` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_statement_classes`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_statement_stack` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_statement_stack`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_table_handles` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_table_handles`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_table_instances` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_table_instances`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_table_lock_stat` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_table_lock_stat`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_thread_classes` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_thread_classes`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_max_thread_instances` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_max_thread_instances`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_session_connect_attrs_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_session_connect_attrs_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_setup_actors_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_setup_actors_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_setup_objects_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_setup_objects_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_show_processlist` | Oui | Ce paramètre détermine quelle implémentation SHOW PROCESSLIST utiliser : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html)Ce paramètre s’applique à Aurora MySQL versions 2.12 et ultérieures, et version 3. Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_show_processlist`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `performance_schema_users_size` | Oui | Si la colonne **Source** du paramètre `performance_schema` est définie sur `Modified`, le schéma de performance utilise le paramètre `performance_schema_users_size`. Pour plus d’informations sur l’activation du schéma de performance, consultez [Déterminer si Performance Insights gère le schéma de performance](USER_PerfInsights.EnableMySQL.determining-status.md). | | `pid_file` | Non | Aucun | | `plugin_dir` | Non | Aurora MySQL utilise des instances gérées dans lesquelles vous n’accédez pas directement au système de fichiers. | | `port` | Non | Aurora MySQL gère les propriétés de connexion et applique des paramètres cohérents pour toutes les instances de base de données contenues dans un cluster. | | `preload_buffer_size` | Oui | Taille de la mémoire tampon allouée lors du préchargement des index. Ce paramètre s’applique à Aurora MySQL version 3. | | `profiling_history_size` | Oui | Aucun | | `query_alloc_block_size` | Oui | Aucun | | `query_cache_limit` | Oui | Supprimé d’Aurora MySQL version 3. | | `query_cache_min_res_unit` | Oui | Supprimé d’Aurora MySQL version 3. | | `query_cache_size` | Oui | La valeur par défaut est représentée par une formule. Pour plus de détails sur le calcul de la valeur `DBInstanceClassMemory` dans la formule, consultez [Variables de formule de paramètre de bases de données](USER_ParamValuesRef.md#USER_FormulaVariables). Supprimé d’Aurora MySQL version 3. | | `query_cache_type` | Oui | Supprimé d’Aurora MySQL version 3. | | `query_cache_wlock_invalidate` | Oui | Supprimé d’Aurora MySQL version 3. | | `query_prealloc_size` | Oui | Aucun | | `range_alloc_block_size` | Oui | Aucun | | `read_buffer_size` | Oui | Aucun | | `read_only` | Oui | Lorsque ce paramètre est activé, le serveur n’autorise aucune mise à jour, à l’exception de celles effectuées par les threads de réplica. Pour Aurora MySQL version 2, les valeurs valides sont les suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Nous vous recommandons d’utiliser le groupe de paramètres du cluster de bases de données dans Aurora MySQL version 2 pour vous assurer que le paramètre `read_only` est appliqué aux nouvelles instances d’enregistreur lors du basculement. Les instances de lecteur sont toujours en lecture seule, car Aurora MySQL définit `innodb_read_only` sur `1` pour tous les lecteurs. Par conséquent, `read_only` est redondant sur les instances de lecteur. Supprimé au niveau de l’instance d’Aurora MySQL version 3. | | `read_rnd_buffer_size` | Oui | Aucun | | `relay-log` | Non | Aucun | | `relay_log_info_repository` | Oui | Supprimé d’Aurora MySQL version 3. | | `relay_log_recovery` | Non | Aucun | | `replica_checkpoint_group` | Oui | Aurora MySQL version 3 | | `replica_checkpoint_period` | Oui | Aurora MySQL version 3 | | `replica_parallel_workers` | Oui | Aurora MySQL version 3 | | `replica_pending_jobs_size_max` | Oui | Aurora MySQL version 3 | | `replica_skip_errors` | Oui | Aurora MySQL version 3 | | `replica_sql_verify_checksum` | Oui | Aurora MySQL version 3 | | `safe-user-create` | Oui | Aucun | | `secure_auth` | Oui | Ce paramètre est toujours activé dans Aurora MySQL version 2. Essayer de le désactiver génère une erreur. Supprimé d’Aurora MySQL version 3. | | `secure_file_priv` | Non | Aurora MySQL utilise des instances gérées dans lesquelles vous n’accédez pas directement au système de fichiers. | | `show_create_table_verbosity` | Oui | En raison de l’activation de cette variable, [SHOW\$1CREATE\$1TABLE](https://dev.mysql.com/doc/refman/5.7/en/show-create-table.html) affiche `ROW_FORMAT`, qu’il s’agisse du format par défaut ou non. Ce paramètre s’applique à Aurora MySQL versions 2.12 et ultérieures, et version 3. | | `skip-slave-start` | Non | Aucun | | `skip_external_locking` | Non | Aucun | | `skip_show_database` | Oui | Aucun | | `slave_checkpoint_group` | Oui | Aurora MySQL version 2. Utilisez `replica_checkpoint_group` dans Aurora MySQL version 3. | | `slave_checkpoint_period` | Oui | Aurora MySQL version 2. Utilisez `replica_checkpoint_period` dans Aurora MySQL version 3. | | `slave_parallel_workers` | Oui | Aurora MySQL version 2. Utilisez `replica_parallel_workers` dans Aurora MySQL version 3. | | `slave_pending_jobs_size_max` | Oui | Aurora MySQL version 2. Utilisez `replica_pending_jobs_size_max` dans Aurora MySQL version 3. | | `slave_sql_verify_checksum` | Oui | Aurora MySQL version 2. Utilisez `replica_sql_verify_checksum` dans Aurora MySQL version 3. | | `slow_launch_time` | Oui | Aucun | | `slow_query_log` | Oui | Pour accéder aux instructions concernant le chargement de journaux dans CloudWatch Logs, consultez [Publication de journaux Amazon Aurora MySQL dans Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). | | `slow_query_log_file` | Non | Aurora MySQL utilise des instances gérées dans lesquelles vous n’accédez pas directement au système de fichiers. | | `socket` | Non | Aucun | | `sort_buffer_size` | Oui | Aucun | | `sql_mode` | Oui | Aucun | | `sql_select_limit` | Oui | Aucun | | `stored_program_cache` | Oui | Aucun | | `sync_binlog` | Non | Aucun | | `sync_master_info` | Oui | Aucun | | `sync_source_info` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. | | `sync_relay_log` | Oui | Supprimé d’Aurora MySQL version 3. | | `sync_relay_log_info` | Oui | Aucun | | `sysdate-is-now` | Oui | Aucun | | `table_cache_element_entry_ttl` | Non | Aucun | | `table_definition_cache` | Oui | La valeur par défaut est représentée par une formule. Pour plus de détails sur le calcul de la valeur `DBInstanceClassMemory` dans la formule, consultez [Variables de formule de paramètre de bases de données](USER_ParamValuesRef.md#USER_FormulaVariables). | | `table_open_cache` | Oui | La valeur par défaut est représentée par une formule. Pour plus de détails sur le calcul de la valeur `DBInstanceClassMemory` dans la formule, consultez [Variables de formule de paramètre de bases de données](USER_ParamValuesRef.md#USER_FormulaVariables). | | `table_open_cache_instances` | Oui | Aucun | | `temp-pool` | Oui | Supprimé d’Aurora MySQL version 3. | | `temptable_max_mmap` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. Pour en savoir plus, consultez [Nouveau comportement de table temporaire dans Aurora MySQL version 3](ams3-temptable-behavior.md). | | `temptable_max_ram` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. Pour en savoir plus, consultez [Nouveau comportement de table temporaire dans Aurora MySQL version 3](ams3-temptable-behavior.md). | | `temptable_use_mmap` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. Pour en savoir plus, consultez [Nouveau comportement de table temporaire dans Aurora MySQL version 3](ams3-temptable-behavior.md). | | `thread_cache_size` | Oui | Le nombre de threads à mettre en cache. Ce paramètre s’applique à Aurora MySQL versions 2 et 3. | | `thread_handling` | Non | Aucun | | `thread_stack` | Oui | Aucun | | `timed_mutexes` | Oui | Aucun | | `tmp_table_size` | Oui | Définit la taille maximale des tables temporaires en mémoire internes créées par le moteur de stockage `MEMORY` dans Aurora MySQL version 3. Dans Aurora MySQL version 3.04, définit la taille maximale des tables temporaires en mémoire internes créées par le moteur de stockage `TempTable` quand `aurora_tmptable_enable_per_table_limit` a pour valeur `ON`. Pour plus d’informations, consultez [Limitation de la taille des tables temporaires internes en mémoire](ams3-temptable-behavior.md#ams3-temptable-behavior-limit). | | `tmpdir` | Non | Aurora MySQL utilise des instances gérées dans lesquelles vous n’accédez pas directement au système de fichiers. | | `transaction_alloc_block_size` | Oui | Aucun | | `transaction_isolation` | Oui | Ce paramètre s’applique à Aurora MySQL version 3. Remplace `tx_isolation`. | | `transaction_prealloc_size` | Oui | Aucun | | `tx_isolation` | Oui | Supprimé d’Aurora MySQL version 3. Remplacé par `transaction_isolation`. | | `updatable_views_with_limit` | Oui | Aucun | | `validate-password` | Non | Aucun | | `validate_password_dictionary_file` | Non | Aucun | | `validate_password_length` | Non | Aucun | | `validate_password_mixed_case_count` | Non | Aucun | | `validate_password_number_count` | Non | Aucun | | `validate_password_policy` | Non | Aucun | | `validate_password_special_char_count` | Non | Aucun | | `wait_timeout` | Oui | Aurora évalue la valeur minimale de `interactive_timeout` et `wait_timeout`. Il utilise ensuite ce minimum comme délai pour mettre fin à toutes les sessions inactives, à la fois interactives et non interactives. | ## Paramètres MySQL ne s’appliquant pas à Aurora MySQL En raison des différences d’architecture entre Aurora MySQL et MySQL, certains paramètres MySQL ne s’appliquent pas à Aurora MySQL. Les paramètres MySQL suivants ne s’appliquent pas à Aurora MySQL. Cette liste n’est pas exhaustive. + `activate_all_roles_on_login` – Ce paramètre ne s’applique pas à Aurora MySQL version 2. Il est disponible dans Aurora MySQL version 3. + `big_tables` + `bind_address` + `character_sets_dir` + `innodb_adaptive_flushing` + `innodb_adaptive_flushing_lwm` + `innodb_buffer_pool_chunk_size` + `innodb_buffer_pool_instances` + `innodb_change_buffering` + `innodb_checksum_algorithm` + `innodb_data_file_path` + `innodb_dedicated_server` + `innodb_doublewrite` + `innodb_flush_log_at_timeout` – Ce paramètre ne s’applique pas à Aurora MySQL. Pour plus d’informations, consultez [Configuration de la fréquence à laquelle le tampon du journal est vidé](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). + `innodb_flush_method` + `innodb_flush_neighbors` + `innodb_io_capacity` + `innodb_io_capacity_max` + `innodb_log_buffer_size` + `innodb_log_file_size` + `innodb_log_files_in_group` + `innodb_log_spin_cpu_abs_lwm` + `innodb_log_spin_cpu_pct_hwm` + `innodb_log_writer_threads` + `innodb_max_dirty_pages_pct` + `innodb_numa_interleave` + `innodb_page_size` + `innodb_redo_log_capacity` + `innodb_redo_log_encrypt` + `innodb_undo_log_encrypt` + `innodb_undo_log_truncate` + `innodb_undo_logs` + `innodb_undo_tablespaces` + `innodb_use_native_aio` + `innodb_write_io_threads` # Variables d’état globales Aurora MySQL Aurora MySQL inclut des variables d’état issues de la communauté MySQL et des variables propres à Aurora. Vous pouvez examiner ces variables pour savoir ce qui se passe dans le moteur de base de données. Pour plus d’informations sur les variables d’état dans la communauté MySQL, consultez [Variables d’état du serveur](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html) dans la documentation MySQL 8.0 de la communauté. Vous pouvez trouver les valeurs actuelles des variables d’état globales Aurora MySQL à l’aide d’une instruction telle que la suivante : ``` show global status like '%aurora%'; ``` **Note** Les variables d’état globales sont effacées lorsque le moteur de base de données redémarre. Le tableau suivant décrit les variables d’état globales utilisées par Aurora MySQL. | Nom | Description | | --- | --- | | `AuroraDb_commits` | Nombre total de validations depuis le dernier redémarrage. | | `AuroraDb_commit_latency` | Latence de validation agrégée depuis le dernier redémarrage. | | `AuroraDb_ddl_stmt_duration` | Latence DDL agrégée depuis le dernier redémarrage. | | `AuroraDb_select_stmt_duration` | Latence d’instruction `SELECT` agrégée depuis le dernier redémarrage. | | `AuroraDb_insert_stmt_duration` | Latence d’instruction `INSERT` agrégée depuis le dernier redémarrage. | | `AuroraDb_update_stmt_duration` | Latence d’instruction `UPDATE` agrégée depuis le dernier redémarrage. | | `AuroraDb_delete_stmt_duration` | Latence d’instruction `DELETE` agrégée depuis le dernier redémarrage. | | `Aurora_binlog_io_cache_allocated` | Le nombre d'octets alloués au I/O cache du journal binaire. | | `Aurora_binlog_io_cache_read_requests` | Le nombre de demandes de lecture envoyées au I/O cache binlog. | | `Aurora_binlog_io_cache_reads` | Le nombre de demandes de lecture traitées depuis le I/O cache binlog. | | `Aurora_enhanced_binlog` | Indique si le journal binaire amélioré est activé ou désactivé pour cette instance de base de données. Pour plus d’informations, consultez [Configuration du binlog amélioré pour Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). | | `Aurora_external_connection_count` | Nombre de connexions de base de données à l’instance de base de données, à l’exclusion des connexions au service RDS utilisées pour les vérifications d’état de la base de données. | | `Aurora_fast_insert_cache_hits` | Compteur incrémenté quand le curseur mis en cache est récupéré et vérifié avec succès. Pour plus d’informations sur le cache d’insertion rapide, consultez [Améliorations des performances Amazon Aurora MySQL](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance). | | `Aurora_fast_insert_cache_misses` | Compteur incrémenté quand le curseur mis en cache n’est plus valide et qu’Aurora exécute une traversée d’index normale. Pour plus d’informations sur le cache d’insertion rapide, consultez [Améliorations des performances Amazon Aurora MySQL](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance). | | `Aurora_fts_cache_memory_used` | Quantité de mémoire, en octets, qu’utilise le système de recherche de texte intégral InnoDB. Cette variable s’applique à Aurora MySQL 3.07 ou version ultérieure. | | `Aurora_fwd_master_dml_stmt_count` | Nombre total d’instructions DML transférées à cette instance de base de données d’enregistreur. Cette variable s’applique à Aurora MySQL version 2. | | `Aurora_fwd_master_dml_stmt_duration` | Durée totale des instructions DML transférées à cette instance de base de données d’enregistreur. Cette variable s’applique à Aurora MySQL version 2. | | `Aurora_fwd_master_errors_rpc_timeout` | Nombre de fois où une connexion transférée n’a pas pu être établie sur l’enregistreur. | | `Aurora_fwd_master_errors_session_limit` | Nombre de requêtes transférées qui sont rejetées en raison de `session full` sur l’enregistreur. | | `Aurora_fwd_master_errors_session_timeout` | Nombre de fois qu’une session de transfert est interrompue en raison d’un dépassement de délai d’attente sur l’enregistreur. | | `Aurora_fwd_master_open_sessions` | Nombre de sessions transférées sur l’instance de base de données d’enregistreur. Cette variable s’applique à Aurora MySQL version 2. | | `Aurora_fwd_master_select_stmt_count` | Nombre total d’instructions `SELECT` transférées à cette instance de base de données d’enregistreur. Cette variable s’applique à Aurora MySQL version 2. | | `Aurora_fwd_master_select_stmt_duration` | Durée totale des instructions `SELECT` transférées à cette instance de base de données d’enregistreur. Cette variable s’applique à Aurora MySQL version 2. | | `Aurora_fwd_writer_dml_stmt_count` | Nombre total d’instructions DML transférées à cette instance de base de données d’enregistreur. Cette variable s’applique à Aurora MySQL version 3. | | `Aurora_fwd_writer_dml_stmt_duration` | Durée totale des instructions DML transférées à cette instance de base de données d’enregistreur. Cette variable s’applique à Aurora MySQL version 3. | | `Aurora_fwd_writer_errors_rpc_timeout` | Nombre de fois où une connexion transférée n’a pas pu être établie sur l’enregistreur. | | `Aurora_fwd_writer_errors_session_limit` | Nombre de requêtes transférées qui sont rejetées en raison de `session full` sur l’enregistreur. | | `Aurora_fwd_writer_errors_session_timeout` | Nombre de fois qu’une session de transfert est interrompue en raison d’un dépassement de délai d’attente sur l’enregistreur. | | `Aurora_fwd_writer_open_sessions` | Nombre de sessions transférées sur l’instance de base de données d’enregistreur. Cette variable s’applique à Aurora MySQL version 3. | | `Aurora_fwd_writer_select_stmt_count` | Nombre total d’instructions `SELECT` transférées à cette instance de base de données d’enregistreur. Cette variable s’applique à Aurora MySQL version 3. | | `Aurora_fwd_writer_select_stmt_duration` | Durée totale des instructions `SELECT` transférées à cette instance de base de données d’enregistreur. Cette variable s’applique à Aurora MySQL version 3. | | `Aurora_lockmgr_buffer_pool_memory_used` | Quantité de mémoire du groupe de mémoires tampons, en octets, qu’utilise le gestionnaire de verrouillage Aurora MySQL. | | `Aurora_lockmgr_memory_used` | Quantité de mémoire en octets qu’utilise le gestionnaire de verrouillage Aurora MySQL. | | `Aurora_ml_actual_request_cnt` | Le nombre total de demandes envoyées par Aurora My SQLmakes aux services d'apprentissage automatique Aurora pour toutes les requêtes exécutées par les utilisateurs de l'instance de base de données. Pour de plus amples informations, veuillez consulter [Utilisation du machine learning Amazon Aurora avec Aurora MySQL](mysql-ml.md). | | `Aurora_ml_actual_response_cnt` | Le nombre total de réponses reçues par Aurora MySQL de la part des services de machine learning Aurora dans toutes les requêtes exécutées par des utilisateurs de l’instance de base de données. Pour plus d’informations, consultez [Utilisation du machine learning Amazon Aurora avec Aurora MySQL](mysql-ml.md). | | `Aurora_ml_cache_hit_cnt` | Le nombre total d’accès au cache interne reçus par Aurora MySQL de la part des services de machine learning Aurora dans toutes les requêtes exécutées par des utilisateurs de l’instance de base de données. Pour plus d’informations, consultez [Utilisation du machine learning Amazon Aurora avec Aurora MySQL](mysql-ml.md). | | `Aurora_ml_logical_request_cnt` | Nombre de demandes logiques que l’instance de base de données a évaluées pour qu’elles soient envoyées aux services de machine learning Aurora depuis la dernière réinitialisation de l’état. Si un traitement par lots a été utilisé, cette valeur peut être supérieure à `Aurora_ml_actual_request_cnt`. Pour plus d’informations, consultez [Utilisation du machine learning Amazon Aurora avec Aurora MySQL](mysql-ml.md). | | `Aurora_ml_logical_response_cnt` | Le nombre total de réponses reçues par Aurora MySQL de la part des services de machine learning Aurora dans toutes les requêtes exécutées par des utilisateurs de l’instance de base de données. Pour plus d’informations, consultez [Utilisation du machine learning Amazon Aurora avec Aurora MySQL](mysql-ml.md). | | `Aurora_ml_retry_request_cnt` | Nombre de nouvelles tentatives de demande que l’instance de base de données a envoyées aux services de machine learning Aurora depuis la dernière réinitialisation de l’état. Pour plus d’informations, consultez [Utilisation du machine learning Amazon Aurora avec Aurora MySQL](mysql-ml.md). | | `Aurora_ml_single_request_cnt` | Le nombre total de fonctions de machine learning Aurora évaluées par un mode autre que par lots dans toutes les requêtes exécutées par des utilisateurs de l’instance de base de données. Pour de plus amples informations, veuillez consulter [Utilisation du machine learning Amazon Aurora avec Aurora MySQL](mysql-ml.md). | | `aurora_oom_avoidance_recovery_state` | Indique si la restauration visant à éviter Aurora out-of-memory (OOM) est à l'`INACTIVE`état `ACTIVE` ou pour cette instance de base de données. Cette variable s’applique à Aurora MySQL 3.06.0 ou version ultérieure. | | `aurora_oom_reserved_mem_enter_kb` | Représente le seuil à atteindre pour passer à l’état `RESERVED` dans le mécanisme de gestion des insuffisances de mémoire d’Aurora. Lorsque la mémoire disponible sur le serveur tombe en dessous de ce seuil, `aurora_oom_status` indique `RESERVED`, ce qui signifie que le serveur se rapproche d’un niveau critique d’utilisation de la mémoire. Cette variable s’applique à Aurora MySQL 3.06.0 ou version ultérieure. | | `aurora_oom_reserved_mem_exit_kb` | Représente le seuil à atteindre pour sortir de l’état `RESERVED` dans le mécanisme de gestion des insuffisances de mémoire d’Aurora. Lorsque la mémoire disponible sur le serveur dépasse ce seuil, `aurora_oom_status` indique `NORMAL`, ce qui signifie que le serveur est revenu à un état plus stable avec des ressources de mémoire suffisantes. Cette variable s’applique à Aurora MySQL 3.06.0 ou version ultérieure. | | `aurora_oom_status` | Représente l’état actuel de cette instance de base de données en matière d’insuffisance de mémoire. Lorsque cette valeur est `NORMAL`, cela indique que les ressources de mémoire sont suffisantes. Si cette valeur passe à `RESERVED`, cela indique que la mémoire disponible du serveur est faible. Les actions sont effectuées en fonction de la configuration du paramètre `aurora_oom_response`. Pour plus d’informations, consultez [Résolution des problèmes de mémoire insuffisante pour les bases de données Aurora MySQL](AuroraMySQLOOM.md). Cette variable s’applique à Aurora MySQL 3.06.0 ou version ultérieure. | | `Aurora_pq_bytes_returned` | Nombre d’octets des structures de données à tuple transmises au nœud principal lors des requêtes parallèles. Divisez cette valeur par 16 384 pour la comparer à `Aurora_pq_pages_pushed_down`. | | `Aurora_pq_max_concurrent_requests` | Nombre maximal de sessions de requêtes parallèles pouvant être exécutées simultanément sur cette instance de base de données Aurora. Il s'agit d'un nombre fixe qui dépend de la classe d' AWS instance de base de données. | | `Aurora_pq_pages_pushed_down` | Nombre de pages de données (chacune avec une taille fixe de 16 Kio) pour lesquelles une requête parallèle a évité une transmission réseau au nœud principal. | | `Aurora_pq_request_attempted` | Nombre de sessions de requêtes parallèles demandées. Cette valeur peut représenter plus d’une session par requête, en fonction des constructions SQL telles que les sous-requêtes et les jointures. | | `Aurora_pq_request_executed` | Nombre de sessions de requêtes parallèles ayant réussi. | | `Aurora_pq_request_failed` | Nombre de sessions de requêtes parallèles ayant renvoyé une erreur au client. Dans certains cas, les demandes de requêtes parallèles peuvent échouer (en cas de problème au niveau de la couche de stockage, par exemple). Dans ce cas, la partie de la requête ayant échoué fait l’objet d’une autre tentative avec un mécanisme de requête non parallèle. Si cette nouvelle tentative échoue également, une erreur est renvoyée au client, et ce compteur est incrémenté. | | `Aurora_pq_request_in_progress` | Nombre de sessions de requêtes parallèles en cours. Ce nombre s’applique à l’instance de base de données Aurora spécifique à laquelle vous êtes connecté, et non à l’ensemble du cluster de bases de données Aurora. Pour déterminer si une instance de base de données se rapproche de sa limite de simultanéité, comparez cette valeur à `Aurora_pq_max_concurrent_requests`. | | `Aurora_pq_request_not_chosen` | Nombre de fois qu’une requête parallèle n’a pas été choisie pour accomplir une requête. Cette valeur correspond à la somme de plusieurs autres compteurs plus précis. Une instruction `EXPLAIN` peut incrémenter ce compteur même si la requête n’est pas réellement effectuée. | | `Aurora_pq_request_not_chosen_below_min_rows` | Nombre de fois qu’une requête parallèle n’a pas été choisie en raison du nombre de lignes dans la table. Une instruction `EXPLAIN` peut incrémenter ce compteur même si la requête n'est pas réellement effectuée. | | `Aurora_pq_request_not_chosen_column_bit` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle en raison d’un type de données non pris en charge dans la liste des colonnes projetées. | | `Aurora_pq_request_not_chosen_column_geometry` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle, car la table comporte des colonnes avec le type de données `GEOMETRY`. Pour plus d’informations sur les versions Aurora MySQL qui suppriment cette limitation, consultez [Mise à niveau des clusters de requêtes parallèles vers Aurora MySQL version 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). | | `Aurora_pq_request_not_chosen_column_lob` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle, car la table comporte des colonnes avec un type de données `LOB` ou des colonnes `VARCHAR` stockées en externe en raison de la longueur déclarée. Pour plus d’informations sur les versions Aurora MySQL qui suppriment cette limitation, consultez [Mise à niveau des clusters de requêtes parallèles vers Aurora MySQL version 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2). | | `Aurora_pq_request_not_chosen_column_virtual` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle, car la table contient une colonne virtuelle. | | `Aurora_pq_request_not_chosen_custom_charset` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle, car la table comporte des colonnes avec un jeu de caractères personnalisé. | | `Aurora_pq_request_not_chosen_fast_ddl` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle car la table est actuellement modifiée par une instruction DDL rapide `ALTER`. | | `Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool` | Nombre de fois qu’une requête parallèle n’a pas été choisie, même si moins de 95 % des données de la table se trouvait dans le groupe de mémoires tampons, car il n’y avait pas suffisamment de données hors mémoire tampon pour que l’application de la fonction de requête parallèle soit justifiée. | | `Aurora_pq_request_not_chosen_full_text_index` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle, car la table comporte des index de texte intégral. | | `Aurora_pq_request_not_chosen_high_buffer_pool_pct` | Nombre de fois qu’une requête parallèle n’a pas été choisie, car un pourcentage élevé de données de la table (pourcentage actuellement supérieur à 95 %) se trouvait déjà dans un groupe de mémoires tampons. Dans ce cas, l’optimiseur détermine que la lecture des données à partir du groupe de mémoires tampons est plus efficace. Une instruction `EXPLAIN` peut incrémenter ce compteur même si la requête n'est pas réellement effectuée. | | `Aurora_pq_request_not_chosen_index_hint` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle, car la requête inclut un indicateur d’index. | | `Aurora_pq_request_not_chosen_innodb_table_format` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle, car la table utilise un format de ligne InnoDB non pris en charge. Une requête parallèle Aurora s’applique uniquement aux formats de ligne `COMPACT`, `REDUNDANT` et `DYNAMIC`. | | `Aurora_pq_request_not_chosen_long_trx` | Nombre de demandes de requêtes parallèles ayant utilisé le chemin de traitement de requête non parallèle en raison du lancement de la requête dans une transaction de longue durée. Une instruction `EXPLAIN` peut incrémenter ce compteur même si la requête n'est pas réellement effectuée. | | `Aurora_pq_request_not_chosen_no_where_clause` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle, car la requête n’inclut aucune clause `WHERE`. | | `Aurora_pq_request_not_chosen_range_scan` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle, car la requête utilise une analyse de plage sur un index. | | `Aurora_pq_request_not_chosen_row_length_too_long` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle, car la longueur totale combinée de toutes les colonnes est trop élevée. | | `Aurora_pq_request_not_chosen_small_table` | Nombre de fois qu’une requête parallèle n’a pas été choisie en raison de la taille globale de la table, telle que déterminée par le nombre de lignes dans la table et leur longueur moyenne. Une instruction `EXPLAIN` peut incrémenter ce compteur même si la requête n’est pas réellement effectuée. | | `Aurora_pq_request_not_chosen_temporary_table` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle, car la requête fait référence à des tables temporaires qui utilisent les types de table `MyISAM` ou `memory` non pris en charge. | | `Aurora_pq_request_not_chosen_tx_isolation` | Nombre de demandes de requête parallèle qui utilisent le chemin de traitement de requête non parallèle, car la requête utilise un niveau d’isolement de transaction non pris en charge. Sur les instances de base de données de lecteur, la requête parallèle s’applique uniquement aux niveaux d’isolement `REPEATABLE READ` et `READ COMMITTED`. | | `Aurora_pq_request_not_chosen_update_delete_stmts` | Nombre de demandes de requête parallèle utilisant le chemin de traitement de requête non parallèle, car la requête fait partie d’une instruction `UPDATE` ou `DELETE`. | | `Aurora_pq_request_not_chosen_unsupported_access` | Nombre de demandes de requêtes parallèles qui utilisent le chemin de traitement de requête non parallèle, car la clause `WHERE` ne remplit pas les critères des requêtes parallèles. Ce résultat peut se produire si la requête ne nécessite aucune analyse à usage intensif de données ou si la requête est une instruction `DELETE` ou `UPDATE`. | | `Aurora_pq_request_not_chosen_unsupported_storage_type` | Nombre de demandes de requêtes parallèles qui utilisent le chemin de traitement des requêtes non parallèles parce que le cluster de bases de données Aurora MySQL n’utilise pas de configuration de stockage de cluster Aurora prise en charge. Pour plus d’informations, consultez [Limitations](aurora-mysql-parallel-query.md#aurora-mysql-parallel-query-limitations). Ce paramètre s’applique à Aurora MySQL versions 3.04 et ultérieures. | | `Aurora_pq_request_throttled` | Nombre de fois qu’une requête parallèle n’a pas été choisie en raison du nombre maximal de requêtes parallèles simultanées déjà exécutées sur une instance de base de données Aurora spécifique. | | `Aurora_repl_bytes_received` | Nombre d’octets répliqués vers une instance de base de données de lecteur Aurora MySQL depuis le dernier redémarrage. Pour plus d’informations, consultez [Réplication avec Amazon Aurora MySQL](AuroraMySQL.Replication.md). | | `Aurora_reserved_mem_exceeded_incidents` | Nombre de fois depuis le dernier redémarrage où le moteur a dépassé les limites de mémoire réservées. S'il `aurora_oom_response` est configuré, ce seuil définit le moment où les activités d'évitement out-of-memory (OOM) sont déclenchées. Pour plus d’informations sur la réponse OOM d’Aurora MySQL, consultez [Résolution des problèmes de mémoire insuffisante pour les bases de données Aurora MySQL](AuroraMySQLOOM.md). | | `aurora_temptable_max_ram_allocation` | Quantité de mémoire, en octets, utilisée à tout moment par les tables temporaires internes depuis le dernier redémarrage. | | `aurora_temptable_ram_allocation` | Quantité de mémoire actuelle, en octets, utilisée par les tables temporaires internes. | | `Aurora_in_memory_relaylog_status` | État actuel de la fonctionnalité de journal de relais en mémoire, qui peut être ACTIVÉE ou DÉSACTIVÉE. | | `Aurora_in_memory_relaylog_disabled_reason` | Indique la cause de l’état actuel de la fonctionnalité de journal de relais en mémoire. Si cette fonctionnalité est désactivée, un message explique pourquoi elle est désactivée. | | `Aurora_in_memory_relaylog_fallback_count` | Affiche le nombre total de remplacements de la fonctionnalité de journal de relais en mémoire par le mode journal de relais persistant (ancien). Le remplacement peut être dû à un événement ayant une taille supérieure à celle du cache (128 Mo actuellement) ou à un dépassement de la limite de nouvelles tentatives de transaction du réplica (replica\$1transaction\$1retries). | | `Aurora_in_memory_relaylog_recovery_count` | Indique le nombre total de restaurations automatiques du journal de relais en mémoire. Ce décompte inclut le nombre total de remplacements et le nombre de rétablissements automatiques du mode journal de relais en mémoire après les remplacements temporaires. | | `Aurora_thread_pool_thread_count` | Nombre actuel de threads dans le groupe de threads Aurora. Pour plus d’informations sur le groupe de threads dans Aurora MySQL, consultez [Groupe de threads](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.pool). | | `Aurora_tmz_version` | Désigne la version actuelle des informations de fuseau horaire utilisées par le cluster de bases de données. Les valeurs suivent le format de l’IANA (Internet Assigned Numbers Authority) : `YYYYsuffix`, par exemple`2022a` et `2023c`. Ce paramètre s’applique à Aurora MySQL versions 2.12 et ultérieures, et versions 3.04 et ultérieures. | | `Aurora_zdr_oom_threshold` | Représente le seuil de mémoire, en kilo-octets (Ko), à atteindre pour qu’une instance de base de données Aurora lance un redémarrage sans durée d’indisponibilité (ZDR) afin de remédier à d’éventuels problèmes liés à la mémoire. | | `server_aurora_das_running` | Indique si les flux d’activité de base de données (DAS) sont activés ou désactivés sur cette instance de base de données. Pour plus d’informations, consultez [Surveillance d’Amazon Aurora à l’aide des flux d’activité de base de données](DBActivityStreams.md). | ## Variables d’état MySQL ne s’appliquant pas à Aurora MySQL En raison des différences d’architecture entre Aurora MySQL et MySQL, certaines variables d’état MySQL ne s’appliquent pas à Aurora MySQL. Les variables d’état MySQL suivantes ne s’appliquent pas à Aurora MySQL. Cette liste n’est pas exhaustive. + `innodb_buffer_pool_bytes_dirty` + `innodb_buffer_pool_pages_dirty` + `innodb_buffer_pool_pages_flushed` Aurora MySQL version 3 supprime les variables d’état suivantes précédemment disponibles dans Aurora MySQL version 2 : + `AuroraDb_lockmgr_bitmaps0_in_use` + `AuroraDb_lockmgr_bitmaps1_in_use` + `AuroraDb_lockmgr_bitmaps_mem_used` + `AuroraDb_thread_deadlocks` + `available_alter_table_log_entries` + `Aurora_lockmgr_memory_used` + `Aurora_missing_history_on_replica_incidents` + `Aurora_new_lock_manager_lock_release_cnt` + `Aurora_new_lock_manager_lock_release_total_duration_micro` + `Aurora_new_lock_manager_lock_timeout_cnt` + `Aurora_total_op_memory` + `Aurora_total_op_temp_space` + `Aurora_used_alter_table_log_entries` + `Aurora_using_new_lock_manager` + `Aurora_volume_bytes_allocated` + `Aurora_volume_bytes_left_extent` + `Aurora_volume_bytes_left_total` + `Com_alter_db_upgrade` + `Compression` + `External_threads_connected` + `Innodb_available_undo_logs` + `Last_query_cost` + `Last_query_partial_plans` + `Slave_heartbeat_period` + `Slave_last_heartbeat` + `Slave_received_heartbeats` + `Slave_retried_transactions` + `Slave_running` + `Time_since_zero_connections` Ces variables d’état MySQL sont disponibles dans Aurora MySQL version 2, mais pas disponibles dans Aurora MySQL version 3 : + `Innodb_redo_log_enabled` + `Innodb_undo_tablespaces_total` + `Innodb_undo_tablespaces_implicit` + `Innodb_undo_tablespaces_explicit` + `Innodb_undo_tablespaces_active` # Événements d’attente Aurora MySQL Voici quelques événements d’attente courants pour Aurora MySQL. **Note** Pour plus d’informations sur le réglage des performances d’Aurora MySQL à l’aide d’événements d’attente, consultez [Réglage d'Aurora MySQL avec des événements d'attente](AuroraMySQL.Managing.Tuning.wait-events.md). Pour plus d’informations sur les conventions de dénomination utilisées dans les événements d’attente MySQL, consultez [Performance Schema Instrument Naming Conventions](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html) dans la documentation MySQL. **cpu** Le nombre de connexions actives prêtes à fonctionner est constamment supérieur au nombre de CPUs v. Pour plus d'informations, consultez[cpu](ams-waits.cpu.md). **io/aurora\$1redo\$1log\$1flush** Une session conserve les données dans le stockage Aurora. Cet événement d’attente correspond généralement à une opération I/O d’écriture dans Aurora MySQL. Pour plus d’informations, consultez [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md). **io/aurora\$1respond\$1to\$1client** Le traitement des requêtes est terminé et les résultats sont renvoyés au client d’application pour les versions suivantes d’Aurora MySQL : 2.10.2 et versions 2.10 ultérieures, 2.09.3 et versions 2.09 ultérieures, 2.07.7 et versions 2.07 ultérieures. Comparez la bande passante réseau de la classe d’instance de base de données avec la taille de l’ensemble de résultats renvoyé. Vérifiez également les temps de réponse côté client. Si le client ne répond pas et n’est pas en mesure de traiter les paquets TCP, des pertes de paquets et des retransmissions TCP peuvent se produire. Cette situation affecte négativement la bande passante réseau. Dans les versions antérieures aux versions 2.10.2, 2.09.3 et 2.07.7, l’événement d’attente inclut par erreur le temps d’inactivité. Pour savoir comment régler votre base de données lorsque cette attente est importante, consultez [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md). **io/file/csv/data** Les threads écrivent dans les tables au format CSV. Vérifiez votre utilisation de la table CSV. Cet événement est souvent déclenché par la définition de `log_output` sur une table. **io/file/sql/binlog** Un thread attend un fichier journal binaire (binlog) en cours d’écriture sur le disque. **io/redo\$1log\$1flush** Une session conserve les données dans le stockage Aurora. Généralement, cet événement d'attente concerne une I/O opération d'écriture dans Aurora MySQL. Pour de plus amples informations, veuillez consulter [io/redo\$1log\$1flush](ams-waits.io-redologflush.md). **io/socket/sql/client\$1connexion** Le programme `mysqld` est occupé à créer des threads pour gérer les nouvelles connexions client entrantes. Pour de plus amples informations, veuillez consulter [io/socket/sql/client\$1connexion](ams-waits.client-connection.md). **io/table/sql/handler** Le moteur attend d’accéder à une table. Cet événement se produit indépendamment du fait que les données soient mises en cache dans le groupe de mémoires tampons ou accessibles sur disque. Pour de plus amples informations, veuillez consulter [io/table/sql/handler](ams-waits.waitio.md). **lock/table/sql/handler** Cet événement d’attente est un gestionnaire d’événements d’attente de verrouillage de table. Pour plus d’informations sur les événements « atom » et « molecule » du schéma de performance, consultez [Performance Schema atom and molecule events](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-atom-molecule-events.html) dans la documentation MySQL. **synch/cond/innodb/row\$1bloquer\$1attendre** Plusieurs instructions en langage de manipulation de données (DML) accèdent simultanément aux mêmes lignes de base de données. Pour de plus amples informations, veuillez consulter [synch/cond/innodb/row\$1bloquer\$1attendre](ams-waits.row-lock-wait.md). **synch/cond/innodb/row\$1lock\$1wait\$1cond** Plusieurs instructions DML accèdent simultanément aux mêmes lignes de base de données. Pour de plus amples informations, veuillez consulter [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md). **synch/cond/sql/MDL\$1context : :Cond\$1Wait\$1Status** Les threads attendent sur un verrou de métadonnées de table. Le moteur utilise ce type de verrou pour gérer l’accès simultané à un schéma de base de données et assurer la cohérence des données. Pour plus d’informations, consultez [Optimizing Locking Operations](https://dev.mysql.com/doc/refman/8.0/en/locking-issues.html) dans la documentation MySQL. Pour savoir comment régler votre base de données lorsque cet événement est important, consultez [synch/cond/sql/MDL\$1context : :Cond\$1Wait\$1Status](ams-waits.cond-wait-status.md). **synch/cond/sql/MYSQL\$1BIN\$1LOG : :Cond\$1Done** Vous avez activé la journalisation binaire. Il peut y avoir un débit de validation élevé, un grand nombre de transactions en cours de validation ou des réplicas lisant des journaux binaires. Envisagez d’utiliser des instructions à plusieurs lignes ou de regrouper des instructions dans une seule transaction. Dans Aurora, privilégiez les bases de données globales à la réplication des journaux binaires, ou utilisez le paramètres `aurora_binlog_*`. **synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex** Plusieurs instructions DML accèdent simultanément aux mêmes lignes de base de données. Pour de plus amples informations, veuillez consulter [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md). **synch/mutex/innodb/buf\$1pool\$1mutex** Le groupe de mémoires de tampons n’est pas suffisamment grand pour contenir l’ensemble de données de travail. Ou bien, la charge de travail accède aux pages d’une table spécifique, ce qui entraîne une contention dans le groupe de mémoires tampons. Pour de plus amples informations, veuillez consulter [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md). **synch/mutex/innodb/fil\$1system\$1mutex** Le processus est en attente d’accès au cache mémoire de l’espace disque logique. Pour de plus amples informations, veuillez consulter [synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md). **synch/mutex/innodb/trx\$1sys\$1mutex** Les opérations vérifient, mettent à jour, suppriment ou ajoutent des transactions IDs dans InnoDB de manière cohérente ou contrôlée. Ces opérations nécessitent un appel de mutex `trx_sys`, suivi par l’instrumentation Performance Schema. Parmi les opérations figurent les suivantes : gestion du système de transactions lorsque la base de données démarre ou s’arrête, restaurations, nettoyages après annulation, accès en lecture de ligne et charges de groupe de mémoires tampons. Une charge de base de données élevée avec un grand nombre de transactions entraîne l’apparition fréquente de cet événement d’attente. Pour de plus amples informations, veuillez consulter [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md). **synch/mutex/mysys/KEY\$1CACHE : :cache\$1lock** Le mutex `keycache->cache_lock` contrôle l’accès au cache de clé pour les tables MyISAM. Bien qu’Aurora MySQL n’autorise pas l’utilisation des tables MyISAM pour stocker des données persistantes, elles sont utilisées pour stocker des tables temporaires internes de stockage. Envisagez de vérifier les compteurs d’état `created_tmp_tables` et `created_tmp_disk_tables`, car dans certaines situations, les tables temporaires sont écrites sur le disque lorsqu’elles ne tiennent plus dans la mémoire. **synch/mutex/sql/FILE\$1AS\$1TABLE : :Lock\$1Offsets** Le moteur acquiert ce mutex lors de l’ouverture ou de la création d’un fichier de métadonnées de table. Lorsque cet événement d’attente se produit à une fréquence excessive, le nombre de tables créées ou ouvertes a connu un pic. **synch/mutex/sql/FILE\$1AS\$1TABLE : :Lock\$1Shim\$1Lists** Le moteur acquiert ce mutex tout en effectuant des opérations telles que `reset_size`, `detach_contents` ou `add_contents` sur la structure interne qui permet de suivre les tables ouvertes. Le mutex synchronise l’accès au contenu de la liste. Lorsque cet événement d’attente se produit très fréquemment, cela indique un changement soudain de l’ensemble de tables précédemment consultées. Le moteur doit accéder à de nouvelles tables ou renoncer au contexte lié aux tables précédemment consultées. **synch/mutex/sql/LOCK\$1ouvert** Le nombre de tables que vos sessions ouvrent dépasse la taille du cache de définition de table ou du cache ouvert de table. Augmentez la taille de ces caches. Pour plus d’informations, consultez [How MySQL opens and closes tables](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html). **synch/mutex/sql/LOCK\$1cache\$1table** Le nombre de tables que vos sessions ouvrent dépasse la taille du cache de définition de table ou du cache ouvert de table. Augmentez la taille de ces caches. Pour plus d’informations, consultez [How MySQL opens and closes tables](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html). **synch/mutex/sql/LOG** Dans cet événement d’attente, certains threads attendent un verrouillage des journaux. Par exemple,un thread peut attendre qu’un verrouillage écrive dans le fichier journal de requêtes lentes. **synch/mutex/sql/MYSQL\$1BIN\$1LOG : :LOCK\$1COMMIT** Dans cet événement d’attente, un thread attend d’acquérir un verrouillage avec l’intention de valider dans le journal binaire. Des conflits de journalisation binaire peuvent se produire sur des bases de données présentant un rythme de changement très élevé. Selon votre version de MySQL, certains verrouillages sont utilisés pour protéger la cohérence et la longévité du journal binaire. Dans RDS pour MySQL, les journaux binaires sont utilisés pour la réplication et le processus de sauvegarde automatisée. Dans Aurora MySQL, les journaux binaires ne sont pas nécessaires pour la réplication native ou les sauvegardes. Ils sont désactivés par défaut, mais ils peuvent être activés et utilisés pour la réplication externe ou la capture des données modifiées. Pour plus d’informations, consultez [The Binary Log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) dans la documentation MySQL. **sync/mutex/sql/MYSQL\$1BIN\$1LOG : :Lock\$1Dump\$1Thread\$1Metrics\$1Collection** Si la journalisation binaire est activée, le moteur acquiert ce mutex lorsqu’il imprime des métriques de threads de vidage actifs dans le journal des erreurs du moteur et sur le mappage des opérations internes. **sync/mutex/sql/MYSQL\$1BIN\$1LOG : :LOCK\$1INACTIVE\$1BINLOGS\$1MAP** Si la journalisation binaire est activée, le moteur acquiert ce mutex lorsqu’il ajoute, supprime ou effectue une recherche dans la liste des fichiers binlog antérieurs au plus récent. **sync/mutex/sql/MYSQL\$1BIN\$1LOG : :LOCK\$1IO\$1CACHE** Si la journalisation binaire est activée, le moteur acquiert ce mutex lors des opérations de cache d’I/O du journal binaire Aurora : allouer, redimensionner, libérer, écrire, lire, purger et accéder aux informations du cache. Si cet événement se produit fréquemment, le moteur accède au cache où les événements de journal binaire sont stockés. Pour réduire les temps d’attente, réduisez les validations. Essayez de regrouper plusieurs instructions dans une seule transaction. **synch/mutex/sql/MYSQL\$1BIN\$1LOG : :LOCK\$1LOG** Vous avez activé la journalisation binaire. Il peut y avoir un débit de validation élevé, de nombreuses transactions en cours de validation ou des réplicas lisant des journaux binaires. Envisagez d’utiliser des instructions à plusieurs lignes ou de regrouper des instructions dans une seule transaction. Dans Aurora, privilégiez les bases de données globales à la réplication des journaux binaires, ou utilisez le paramètres `aurora_binlog_*`. **synch/mutex/sql/SERVER\$1THREAD : :Lock\$1Sync** Le mutex `SERVER_THREAD::LOCK_sync` est acquis lors de la planification, du traitement ou du lancement de threads pour les écritures de fichier. Si cet événement d’attente se produit de manière excessive, cela indique une activité d’écriture accrue dans la base de données. **synch/mutex/sql/TABLESPACES:verrou** Le moteur acquiert le mutex `TABLESPACES:lock` lors des opérations d’espace disque logique suivantes : créer, supprimer, tronquer et étendre. Si cet événement d’attente se produit de manière excessive, cela indique une fréquence élevée d’opérations d’espace disque logique. Le chargement d’une grande quantité de données dans la base de données en est un exemple. **synch/rwlock/innodb/dict** Dans cet événement d’attente, certains threads attendent un rwlock maintenu sur le dictionnaire de données InnoDB. **synch/rwlock/innodb/dict\$1operation\$1lock** Dans cet événement d’attente, certains threads maintiennent des verrouillages sur les opérations de dictionnaire de données InnoDB. **synch/rwlock/innodb/dictsystème RW lock** Un grand nombre d'instructions simultanées du langage de contrôle des données (DCLs) dans le code du langage de définition des données (DDLs) sont déclenchées simultanément. Réduisez la dépendance de l'application par rapport à DDLs l'activité normale de l'application. **synch/rwlock/innodb/index\$1tree\$1rw\$1lock** Un grand nombre d’instructions en langage de manipulation de données (DML) accèdent simultanément au même objet de base de données. Essayez d’utiliser des instructions à plusieurs lignes. Répartissez également la charge de travail sur différents objets de base de données. Par exemple, implémentez le partitionnement. **synch/sxlock/innodb/dict\$1operation\$1lock** Un grand nombre d'instructions simultanées du langage de contrôle des données (DCLs) dans le code du langage de définition des données (DDLs) sont déclenchées simultanément. Réduisez la dépendance de l'application par rapport à DDLs l'activité normale de l'application. **synch/sxlock/innodb/dict\$1sys\$1lock** Un grand nombre d'instructions simultanées du langage de contrôle des données (DCLs) dans le code du langage de définition des données (DDLs) sont déclenchées simultanément. Réduisez la dépendance de l'application par rapport à DDLs l'activité normale de l'application. **synch/sxlock/innodb/hash\$1verrous de table** La session n’a pas pu trouver de pages dans le groupe de mémoires tampons. Le moteur doit lire un fichier ou modifier la liste utilisée le moins récemment (LRU) pour le groupe de mémoires tampons. Envisagez d’augmenter la taille du cache de mémoire tampon et d’améliorer les chemins d’accès pour les requêtes pertinentes. **synch/sxlock/innodb/index\$1tree\$1rw\$1lock** Un grand nombre d’instructions similaires en langage de manipulation de données (DML) accèdent simultanément au même objet de base de données. Essayez d’utiliser des instructions à plusieurs lignes. Répartissez également la charge de travail sur différents objets de base de données. Par exemple, implémentez le partitionnement. **synch/mutex/innodb/temp\$1pool\$1manager\$1mutex** Cet événement d'attente se produit lorsqu'une session attend d'acquérir un mutex pour gérer le pool de tablespaces temporaires de session. Pour plus d’informations sur le dépannage des événements d’attente SYNCH, consultez [Pourquoi mon instance DB MySQL affiche-t-il un nombre élevé de séances actives en attente sur les événements d’attente SYNCH dans Performance Insights ?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-mysql-synch-wait-events/) # États de thread Aurora MySQL Voici quelques états de thread courants pour Aurora MySQL. **checking permissions** Le thread vérifie si le serveur dispose des privilèges requis pour exécuter l’instruction. **checking query cache for query** Le serveur vérifie si la requête actuelle est présente dans le cache de requête. **cleaned up** Il s’agit de l’état final d’une connexion dont la tâche est terminée, mais qui n’a pas été fermée par le client. La meilleure solution consiste à fermer explicitement la connexion dans le code. Vous pouvez également définir une valeur inférieure pour `wait_timeout` dans votre groupe de paramètres. **closing tables** Le thread vide les données de table modifiées sur le disque et ferme les tables utilisées. Si l’opération se prolonge, vérifiez les métriques de consommation de bande passante réseau par rapport à la bande passante réseau de classe d’instance. Vérifiez également que les valeurs des paramètres pour `table_open_cache`et `table_definition_cache` permettent d’ouvrir simultanément un nombre suffisant de tables pour éviter au moteur de devoir ouvrir et fermer fréquemment les tables. Ces paramètres ont une incidence sur la consommation de mémoire sur l’instance. **converting HEAP to MyISAM** La requête convertit une table temporaire de table en mémoire à table sur disque. Cette conversion est nécessaire car les tables temporaires créées par MySQL au cours des étapes intermédiaires du traitement des requêtes sont devenues trop volumineuses pour la mémoire. Vérifiez les valeurs de `tmp_table_size` et `max_heap_table_size`. Dans les versions ultérieures, ce nom d’état de thread est`converting HEAP to ondisk`. **converting HEAP to ondisk** Le thread convertit une table temporaire interne de table en mémoire à table sur disque. **copy to tmp table** Le thread traite une instruction `ALTER TABLE`. Cet état intervient après la création de la table avec la nouvelle structure, mais avant que des lignes n’y soient copiées. En présence d’un thread dans cet état, vous pouvez utiliser le schéma de performance pour obtenir des informations relatives à la progression de l’opération de copie. **creating sort index** Aurora MySQL effectue un tri, car il n’est pas en mesure d’utiliser un index existant pour satisfaire la clause `ORDER BY` ou `GROUP BY` d’une requête. Pour plus d’informations, consultez [creating sort index](ams-states.sort-index.md). **creating table** Le thread crée une table permanente ou temporaire. **delayed commit ok done** Dans Aurora MySQL, une validation asynchrone a reçu un accusé de réception et est terminée. **delayed commit ok initiated** Le thread Aurora MySQL a démarré le processus de validation asynchrone, mais attend l’accusé de réception. Il s’agit généralement du moment auquel une transaction est validée. **delayed send ok done** Un thread de travail Aurora MySQL lié à une connexion peut être libéré lorsqu’une réponse est envoyée au client. Le thread peut entamer d’autres tâches. L’état `delayed send ok` signifie que l’accusé de réception asynchrone adressé au client est terminé. **delayed send ok initiated** Un thread de travail Aurora MySQL a envoyé une réponse de manière asynchrone à un client et est désormais libre pour d’autres connexions. La transaction a lancé un processus de validation asynchrone qui n’a pas encore été confirmé. **executing** Le thread a commencé à exécuter une instruction. **freeing items** Le thread a exécuté une commande. La libération de certains éléments durant cet état implique le cache de requête. Cet état est généralement suivi d’un nettoyage. **init** Cet état intervient avant l’initialisation des instructions `ALTER TABLE`, `DELETE`, `INSERT`, `SELECT` ou `UPDATE`. Les actions correspondant à cet état incluent le vidage du journal binaire ou du journal InnoDB, et le nettoyage du cache de requête. **La source a envoyé tous les journaux binaires au réplica ; en attente de nouvelles mises à jour** Le nœud primaire a terminé sa part de la réplication. Le thread attend l’exécution d’autres requêtes pour pouvoir écrire dans le journal binaire (binlog). **opening tables** Le thread essaie d’ouvrir une table. Cette opération est rapide, sauf si une instruction `ALTER TABLE` ou `LOCK TABLE`doit se terminer, ou si elle dépasse la valeur de `table_open_cache`. **optimizing** Le serveur effectue des optimisations initiales pour une requête. **preparing** Cet état intervient lors de l’optimisation des requêtes. **query end** Cet état intervient après le traitement d’une requête, mais avant l’état de libération des éléments. **removing duplicates** Aurora MySQL n’a pas pu optimiser une opération `DISTINCT` au début d’une requête. Aurora MySQL doit supprimer toutes les lignes dupliquées avant d’envoyer le résultat au client. **searching rows for update** Le thread recherche toutes les lignes correspondantes avant de les mettre à jour. Cette étape est nécessaire si la `UPDATE` modifie l’index utilisé par le moteur pour trouver les lignes. **sending binlog event to slave** Le thread lit un événement à partir du journal binaire et l’envoie au réplica. **sending cached result to client** Le serveur extrait le résultat d’une requête du cache de requête et l’envoie au client. **sending data** Le thread lit et traite les lignes d’une instruction `SELECT`, mais n’a pas encore commencé à envoyer des données au client. Le processus consiste à identifier les pages qui contiennent les résultats nécessaires pour satisfaire la requête. Pour plus d’informations, consultez [envoi de données](ams-states.sending-data.md). **sending to client** Le serveur écrit un paquet sur le client. Dans les versions antérieures de MySQL, cet événement d’attente était labélisé `writing to net`. **démarrage** Il s’agit de la première étape intervenant au début de l’exécution de l’instruction. **statistics** Le serveur calcule des statistiques pour développer un plan d’exécution des requêtes. Si un thread perdure dans cet état, le serveur est probablement lié au disque pendant qu’il effectue d’autres tâches. **storing result in query cache** Le serveur stocke le résultat d’une requête dans le cache de requête. **system lock** Le thread a appelé `mysql_lock_tables`, mais l’état du thread n’a pas été mis à jour depuis l’appel. Cet état général intervient pour de nombreuses raisons. **mise à jour** Le thread se prépare à commencer à mettre à jour la table. **updating** Le thread recherche des lignes et les met à jour. **user lock** Le thread a émis un appel `GET_LOCK`. Le thread a demandé un verrou consultatif et l’attend, ou envisage de le demander. **waiting for more updates** Le nœud primaire a terminé sa part de la réplication. Le thread attend l’exécution d’autres requêtes pour pouvoir écrire dans le journal binaire (binlog). **waiting for schema metadata lock** Il s’agit de l’attente d’un verrou de métadonnées. **waiting for stored function metadata lock** Il s’agit de l’attente d’un verrou de métadonnées. **waiting for stored procedure metadata lock** Il s’agit de l’attente d’un verrou de métadonnées. **waiting for table flush** Le thread exécute `FLUSH TABLES` et attend que tous les threads de ferment leurs tables. Ou bien, le thread a reçu une notification indiquant que la structure sous-jacente d’une table a changé et qu’il lui faut rouvrir cette table pour obtenir la nouvelle structure. Pour rouvrir cette table, le thread doit attendre que tous les autres threads l’aient fermée. Cette notification intervient si un autre thread a utilisé une des instructions suivantes sur la table : `FLUSH TABLES`, `ALTER TABLE`, `RENAME TABLE`, `REPAIR TABLE`, `ANALYZE TABLE` ou `OPTIMIZE TABLE`. **waiting for table level lock** Une session maintient un verrou sur une table tandis qu’une autre tente d’acquérir le même verrou sur la même table. **waiting for table metadata lock** Aurora MySQL utilise le verrouillage des métadonnées pour gérer l’accès simultané aux objets de base de données et assurer la cohérence des données. Dans cet événement d’attente, une session maintient un verrou de métadonnées sur une table tandis qu’une autre tente d’acquérir le même verrou sur la même table. Lorsque le schéma de performance est activé, cet état de thread est signalé en tant qu’événement d’attente `synch/cond/sql/MDL_context::COND_wait_status`. **writing to net** Le serveur écrit un paquet sur le réseau. Dans les versions ultérieures de MySQL, cet événement d’attente est labélisé `Sending to client`. # Niveaux d’isolement Aurora MySQL Découvrez comment les instances de base de données d’un cluster Aurora MySQL implémentent la propriété d’isolement d’une base de données. Cette rubrique explique comment le comportement par défaut d’Aurora MySQL cherche l’équilibre entre une cohérence stricte et des performances élevées. Vous pouvez utiliser ces informations pour décider quand modifier les paramètres par défaut en fonction des caractéristiques de votre charge de travail. ## Niveaux d’isolement disponibles pour les instances d’enregistreur Vous pouvez utiliser les niveaux d’isolement `REPEATABLE READ`, `READ COMMITTED`, `READ UNCOMMITTED` et `SERIALIZABLE` sur l’instance principale d’un cluster de bases de données Aurora MySQL. Ces niveaux d’isolement fonctionnent de la même façon dans Aurora MySQL que dans RDS for MySQL. ## Niveaux d’isolement REPEATABLE READ pour les instances de lecteur Par défaut, les instances de base de données Aurora MySQL configurées comme réplicas Aurora en lecture seule utilisent toujours le niveau d’isolement `REPEATABLE READ`. Ces instances de bases de données ignorent toutes les instructions `SET TRANSACTION ISOLATION LEVEL` et continuent à utiliser le niveau d’isolement `REPEATABLE READ`. ## Niveaux d’isolement READ COMMITTED pour les instances en lecture Si votre application inclut une charge de travail gourmande en écriture sur l’instance principale et des requêtes de longue durée sur les réplicas Aurora, il se peut que vous soyez confronté à un retard de purge conséquent. Le *retard de purge* se produit quand le nettoyage interne de la mémoire est bloqué par les requêtes de longue durée. Le symptôme que vous voyez est une valeur élevée pour `history list length` dans la sortie de la commande `SHOW ENGINE INNODB STATUS`. Vous pouvez superviser cette valeur dans CloudWatch à l'aide de la métrique `RollbackSegmentHistoryListLength`. Un retard de purge substantiel peut réduire l’efficacité des index secondaires, réduire les performances globales des requêtes et conduire à un gaspillage de l’espace de stockage. Si vous rencontrez de tels problèmes, vous pouvez définir un paramètre de configuration de niveau session Aurora MySQL, `aurora_read_replica_read_committed`, pour utiliser le niveau d’isolement `READ COMMITTED` sur les réplicas Aurora. Quand vous appliquez ce paramètre, vous pouvez aider à diminuer les ralentissements et l’espace gaspillé qui peuvent résulter de l’exécution de requêtes de longue durée simultanément aux transactions qui modifient vos tables. Nous vous recommandons de bien comprendre le comportement spécifique d’Aurora MySQL de l’isolement `READ COMMITTED` avant d’utiliser ce paramètre. Le comportement `READ COMMITTED` du réplica Aurora est conforme à la norme ANSI SQL. Cependant, le niveau d’isolement est moins strict que le comportement `READ COMMITTED` MySQL classique que vous connaissez sans doute. Par conséquent, vous pouvez voir des résultats de requête sous `READ COMMITTED` sur un réplica en lecture Aurora MySQL différents de ceux de la même requête sous `READ COMMITTED` sur l’instance principale Aurora MySQL ou sur RDS for MySQL. Vous pouvez envisager d’utiliser le paramètre `aurora_read_replica_read_committed` pour ces cas d’utilisation en tant que rapport exhaustif qui couvre une base de données très volumineuse. En revanche, vous pouvez l’éviter dans le cas de courtes requêtes avec des ensembles de résultats réduits, où la précision et la reproductibilité sont importantes. Le niveau d’isolement `READ COMMITTED` n’est pas disponible pour les sessions dans un cluster secondaire dans une base de données Aurora globale qui utilisent la fonction de transfert d’écriture. Pour plus d’informations sur le transfert d’écriture, consultez [Utilisation du transfert d'écriture dans une base de données globale Amazon Aurora](aurora-global-database-write-forwarding.md). ### Utilisation de READ COMMITTED pour les lecteurs Pour utiliser le niveau d’isolement `READ COMMITTED` pour les réplicas Aurora, définissez le paramètre de configuration `aurora_read_replica_read_committed` sur `ON`. Utilisez ce paramètre au niveau de la session tout en étant connecté à un réplica Aurora spécifique. Pour ce faire, exécutez les commandes SQL suivantes : ``` set session aurora_read_replica_read_committed = ON; set session transaction isolation level read committed; ``` Vous pouvez utiliser ce paramètre de configuration temporairement pour exécuter des requêtes uniques interactives. Il se peut aussi que vous souhaitiez exécuter un rapport ou une application d’analyse des données qui tire profit du niveau d’isolement `READ COMMITTED`, tout en conservant le paramètre par défaut inchangé pour les autres applications. Quand le paramètre `aurora_read_replica_read_committed` est activé, utilisez la commande `SET TRANSACTION ISOLATION LEVEL` pour spécifier le niveau d’isolement pour les transactions appropriées. ``` set transaction isolation level read committed; ``` ### Différences de comportement READ COMMITTED sur les réplicas Aurora Le paramètre `aurora_read_replica_read_committed` garantit la disponibilité du niveau d’isolement `READ COMMITTED` pour un réplica Aurora, avec une cohérence optimisée pour les transactions de longue durée. Le niveau d’isolement `READ COMMITTED` sur les réplicas Aurora offre un isolement moins strict que sur les instances principales Aurora. Pour cette raison, l’activation de ce paramètre uniquement sur les réplicas Aurora où vous savez que vos requêtes peuvent accepter la possibilité de certains types de résultats incohérents. Vos requêtes peuvent expérimenter certains types d’anomalies en lecture quand le paramètre `aurora_read_replica_read_committed` est activé. Deux types d’anomalies sont particulièrement importants à comprendre et à gérer dans le code de votre application. Une *lecture non reproductible* se produit quand une autre transaction est validée tandis que votre requête est en cours d’exécution. Une requête de longue durée peut voir des données au démarrage de la requête différentes de celles qu’il voit à la fin. Une *lecture fantôme* se produit quand d’autres transactions entraînent une réorganisation des lignes existantes tandis que votre requête est en cours d’exécution, et qu’une ou plusieurs lignes sont lues deux fois par votre requête. Vos requêtes peuvent expérimenter des nombres de lignes incohérents comme résultat des lectures fantômes. Vos requêtes peuvent aussi retourner des résultats incomplets ou incohérents suite à des lectures non reproductibles. Par exemple, supposons qu’une opération de jointure fasse référence à des tables modifiées simultanément par des instructions SQL, telles que `INSERT` ou `DELETE`. Dans ce cas, la requête de jointure peut lire une ligne d’une autre table, mais pas la ligne correspondante d’une autre table. La norme ANSI SQL permet les deux comportements pour le niveau d’isolement `READ COMMITTED`. Cependant, ces comportements diffèrent de l’implémentation MySQL typique de `READ COMMITTED`. Ainsi, avant d’activer le paramètre `aurora_read_replica_read_committed`, vérifiez le code SQL existant pour vous assurer qu’il fonctionne comme attendu selon le modèle de cohérence le moins strict. Les nombres de lignes et autres résultats peuvent ne pas offrir une cohérence forte sous le niveau d’isolement `READ COMMITTED` lorsque ce paramètre est activé. Ainsi, vous n’activez généralement le paramètre que lors de l’exécution de requêtes analytiques qui agrègent d’importantes quantités de données et ne nécessitent pas une précision absolue. Si vous n’avez pas ces types de requêtes de longue durée en même temps qu’une charge de travail gourmande en écriture, vous n’avez probablement pas besoin du paramètre `aurora_read_replica_read_committed`. Sans la combinaison de requêtes de longue durée et une charge de travail gourmande en écriture, il est peu probable que vous rencontriez des problèmes avec la longueur de la liste de l’historique. **Example Requêtes illustrant le comportement d’isolement pour READ COMMITTED sur les réplicas Aurora** L’exemple suivant montre comment les requêtes `READ COMMITTED` sur un réplica Aurora peuvent retourner des résultats non reproductibles si les transactions modifient en même temps les tables associées. La table `BIG_TABLE` contient 1 million de lignes avant le démarrage des requêtes. D’autres instructions en langage de manipulation de données (DML) ajoutent, suppriment ou modifient des lignes tandis qu’elles s’exécutent. Les requêtes sur l’instance principale Aurora sous le niveau d’isolement `READ COMMITTED` produisent des résultats prévisibles. Cependant, la surcharge qu’entraîne la conservation d’une vue cohérente en lecture pendant la durée de vie de chaque requête de longue durée peut conduire par la suite à un nettoyage de la mémoire onéreux. Les requêtes sur le réplica Aurora sous le niveau d’isolement `READ COMMITTED` sont optimisées pour réduire cette surcharge du nettoyage de la mémoire. Le compromis est que les résultats peuvent varier selon que les requêtes récupèrent ou non les lignes qui sont ajoutées, supprimées ou réorganisées par les transactions qui sont validées pendant que la requête est en cours d’exécution. Les requêtes sont autorisées à prendre en compte ces lignes, mais elles n’y sont pas obligées. À des fins de démonstration, les requêtes vérifient uniquement le nombre de lignes de la table à l’aide de la fonction `COUNT(*)`. | Heure | Instruction DML sur une instance principale Aurora | Requête sur une instance principale Aurora avec READ COMMITTED | Requête sur un réplica Aurora avec READ COMMITTED | | --- | --- | --- | --- | | T1 | INSERT INTO big\$1table SELECT \$1 FROM other\$1table LIMIT 1000000; COMMIT; | | | | T2 | | Q1: SELECT COUNT(\$1) FROM big\$1table; | Q2: SELECT COUNT(\$1) FROM big\$1table; | | T3 | INSERT INTO big\$1table (c1, c2) VALUES (1, 'one more row'); COMMIT; | | | | T4 | | Si Q1 se termine maintenant, le résultat est 1 000 000. | Si Q2 se termine maintenant, le résultat est 1 000 000 ou 1 000 001. | | T5 | DELETE FROM big\$1table LIMIT 2; COMMIT; | | | | T6 | | Si Q1 se termine maintenant, le résultat est 1 000 000. | Si Q2 se termine maintenant, le résultat est 1 000 000, 1 000 001, 999 999 ou 999 998. | | T7 | UPDATE big\$1table SET c2 = CONCAT(c2,c2,c2); COMMIT; | | | | T8 | | Si Q1 se termine maintenant, le résultat est 1 000 000. | Si Q2 se termine maintenant, le résultat est 1 000 000 ou 1 000 001 ou 999 999, ou même un nombre supérieur. | | T9 | | Q3: SELECT COUNT(\$1) FROM big\$1table; | Q4: SELECT COUNT(\$1) FROM big\$1table; | | T10 | | Si Q3 se termine maintenant, le résultat est 999 999. | Si Q4 se termine maintenant, le résultat est 999 999. | | T11 | | Q5: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; | Q6: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; | | T12 | INSERT INTO parent\$1table (id, s) VALUES (1000, 'hello'); INSERT INTO child\$1table (id, s) VALUES (1000, 'world'); COMMIT; | | | | T13 | | Si Q5 se termine maintenant, le résultat est 0. | Si Q6 se termine maintenant, le résultat est 0 ou 1. | Si les requêtes se finissent rapidement avant que d’autres transactions n’exécutent les instructions DML et les validations, les résultats sont prévisibles et identiques entre l’instance principale et le réplica Aurora. Examinons les différences de comportement en détail, en commençant par la première requête. Les résultats de Q1 sont hautement prévisibles, car `READ COMMITTED` sur l’instance principale utilise un modèle de cohérence forte similaire au niveau d’isolement `REPEATABLE READ`. Les résultats de Q2 peuvent varier en fonction des transactions qui sont validées pendant que la requête est en cours d’exécution. Par exemple, supposons que d’autres transactions exécutent des instructions DML et soient validées tandis que les requêtes sont en cours d’exécution. Dans ce cas, la requête sur le réplica Aurora avec le niveau d’isolement `READ COMMITTED` peut ou non prendre en compte les modifications. Les nombres de lignes ne sont pas prévisibles de la même façon que sous le niveau d’isolement `REPEATABLE READ`. De même, ils ne sont pas aussi prévisibles que les requêtes s’exécutant sous le niveau d’isolement `READ COMMITTED` sur l’instance principale ou sur une instance RDS for MySQL. L’instruction `UPDATE` à T7 ne modifie pas réellement le nombre de lignes de la table. Cependant, en modifiant la longueur d’une colonne de longueur variable, cette instruction peut entraîner une réorganisation interne des lignes. Une transaction `READ COMMITTED` de longue durée peut afficher l’ancienne version d’une ligne, et, par la suite, au sein de la même requête, afficher la nouvelle version de la même ligne. La requête peut également ignorer l’ancienne et la nouvelle version de la ligne, de sorte que le nombre de lignes peut être différent de ce qui est attendu. Les résultats de Q5 et Q6 peuvent être identiques ou légèrement différents. La requête Q6 sur le réplica Aurora sous `READ COMMITTED` peut afficher, mais elle n’est pas obligée à la faire, les nouvelles lignes validées pendant que la requête est en cours d’exécution. Elle peut également afficher la ligne d’une table, mais pas de l’autre table. Si la requête de jointure ne trouve pas de ligne correspondante dans les deux tables, elle retourne un nombre égal à 0 (zéro). Si la requête retrouve bel et bien les nouvelles lignes dans `PARENT_TABLE` et dans `CHILD_TABLE`, la requête retourne un nombre égal à 1 (un). Dans une requête de longue durée, les recherches à partir des tables jointes peuvent se produire à d’importants intervalles de temps. Ces différences de comportement dépendent du moment où les transactions sont validées et de celui où les requêtes traitent les lignes de la table sous-jacente. Ainsi, il est fort probable que vous rencontriez de telles différences dans les requêtes sur les rapports qui nécessitent plusieurs minutes ou heures, et qui s’exécutent sur des clusters Aurora traitant simultanément les transactions OLTP. Ce sont les types de charges de travail mixtes qui tirent le meilleur parti du niveau d’isolement `READ COMMITTED` sur les réplicas Aurora. # Indicateurs Aurora MySQL Vous pouvez utiliser des indicateurs SQL avec des requêtes Aurora MySQL pour ajuster les performances. Vous pouvez également utiliser des indicateurs pour empêcher que les plans d’exécution des requêtes importantes ne changent en fonction de conditions imprévisibles. **Astuce** Pour vérifier l’effet d’un indicateur sur une requête, examinez le plan de requête produit par l’instruction `EXPLAIN`. Comparez les plans de requête avec et sans l’indicateur. Dans Aurora MySQL version 3, vous pouvez utiliser tous les indicateurs disponibles dans MySQL Community Edition 8.0. Pour plus d’informations sur ces indicateurs, consultez [Optimizer Hints](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) (Indicateurs d’optimiseur) dans le *Manuel de référence MySQL*. Les indicateurs suivants sont disponibles dans Aurora MySQL version 2. Ces indicateurs s’appliquent aux requêtes qui utilisent la fonction de jointure par hachage dans Aurora MySQL version 2, notamment les requêtes utilisant l’optimisation via les requêtes parallèles. **PQ, NO\$1PQ** Spécifie s’il faut forcer l’optimiseur à utiliser une requête parallèle par table ou par requête. `PQ` force l’optimiseur à utiliser une requête parallèle pour les tables spécifiées ou pour l’ensemble de la requête (bloc). `NO_PQ` empêche l’optimiseur d’utiliser une requête parallèle pour des tables spécifiées ou pour l’ensemble de la requête (bloc). Cet indicateur est disponible dans Aurora MySQL versions 2.11 et ultérieures. Les exemples suivants vous montrent comment utiliser cet indicateur. La spécification d’un nom de table force l’optimiseur à appliquer l’indicateur `PQ/NO_PQ` uniquement aux tables sélectionnées. Le fait de ne pas spécifier de nom de table force l’indicateur `PQ/NO_PQ` sur toutes les tables concernées par le bloc de requête. ``` EXPLAIN SELECT /*+ PQ() */ f1, f2 FROM num1 t1 WHERE f1 > 10 and f2 < 100; EXPLAIN SELECT /*+ PQ(t1) */ f1, f2 FROM num1 t1 WHERE f1 > 10 and f2 < 100; EXPLAIN SELECT /*+ PQ(t1,t2) */ f1, f2 FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21; EXPLAIN SELECT /*+ NO_PQ() */ f1, f2 FROM num1 t1 WHERE f1 > 10 and f2 < 100; EXPLAIN SELECT /*+ NO_PQ(t1) */ f1, f2 FROM num1 t1 WHERE f1 > 10 and f2 < 100; EXPLAIN SELECT /*+ NO_PQ(t1,t2) */ f1, f2 FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21; ``` **HASH\$1JOIN, NO\$1HASH\$1JOIN** Active ou désactive la capacité de l’optimiseur de requête parallèle à choisir d’utiliser la méthode d’optimisation de jointure de hachage pour une requête. `HASH_JOIN` laisse l’optimiseur utiliser la jointure de hachage si ce mécanisme est plus efficace. `NO_HASH_JOIN` empêche l’optimiseur d’utiliser la jointure de hachage pour la requête. Cet indicateur est disponible dans Aurora MySQL versions 2.08 et ultérieures. Il est sans effet dans Aurora MySQL version 3. Les exemples suivants vous montrent comment utiliser cet indicateur. ``` EXPLAIN SELECT/*+ HASH_JOIN(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ NO_HASH_JOIN(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; ``` **HASH\$1JOIN\$1PROBING, NO\$1HASH\$1JOIN\$1PROBING** Dans une requête de jointure de hachage, il indique s’il faut utiliser la table spécifiée pour le côté sonde de la jointure. La requête vérifie si les valeurs de colonne de la table de build existent dans la table de sonde, au lieu de lire l’intégralité du contenu de cette dernière. Vous pouvez utiliser `HASH_JOIN_PROBING` et `HASH_JOIN_BUILDING` pour spécifier comment les requêtes de jointure de hachage sont traitées sans réordonner les tables dans le texte de la requête. Cet indicateur est disponible dans Aurora MySQL versions 2.08 et ultérieures. Il est sans effet dans Aurora MySQL version 3. Les exemples suivants montrent comment utiliser cet indicateur. La spécification de l’indicateur `HASH_JOIN_PROBING` pour la table `T2` a le même effet que la spécification `NO_HASH_JOIN_PROBING` pour la table `T1`. ``` EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_PROBING(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_PROBING(t1) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; ``` **HASH\$1JOIN\$1BUILDING, NO\$1HASH\$1JOIN\$1BUILDING** Dans une requête de jointure de hachage, spécifie s’il faut utiliser la table spécifiée pour le côté build de la jointure. La requête traite toutes les lignes de cette table pour créer la liste des valeurs de colonne à recouper avec l’autre table. Vous pouvez utiliser `HASH_JOIN_PROBING` et `HASH_JOIN_BUILDING` pour spécifier comment les requêtes de jointure de hachage sont traitées sans réordonner les tables dans le texte de la requête. Cet indicateur est disponible dans Aurora MySQL versions 2.08 et ultérieures. Il est sans effet dans Aurora MySQL version 3. L’exemple suivant vous montre comment utiliser cet indicateur. La spécification de l’indicateur `HASH_JOIN_BUILDING` pour la table `T2` a le même effet que la spécification `NO_HASH_JOIN_BUILDING` pour la table `T1`. ``` EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_BUILDING(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_BUILDING(t1) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; ``` **JOIN\$1FIXED\$1ORDER** Spécifie que les tables de la requête sont jointes en fonction de l’ordre dans lequel elles sont répertoriées dans la requête. Il est utile pour les requêtes impliquant trois tables ou plus. Il est destiné à remplacer l’indicateur MySQL `STRAIGHT_JOIN` et il est équivalent à l’indicateur MySQL [JOIN\$1FIXED\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). Cet indicateur est disponible dans Aurora MySQL versions 2.08 et ultérieures. L’exemple suivant vous montre comment utiliser cet indicateur. ``` EXPLAIN SELECT /*+ JOIN_FIXED_ORDER() */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); ``` **JOIN\$1ORDER** Spécifie l’ordre de jointure des tables de la requête. Il est utile pour les requêtes impliquant trois tables ou plus. Il est équivalent à l’indicateur MySQL [JOIN\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). Cet indicateur est disponible dans Aurora MySQL versions 2.08 et ultérieures. L’exemple suivant vous montre comment utiliser cet indicateur. ``` EXPLAIN SELECT /*+ JOIN_ORDER (t4, t2, t1, t3) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); ``` **JOIN\$1PREFIX** Spécifie les tables à placer en premier dans l’ordre de jointure. Il est utile pour les requêtes impliquant trois tables ou plus. Il est équivalent à l’indicateur MySQL [JOIN\$1PREFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). Cet indicateur est disponible dans Aurora MySQL versions 2.08 et ultérieures. L’exemple suivant vous montre comment utiliser cet indicateur. ``` EXPLAIN SELECT /*+ JOIN_PREFIX (t4, t2) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); ``` **JOIN\$1SUFFIX** Spécifie les tables à mettre en dernier dans l’ordre de jointure. Il est utile pour les requêtes impliquant trois tables ou plus. Il est équivalent à l’indicateur MySQL [JOIN\$1SUFFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). Cet indicateur est disponible dans Aurora MySQL versions 2.08 et ultérieures. L’exemple suivant vous montre comment utiliser cet indicateur. ``` EXPLAIN SELECT /*+ JOIN_SUFFIX (t1) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); ``` Pour plus d’informations sur l’utilisation des requêtes de jointure de hachage, consultez [Optimisation des requêtes de jointure MySQL Aurora volumineuses avec des jointures de hachage](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.HashJoin). # Référence des procédures stockées Aurora MySQL Vous pouvez gérer votre cluster de bases de données Aurora MySQL en appelant des procédures stockées intégrées. **Topics** + [Collecte et maintenance de l’historique global des statuts](mysql-stored-proc-gsh.md) + [Configuration, démarrage et arrêt de la réplication des journaux binaires (binlog)](mysql-stored-proc-replicating.md) + [Mettre fin à une session ou à une requête](mysql-stored-proc-ending.md) + [Répliquer des transactions à l'aide de GTIDs](mysql-stored-proc-gtid.md) + [Rotation des journaux de requêtes](mysql-stored-proc-logging.md) + [Configuration et affichage de la configuration du journal binaire](mysql-stored-proc-configuring.md) # Collecte et maintenance de l’historique global des statuts Amazon RDS fournit un ensemble de procédures qui prennent des instantanés des valeurs des variables d’état au fil du temps et les écrivent dans une table, ainsi que toutes les modifications intervenues depuis le dernier instantané. Cette infrastructure porte le nom d’historique global des statuts. Pour plus d’informations, consultez [Gestion de l’historique global des statuts](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH). Les procédures stockées suivantes gèrent la manière dont l’historique global des statuts est collecté et conservé. **Topics** + [mysql.rds\$1collect\$1global\$1status\$1history](#mysql_rds_collect_global_status_history) + [mysql.rds\$1disable\$1gsh\$1collector](#mysql_rds_disable_gsh_collector) + [mysql.rds\$1disable\$1gsh\$1rotation](#mysql_rds_disable_gsh_rotation) + [mysql.rds\$1enable\$1gsh\$1collector](#mysql_rds_enable_gsh_collector) + [mysql.rds\$1enable\$1gsh\$1rotation](#mysql_rds_enable_gsh_rotation) + [mysql.rds\$1rotate\$1global\$1status\$1history](#mysql_rds_rotate_global_status_history) + [mysql.rds\$1set\$1gsh\$1collector](#mysql_rds_set_gsh_collector) + [mysql.rds\$1set\$1gsh\$1rotation](#mysql_rds_set_gsh_rotation) ## mysql.rds\$1collect\$1global\$1status\$1history Prend un instantané sur demande pour l’historique global des statuts. ### Syntaxe ``` CALL mysql.rds_collect_global_status_history; ``` ## mysql.rds\$1disable\$1gsh\$1collector Désactive les instantanés pris par l’historique global des statuts. ### Syntaxe ``` CALL mysql.rds_disable_gsh_collector; ``` ## mysql.rds\$1disable\$1gsh\$1rotation Désactive la rotation de la table `mysql.global_status_history`. ### Syntaxe ``` CALL mysql.rds_disable_gsh_rotation; ``` ## mysql.rds\$1enable\$1gsh\$1collector Active l’historique global des statuts pour prendre des instantanés par défaut aux intervalles spécifiés par `rds_set_gsh_collector`. ### Syntaxe ``` CALL mysql.rds_enable_gsh_collector; ``` ## mysql.rds\$1enable\$1gsh\$1rotation Active la rotation du contenu de la table `mysql.global_status_history` en `mysql.global_status_history_old` aux intervalles spécifiés par `rds_set_gsh_rotation`. ### Syntaxe ``` CALL mysql.rds_enable_gsh_rotation; ``` ## mysql.rds\$1rotate\$1global\$1status\$1history Effectue une rotation du contenu de la table `mysql.global_status_history` en `mysql.global_status_history_old` à la demande. ### Syntaxe ``` CALL mysql.rds_rotate_global_status_history; ``` ## mysql.rds\$1set\$1gsh\$1collector Spécifie l’intervalle, en minutes, entre les instantanés pris par l’historique global des statuts. ### Syntaxe ``` CALL mysql.rds_set_gsh_collector(intervalPeriod); ``` ### Paramètres *intervalPeriod* Intervalle, en minutes, entre les instantanés. La valeur par défaut est `5`. ## mysql.rds\$1set\$1gsh\$1rotation Spécifie l’intervalle, en jours, entre deux rotations de la table `mysql.global_status_history`. ### Syntaxe ``` CALL mysql.rds_set_gsh_rotation(intervalPeriod); ``` ### Paramètres *intervalPeriod* Intervalle, en jours, entre deux rotations de table. La valeur par défaut est `7`. # Configuration, démarrage et arrêt de la réplication des journaux binaires (binlog) Vous pouvez appeler les procédures stockées suivantes lorsque vous êtes connecté à l’instance principale dans un cluster Aurora MySQL. Ces procédures contrôlent la façon dont les transactions sont répliquées à partir d’une base de données externe dans Aurora MySQL, ou à partir de Aurora MySQL vers une base de données externe. **Topics** + [mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL version 2)](#mysql_rds_disable_session_binlog) + [mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL version 2)](#mysql_rds_enable_session_binlog) + [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) + [mysql.rds\$1next\$1master\$1log ( 2)](#mysql_rds_next_master_log) + [mysql.rds\$1next\$1source\$1log (Aurora MySQL version 3)](#mysql_rds_next_source_log) + [mysql.rds\$1remove\$1binlog\$1ssl\$1material](#mysql_rds_remove_binlog_ssl_material) + [mysql.rds\$1reset\$1external\$1master (Aurora MySQL version 2)](#mysql_rds_reset_external_master) + [mysql.rds\$1reset\$1external\$1source (Aurora MySQL version 3)](#mysql_rds_reset_external_source) + [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL version 3)](#mysql_rds_set_binlog_source_ssl) + [mysql.rds\$1set\$1external\$1master (Aurora MySQL version 2)](#mysql_rds_set_external_master) + [mysql.rds\$1set\$1external\$1source (Aurora MySQL version 3)](#mysql_rds_set_external_source) + [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL version 2)](#mysql_rds_set_external_master_with_auto_position) + [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL version 3)](#mysql_rds_set_external_source_with_auto_position) + [mysql.rds\$1set\$1master\$1auto\$1position 2)](#mysql_rds_set_master_auto_position) + [mysql.rds\$1set\$1read\$1only (Aurora MySQL version 3)](#mysql_rds_set_read_only) + [mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL version 2)](#mysql_rds_set_session_binlog_format) + [mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL version 3)](#mysql_rds_set_source_auto_position) + [mysql.rds\$1skip\$1repl\$1error](#mysql_rds_skip_repl_error) + [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) + [mysql.rds\$1start\$1replication\$1until (Aurora MySQL version 3)](#mysql_rds_start_replication_until) + [mysql.rds\$1stop\$1replication](#mysql_rds_stop_replication) ## mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL version 2) Désactive la journalisation binaire pour la session en cours en définissant la variable `sql_log_bin` sur `OFF`. ### Syntaxe ``` CALL mysql.rds_disable_session_binlog; ``` ### Parameters Aucune ### Notes d’utilisation Pour un cluster de bases de données Aurora MySQL, vous appelez cette procédure stockée lorsque vous êtes connecté à l’instance principale. Pour Aurora, cette procédure est prise en charge pour Aurora MySQL version 2.12 et les versions ultérieures, compatibles avec MySQL 5.7. **Note** Dans Aurora MySQL version 3, vous pouvez utiliser la commande suivante pour désactiver la journalisation binaire pour la session en cours si vous disposez du privilège `SESSION_VARIABLES_ADMIN` : ``` SET SESSION sql_log_bin = OFF; ``` ## mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL version 2) Active la journalisation binaire pour la session en cours en définissant la variable `sql_log_bin` sur `ON`. ### Syntaxe ``` CALL mysql.rds_enable_session_binlog; ``` ### Parameters Aucune ### Notes d’utilisation Pour un cluster de bases de données Aurora MySQL, vous appelez cette procédure stockée lorsque vous êtes connecté à l’instance principale. Pour Aurora, cette procédure est prise en charge pour Aurora MySQL version 2.12 et les versions ultérieures, compatibles avec MySQL 5.7. **Note** Dans Aurora MySQL version 3, vous pouvez utiliser la commande suivante pour activer la journalisation binaire pour la session en cours si vous disposez du privilège `SESSION_VARIABLES_ADMIN` : ``` SET SESSION sql_log_bin = ON; ``` ## mysql.rds\$1import\$1binlog\$1ssl\$1material Importe le certificat d’autorité de certification, le certificat client et la clé client dans un cluster de bases de données Aurora MySQL. Les informations sont requises pour la communication SSL et la réplication chiffrée. **Note** Actuellement, cette procédure est prise en charge pour Aurora MySQL version 2 : 2.09.2, 2.10.0, 2.10.1 et 2.11.0 ; et version 3 : 3.01.1 et versions ultérieures. ### Syntaxe ``` CALL mysql.rds_import_binlog_ssl_material ( ssl_material ); ``` ### Parameters *ssl\$1material* Données utiles JSON contenant le contenu des fichiers au format .pem suivants pour un client MySQL : + « ssl\$1ca » : » » *Certificate authority certificate* + « certificat SSL » : » » *Client certificate* + « clé\$1SSL » : » » *Client key* ### Notes d’utilisation Avant d’exécuter cette procédure, préparez-vous à la réplication chiffrée : + Si le protocole SSL n’est pas activé sur l’instance de base de données source MySQL externe et que vous ne disposez pas d’une clé client et d’un certificat client prêts, activez le protocole SSL sur le serveur de base de données MySQL et générez la clé client et le certificat client requis. + Si le protocole SSL est activé sur l’instance de base de données source externe, fournissez une clé et un certificat client pour le cluster de bases de données Aurora MySQL. En leur absence, générez une nouvelle clé et un nouveau certificat pour le cluster de bases de données Aurora MySQL. Pour signer le certificat client, vous devez disposer de la clé d’autorité de certification utilisée pour configurer le protocole SSL sur l’instance de base de données source MySQL externe. Pour plus d’informations, consultez [Création de certificats et clés SSL à l’aide d’openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) dans la documentation MySQL. **Important** Après vous être préparé à la réplication chiffrée, utilisez une connexion SSL pour exécuter cette procédure. La clé du client ne doit pas être transférée au moyen d’une connexion non sécurisée. Cette procédure permet d’importer des informations SSL entre une base de données MySQL externe et un cluster de bases de données Aurora MySQL. Les informations SSL se trouvent dans des fichiers au format .pem contenant les informations SSL du cluster de bases de données Aurora MySQL. Pendant la réplication chiffrée, le cluster de bases de données Aurora MySQL agit comme client du serveur de base de données MySQL. Les certificats et les clés privées du client Aurora MySQL sont au format .pem dans les fichiers. Vous pouvez copier les informations de ces fichiers dans le paramètre `ssl_material` des données utiles JSON correspondantes. Pour prendre en charge la réplication chiffrée, importez les informations SSL dans le cluster de bases de données Aurora MySQL. Les données utiles JSON doivent être au format suivant. ``` '{"ssl_ca":"-----BEGIN CERTIFICATE----- ssl_ca_pem_body_code -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE----- ssl_cert_pem_body_code -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY----- ssl_key_pem_body_code -----END RSA PRIVATE KEY-----\n"}' ``` ### Exemples L’exemple suivant importe des informations SSL dans Aurora MySQL. Dans les fichiers au format .pem, le code du corps est généralement plus long que le code du corps affiché dans l’exemple. ``` call mysql.rds_import_binlog_ssl_material( '{"ssl_ca":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END RSA PRIVATE KEY-----\n"}'); ``` ## mysql.rds\$1next\$1master\$1log ( 2) Modifie la position du journal de l’instance de base de données source au début du journal binaire suivant sur l’instance de base de données source. Utilisez cette procédure uniquement si vous recevez l' I/O erreur de réplication 1236 sur une réplique en lecture. ### Syntaxe ``` CALL mysql.rds_next_master_log( curr_master_log ); ``` ### Parameters *curr\$1master\$1log* Index du fichier journal maître actif. Par exemple, si le fichier en cours se nomme `mysql-bin-changelog.012345`, l’index est 12345. Pour déterminer le nom du fichier journal maître actif, exécutez la commande `SHOW REPLICA STATUS` et affichez le champ `Master_Log_File`. ### Notes d’utilisation L’utilisateur principal doit exécuter la procédure `mysql.rds_next_master_log`. **Avertissement** Appelez `mysql.rds_next_master_log` uniquement si la réplication échoue après le basculement d'une instance de base de données multi-AZ qui est la source de réplication et si le `Last_IO_Errno` champ de `SHOW REPLICA STATUS` signale l' I/O erreur 1236. L’appel de `mysql.rds_next_master_log` peut se traduire par une perte de données dans le réplica en lecture si les transactions de l’instance source n’ont pas été écrites dans le journal binaire sur disque avant que l’événement de basculement se produise. ### Exemples Supposons que la réplication échoue sur un réplica en lecture Aurora MySQL. L’exécution de `SHOW REPLICA STATUS\G` sur le réplica en lecture renvoie le résultat suivant : ``` *************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Source_SSL_Allowed: No Source_SSL_CA_File: Source_SSL_CA_Path: Source_SSL_Cert: Source_SSL_Cipher: Source_SSL_Key: Seconds_Behind_Master: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976 ``` Le champ `Last_IO_Errno` montre que l’instance reçoit une erreur 1236 d’I/O. Le champ `Master_Log_File` montre que le nom du fichier est `mysql-bin-changelog.012345`, ce qui signifie que l’index du fichier journal est `12345`. Pour résoudre l’erreur, vous pouvez appeler `mysql.rds_next_master_log` avec le paramètre suivant : ``` CALL mysql.rds_next_master_log(12345); ``` ## mysql.rds\$1next\$1source\$1log (Aurora MySQL version 3) Modifie la position du journal de l’instance de base de données source au début du journal binaire suivant sur l’instance de base de données source. Utilisez cette procédure uniquement si vous recevez l' I/O erreur de réplication 1236 sur une réplique en lecture. ### Syntaxe ``` CALL mysql.rds_next_source_log( curr_source_log ); ``` ### Parameters *curr\$1source\$1log* Index du fichier journal source actuel. Par exemple, si le fichier en cours se nomme `mysql-bin-changelog.012345`, l’index est 12345. Pour déterminer le nom du fichier journal actuel, exécutez la commande `SHOW REPLICA STATUS` et affichez le champ `Source_Log_File`. ### Notes d’utilisation L’utilisateur administratif doit exécuter la procédure `mysql.rds_next_source_log`. **Avertissement** Appelez `mysql.rds_next_source_log` uniquement si la réplication échoue après le basculement d'une instance de base de données multi-AZ qui est la source de réplication et si le `Last_IO_Errno` champ de `SHOW REPLICA STATUS` signale l' I/O erreur 1236. L’appel de `mysql.rds_next_source_log` peut se traduire par une perte de données dans le réplica en lecture si les transactions de l’instance source n’ont pas été écrites dans le journal binaire sur disque avant que l’événement de basculement se produise. Vous pouvez réduire la probabilité que cela se produise en définissant les paramètres d’instance source `sync_binlog` et `innodb_support_xa` sur `1`, même si cela peut compromettre les performances. ### Exemples Supposons que la réplication échoue sur un réplica en lecture Aurora MySQL. L’exécution de `SHOW REPLICA STATUS\G` sur le réplica en lecture renvoie le résultat suivant : ``` *************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Source_SSL_Allowed: No Source_SSL_CA_File: Source_SSL_CA_Path: Source_SSL_Cert: Source_SSL_Cipher: Source_SSL_Key: Seconds_Behind_Source: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976 ``` Le champ `Last_IO_Errno` montre que l’instance reçoit une erreur 1236 d’I/O. Le champ `Source_Log_File` montre que le nom du fichier est `mysql-bin-changelog.012345`, ce qui signifie que l’index du fichier journal est `12345`. Pour résoudre l’erreur, vous pouvez appeler `mysql.rds_next_source_log` avec le paramètre suivant : ``` CALL mysql.rds_next_source_log(12345); ``` ## mysql.rds\$1remove\$1binlog\$1ssl\$1material Supprime le certificat de l’autorité de certification, le certificat du client et la clé du client pour la communication SSL et la réplication chiffrée. Ces informations sont importées à l’aide de [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material). ### Syntaxe ``` CALL mysql.rds_remove_binlog_ssl_material; ``` ## mysql.rds\$1reset\$1external\$1master (Aurora MySQL version 2) Reconfigure une instance de base de données Aurora MySQL comme n’étant plus un réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS. **Important** Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). ### Syntaxe ``` CALL mysql.rds_reset_external_master; ``` ### Notes d’utilisation L’utilisateur principal doit exécuter la procédure `mysql.rds_reset_external_master`. Cette procédure doit être exécutée sur l’instance de base de données MySQL à supprimer comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS. **Note** Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Nous vous conseillons d’utiliser les réplicas Aurora pour gérer la réplication au sein d’un cluster de bases de données Aurora MySQL, dès que possible. Pour plus d’informations sur la gestion de la réplication dans des clusters de bases de données Aurora MySQL, consultez [Utilisation de réplicas Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas). Pour plus d’informations sur l’utilisation de la réplication pour importer des données à partir d’une instance de MySQL s’exécutant à l’extérieur d’Aurora MySQL, 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). ## mysql.rds\$1reset\$1external\$1source (Aurora MySQL version 3) Reconfigure une instance de base de données Aurora MySQL comme n’étant plus un réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS. **Important** Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). ### Syntaxe ``` CALL mysql.rds_reset_external_source; ``` ### Notes d’utilisation L’utilisateur administratif doit exécuter la procédure `mysql.rds_reset_external_source`. Cette procédure doit être exécutée sur l’instance de base de données MySQL à supprimer comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS. **Note** Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Nous vous conseillons d’utiliser les réplicas Aurora pour gérer la réplication au sein d’un cluster de bases de données Aurora MySQL, dès que possible. Pour plus d’informations sur la gestion de la réplication dans des clusters de bases de données Aurora MySQL, consultez [Utilisation de réplicas Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas). ## mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL version 3) Active le chiffrement `SOURCE_SSL` pour la réplication des journaux binaires. Pour plus d’informations, consultez [Instruction CHANGE REPLICATION SOURCE TO](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) dans la documentation MySQL. ### Syntaxe ``` CALL mysql.rds_set_binlog_source_ssl(mode); ``` ### Parameters *mode* Valeur qui indique si le chiffrement `SOURCE_SSL` est activé : + `0` : le chiffrement `SOURCE_SSL` est désactivé. La valeur par défaut est `0`. + `1` : le chiffrement `SOURCE_SSL` est activé. Vous pouvez configurer le chiffrement à l’aide du protocole SSL ou TLS. ### Notes d’utilisation Cette procédure est prise en charge pour les versions 3.06 et supérieures d'Aurora MySQL. ## mysql.rds\$1set\$1external\$1master (Aurora MySQL version 2) Configure une instance de base de données Aurora MySQL comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS. La procédure `mysql.rds_set_external_master` est obsolète et sera supprimée dans une version future. Utilisez `mysql.rds\$1set\$1external\$1source` à la place. **Important** Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). ### Syntaxe ``` CALL mysql.rds_set_external_master ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` ### Parameters *host\$1name* Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS pour devenir l’instance de base de données source. *host\$1port* Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS et à configurer comme instance de base de données source. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH. *replication\$1user\$1name* ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe. *replication\$1user\$1password* Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* Nom du journal binaire sur l’instance de base de données source qui contient les informations de réplication. *mysql\$1binary\$1log\$1file\$1location* Emplacement dans le journal binaire `mysql_binary_log_file_name` à partir duquel la réplication commence à lire les informations de réplication. Vous pouvez déterminer le nom et l’emplacement du fichier journal binaire en exécutant `SHOW MASTER STATUS` sur l’instance de base de données source. *ssl\$1encryption* Valeur indiquant si le chiffrement Secure Socket Layer (SSL) est utilisé sur la connexion de réplication. La valeur 1 spécifie d’utiliser le chiffrement SSL, et la valeur 0 de ne pas l’utiliser. La valeur par défaut est 0. L’option `MASTER_SSL_VERIFY_SERVER_CERT` n’est pas prise en charge. Cette option est définie sur 0, ce qui signifie que la connexion est chiffrée, mais que les certificats ne sont pas vérifiés. ### Notes d’utilisation L’utilisateur principal doit exécuter la procédure `mysql.rds_set_external_master`. Cette procédure doit être exécutée sur l’instance de base de données MySQL qui doit être configurée comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS. Avant d’exécuter `mysql.rds_set_external_master`, vous devez configurer l’instance de MySQL s’exécutant en dehors de Amazon RDS comme instance de base de données source. Pour vous connecter à l’instance MySQL en cours d’exécution en dehors de Amazon RDS, vous devez spécifier des valeurs `replication_user_name` et `replication_user_password` qui indiquent un utilisateur de réplication possédant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance externe de MySQL. **Pour configurer une instance externe de MySQL en tant qu’instance de base de données source** 1. A l’aide du client MySQL de votre choix, connectez-vous à l’instance externe de MySQL et créez un compte d’utilisateur à utiliser pour la réplication. Voici un exemple. **MySQL 5.7** ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **MySQL 8.0** ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password'; ``` **Note** Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité. 1. Sur l’instance externe de MySQL, accordez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur « repl\$1user » de votre domaine. **MySQL 5.7** ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **MySQL 8.0** ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` Pour utiliser la réplication chiffrée, configurez l’instance de base de données source de façon à utiliser les connexions SSL. De même, importez le certificat de l’autorité de certification, le certificat du client et la clé du client dans l’instance de base de données ou le cluster de bases de données à l’aide de la procédure [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material). **Note** Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Nous vous conseillons d’utiliser les réplicas Aurora pour gérer la réplication au sein d’un cluster de bases de données Aurora MySQL, dès que possible. Pour plus d’informations sur la gestion de la réplication dans des clusters de bases de données Aurora MySQL, consultez [Utilisation de réplicas Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas). Après avoir appelé `mysql.rds_set_external_master` pour configurer une instance de base de données Amazon RDS comme réplica en lecture, vous pouvez appeler [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) sur le réplica en lecture pour démarrer le processus de réplication. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1master (Aurora MySQL version 2)](#mysql_rds_reset_external_master) pour supprimer la configuration du réplica en lecture. Quand la procédure `mysql.rds_set_external_master` est appelée, Amazon RDS enregistre l’heure, l’utilisateur et une action de `set master` dans les tables `mysql.rds_history` et `mysql.rds_replication_status`. ### Exemples Lors d’une exécution sur une instance de base de données MySQL, l’exemple suivant configure l’instance de base de données comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS. ``` call mysql.rds_set_external_master( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 1); ``` ## mysql.rds\$1set\$1external\$1source (Aurora MySQL version 3) Configure une instance de base de données Aurora MySQL comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS. **Important** Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). ### Syntaxe ``` CALL mysql.rds_set_external_source ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` ### Parameters *host\$1name* Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS pour devenir l’instance de base de données source. *host\$1port* Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS et à configurer comme instance de base de données source. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH. *replication\$1user\$1name* ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe. *replication\$1user\$1password* Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* Nom du journal binaire sur l’instance de base de données source qui contient les informations de réplication. *mysql\$1binary\$1log\$1file\$1location* Emplacement dans le journal binaire `mysql_binary_log_file_name` à partir duquel la réplication commence à lire les informations de réplication. Vous pouvez déterminer le nom et l’emplacement du fichier journal binaire en exécutant `SHOW MASTER STATUS` sur l’instance de base de données source. *ssl\$1encryption* Valeur indiquant si le chiffrement Secure Socket Layer (SSL) est utilisé sur la connexion de réplication. La valeur 1 spécifie d’utiliser le chiffrement SSL, et la valeur 0 de ne pas l’utiliser. La valeur par défaut est 0. Vous devez avoir importé un certificat SSL personnalisé [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) pour activer cette option. Si vous n’avez pas importé de certificat SSL personnalisé, définissez ce paramètre sur 0 et utilisez [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL version 3)](#mysql_rds_set_binlog_source_ssl) pour activer le protocole SSL pour la réplication des journaux binaires. L’option `SOURCE_SSL_VERIFY_SERVER_CERT` n’est pas prise en charge. Cette option est définie sur 0, ce qui signifie que la connexion est chiffrée, mais que les certificats ne sont pas vérifiés. ### Notes d’utilisation L’utilisateur administratif doit exécuter la procédure `mysql.rds_set_external_source`. Cette procédure doit être exécutée sur l’instance de base de données Aurora MySQL qui doit être configurée comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS. Avant d’exécuter `mysql.rds_set_external_source`, vous devez configurer l’instance de MySQL s’exécutant en dehors de Amazon RDS comme instance de base de données source. Pour vous connecter à l’instance MySQL en cours d’exécution en dehors de Amazon RDS, vous devez spécifier des valeurs `replication_user_name` et `replication_user_password` qui indiquent un utilisateur de réplication possédant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance externe de MySQL. **Pour configurer une instance externe de MySQL en tant qu’instance de base de données source** 1. A l’aide du client MySQL de votre choix, connectez-vous à l’instance externe de MySQL et créez un compte d’utilisateur à utiliser pour la réplication. Voici un exemple. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **Note** Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité. 1. Sur l’instance externe de MySQL, accordez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur « repl\$1user » de votre domaine. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` Pour utiliser la réplication chiffrée, configurez l’instance de base de données source de façon à utiliser les connexions SSL. De plus, importez le certificat de l’autorité de certification, le certificat du client et la clé du client dans l’instance de base de données ou le cluster de bases de données à l’aide de la procédure [mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html). **Note** Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Nous vous conseillons d’utiliser les réplicas Aurora pour gérer la réplication au sein d’un cluster de bases de données Aurora MySQL, dès que possible. Pour plus d’informations sur la gestion de la réplication dans des clusters de bases de données Aurora MySQL, consultez [Utilisation de réplicas Aurora](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas). Après avoir appelé `mysql.rds_set_external_source` pour configurer une instance de base de données Aurora MySQL comme réplica en lecture, vous pouvez appeler [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) sur le réplica en lecture pour démarrer le processus de réplication. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1source (Aurora MySQL version 3)](#mysql_rds_reset_external_source) pour supprimer la configuration du réplica en lecture. Quand la procédure `mysql.rds_set_external_source` est appelée, Amazon RDS enregistre l’heure, l’utilisateur et une action de `set master` dans les tables `mysql.rds_history` et `mysql.rds_replication_status`. ### Exemples Lors d’une exécution sur une instance de base de données Aurora MySQL, l’exemple suivant configure l’instance de base de données comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS. ``` call mysql.rds_set_external_source( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 1); ``` ## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL version 2) Configure une instance principale Aurora MySQL afin d’accepter la réplication entrante à partir d’une instance MySQL externe. Cette procédure configure également la réplication en fonction des identifiants de transaction globaux ()GTIDs. Cette procédure ne configure pas la réplication retardée, car Aurora MySQL ne prend pas en charge la réplication retardée. ### Syntaxe ``` CALL mysql.rds_set_external_master_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption ); ``` ### Parameters *host\$1name* Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Aurora pour devenir la source de réplication. *host\$1port* Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Aurora et à configurer comme source de réplication. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH. *replication\$1user\$1name* ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Aurora. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe. *replication\$1user\$1password* Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`. *ssl\$1encryption* Cette option n’est pas actuellement implémentée. La valeur par défaut est 0. ### Notes d’utilisation Pour un cluster de bases de données Aurora MySQL, vous appelez cette procédure stockée lorsque vous êtes connecté à l’instance principale. L'utilisateur principal doit exécuter la procédure `mysql.rds_set_external_master_with_auto_position`. L’utilisateur principal exécute cette procédure sur l’instance principale d’un cluster de bases de données Aurora MySQL qui agit en tant que cible de réplication. Il peut s’agir de la cible de réplication d’une instance de base de données MySQL externe ou d’un cluster de bases de données Aurora MySQL. Cette procédure est prise en charge pour Aurora MySQL version 2. Pour Aurora MySQL version 3, utilisez la procédure [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL version 3)](#mysql_rds_set_external_source_with_auto_position). Avant d’exécuter `mysql.rds_set_external_master_with_auto_position`, configurez l’instance de base de données MySQL comme source de réplication. Pour vous connecter à l’instance MySQL externe, spécifiez des valeurs pour `replication_user_name` et `replication_user_password`. Ces valeurs doivent indiquer un utilisateur de réplication disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL externe. **Pour configurer une instance MySQL externe comme source de réplication** 1. À l’aide du client MySQL de votre choix, connectez-vous à l’instance MySQL externe et créez un compte utilisateur à utiliser pour la réplication. Voici un exemple de. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Sur l’instance MySQL externe, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur `'repl_user'` de votre domaine. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Lorsque vous appelez `mysql.rds_set_external_master_with_auto_position`, Amazon RDS enregistre certaines informations. Il s’agit de l’heure, de l’utilisateur et d’une action de `"set master"` dans les tables `mysql.rds_history` et `mysql.rds_replication_status`. Pour ignorer une transaction basée sur des identifiants de transaction globaux spécifique qui est réputée entraîner un problème, vous pouvez utiliser la procédure stockée [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versions 2 et 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Pour plus d’informations sur la gestion d’une réplication basée sur des identifiants de transaction globaux, consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md). ### Exemples Lorsqu’il est exécuté sur une instance principale Aurora, l’exemple suivant configure le cluster Aurora pour qu’il agisse comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Aurora. ``` call mysql.rds_set_external_master_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'SomePassW0rd'); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL version 3) Configure une instance principale Aurora MySQL afin d’accepter la réplication entrante à partir d’une instance MySQL externe. Cette procédure configure également la réplication en fonction des identifiants de transaction globaux ()GTIDs. ### Syntaxe ``` CALL mysql.rds_set_external_source_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption ); ``` ### Parameters *host\$1name* Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Aurora pour devenir la source de réplication. *host\$1port* Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Aurora et à configurer comme source de réplication. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH. *replication\$1user\$1name* ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Aurora. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe. *replication\$1user\$1password* Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`. *ssl\$1encryption* Cette option n’est pas actuellement implémentée. La valeur par défaut est 0. Utilisez [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL version 3)](#mysql_rds_set_binlog_source_ssl) pour activer SSL pour la réplication des journaux binaires. ### Notes d’utilisation Pour un cluster de bases de données Aurora MySQL, vous appelez cette procédure stockée lorsque vous êtes connecté à l’instance principale. L’utilisateur administratif doit exécuter la procédure `mysql.rds_set_external_source_with_auto_position`. L’utilisateur administratif exécute cette procédure sur l’instance principale d’un cluster de bases de données Aurora MySQL qui agit en tant que cible de réplication. Il peut s’agir de la cible de réplication d’une instance de base de données MySQL externe ou d’un cluster de bases de données Aurora MySQL. Cette procédure est prise en charge pour Aurora MySQL version 3. Cette procédure ne configure pas la réplication retardée, car Aurora MySQL ne prend pas en charge la réplication retardée. Avant d’exécuter `mysql.rds_set_external_source_with_auto_position`, configurez l’instance de base de données MySQL comme source de réplication. Pour vous connecter à l’instance MySQL externe, spécifiez des valeurs pour `replication_user_name` et `replication_user_password`. Ces valeurs doivent indiquer un utilisateur de réplication disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL externe. **Pour configurer une instance MySQL externe comme source de réplication** 1. À l’aide du client MySQL de votre choix, connectez-vous à l’instance MySQL externe et créez un compte utilisateur à utiliser pour la réplication. Voici un exemple de. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Sur l’instance MySQL externe, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur `'repl_user'` de votre domaine. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Lorsque vous appelez `mysql.rds_set_external_source_with_auto_position`, Amazon RDS enregistre certaines informations. Il s’agit de l’heure, de l’utilisateur et d’une action de `"set master"` dans les tables `mysql.rds_history` et `mysql.rds_replication_status`. Pour ignorer une transaction basée sur des identifiants de transaction globaux spécifique qui est réputée entraîner un problème, vous pouvez utiliser la procédure stockée [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versions 2 et 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Pour plus d’informations sur la gestion d’une réplication basée sur des identifiants de transaction globaux, consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md). ### Exemples Lorsqu’il est exécuté sur une instance principale Aurora, l’exemple suivant configure le cluster Aurora pour qu’il agisse comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Aurora. ``` call mysql.rds_set_external_source_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'SomePassW0rd'); ``` ## mysql.rds\$1set\$1master\$1auto\$1position 2) Définit le mode de réplication en fonction des positions du fichier journal binaire ou des identificateurs de transaction globaux (GTIDs). ### Syntaxe ``` CALL mysql.rds_set_master_auto_position ( auto_position_mode ); ``` ### Parameters *auto\$1position\$1mode* Valeur qui indique si la réplication à utiliser est la réplication basée sur la position de fichier ou la réplication basée sur les identifiants de transaction globaux : + `0` : utiliser la méthode de réplication basée sur la position du fichier journal binaire. La valeur par défaut est `0`. + `1` : utiliser la méthode de réplication basée sur les identifiants de transaction globaux. ### Notes d’utilisation L’utilisateur principal doit exécuter la procédure `mysql.rds_set_master_auto_position`. Cette procédure est prise en charge pour Aurora MySQL version 2. ## mysql.rds\$1set\$1read\$1only (Aurora MySQL version 3) Active ou désactive le mode `read_only` de manière globale pour l’instance de base de données. ### Syntaxe ``` CALL mysql.rds_set_read_only(mode); ``` ### Parameters *mode* Une valeur qui indique si le mode `read_only` est activé ou désactivé globalement pour l’instance de base de données : + `0` : `OFF`. La valeur par défaut est `0`. + `1` – `ON` ### Notes d’utilisation La procédure `mysql.rds_set_read_only` stockée modifie uniquement le paramètre `read_only`. Le paramètre `innodb_read_only` ne peut pas être modifié sur les instances de base de données du lecteur. Le changement du paramètre `read_only` ne persiste pas au redémarrage. Pour apporter des modifications permanentes à `read_only`, vous devez utiliser le paramètre `read_only` du cluster de bases de données. Cette procédure est prise en charge pour les versions 3.06 et supérieures d'Aurora MySQL. ## mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL version 2) Définit le format de journal binaire pour la session en cours. ### Syntaxe ``` CALL mysql.rds_set_session_binlog_format(format); ``` ### Parameters *format* Valeur qui indique le format de journal binaire pour la session en cours : + `STATEMENT` : la source de réplication écrit les événements dans le journal binaire sur la base d’instructions SQL. + `ROW` : la source de réplication écrit les événements dans le journal binaire qui indiquent les modifications apportées aux lignes individuelles des tables. + `MIXED` : la journalisation est généralement basée sur des instructions SQL, mais passe aux lignes sous certaines conditions. Pour plus d’informations, consultez [Format mixte de journalisation binaire](https://dev.mysql.com/doc/refman/8.0/en/binary-log-mixed.html) (langue française non garantie) dans la documentation MySQL. ### Notes d’utilisation Pour un cluster de bases de données Aurora MySQL, vous appelez cette procédure stockée lorsque vous êtes connecté à l’instance principale. Pour utiliser cette procédure stockée, la journalisation binaire doit être configurée pour la session en cours. Pour Aurora, cette procédure est prise en charge pour Aurora MySQL version 2.12 et les versions ultérieures, compatibles avec MySQL 5.7. ## mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL version 3) Définit le mode de réplication en fonction des positions du fichier journal binaire ou des identificateurs de transaction globaux (GTIDs). ### Syntaxe ``` CALL mysql.rds_set_source_auto_position (auto_position_mode); ``` ### Parameters *auto\$1position\$1mode* Valeur qui indique si la réplication à utiliser est la réplication basée sur la position de fichier ou la réplication basée sur les identifiants de transaction globaux : + `0` : utiliser la méthode de réplication basée sur la position du fichier journal binaire. La valeur par défaut est `0`. + `1` : utiliser la méthode de réplication basée sur les identifiants de transaction globaux. ### Notes d’utilisation Pour un cluster de bases de données Aurora MySQL, vous appelez cette procédure stockée lorsque vous êtes connecté à l’instance principale. L’utilisateur administratif doit exécuter la procédure `mysql.rds_set_source_auto_position`. ## mysql.rds\$1skip\$1repl\$1error Ignore et supprime une erreur de réplication sur un réplica en lecture d’une base de données MySQL. ### Syntaxe ``` CALL mysql.rds_skip_repl_error; ``` ### Notes d’utilisation L’utilisateur principal doit exécuter la procédure `mysql.rds_skip_repl_error` sur un réplica en lecture. Pour plus d’informations sur cette procédure, consultez [Ignorer une erreur de réplication](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.SkipError). Pour déterminer s’il y a des erreurs, exécutez la commande MySQL `SHOW REPLICA STATUS\G`. Si une erreur de réplication n’est pas critique, vous pouvez exécuter `mysql.rds_skip_repl_error` pour ignorer l’erreur. S’il y a plusieurs erreurs, `mysql.rds_skip_repl_error` supprime la première erreur, puis avertit qu’il y a d’autres erreurs. Vous pouvez alors utiliser `SHOW REPLICA STATUS\G` pour déterminer l’action appropriée pour l’erreur suivante. Pour obtenir des informations sur les valeurs renvoyées, consultez [Instruction SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) dans la documentation sur MySQL. Pour plus d’informations sur le traitement des erreurs de réplication avec Aurora MySQL, consultez [Diagnostic et résolution d'un échec de réplication en lecture MySQL ](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.RR). #### Erreur d’arrêt de réplication Lorsque vous appelez la procédure `mysql.rds_skip_repl_error`, un message d’erreur peut s’afficher pour indiquer que le réplica a rencontré une erreur ou est désactivé. Ce message d’erreur s’affiche si vous exécutez la procédure sur l’instance principale plutôt que sur le réplica en lecture. Vous devez exécuter cette procédure sur le réplica en lecture pour que la procédure fonctionne. Ce message d’erreur peut également s’afficher si vous exécutez la procédure sur le réplica en lecture, mais que la réplication ne peut pas être redémarrée correctement. Si vous avez besoin d’ignorer un grand nombre d’erreurs, le retard de réplication peut augmenter et dépasser la période de rétention par défaut pour les fichiers journaux binaires (binlog). Dans ce cas, vous pouvez rencontrer une erreur irrécupérable due à des fichiers journaux binaires purgés avant d’avoir été réutilisés sur le réplica en lecture. Cette purge entraîne l'arrêt de la réplication et vous ne pouvez plus appeler la commande `mysql.rds_skip_repl_error` pour ignorer les erreurs de réplication. Vous pouvez atténuer ce problème en augmentant le nombre d’heures pendant lequel les fichiers journaux binaires sont conservés sur votre instance de base de données source. Une fois que vous avez augmenté le temps de rétention de journaux binaires, vous pouvez redémarrer la réplication et appeler la commande `mysql.rds_skip_repl_error` en fonction des besoins. Pour définir la période de rétention des journaux binaires, utilisez la procédure [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) et spécifiez un paramètre de configuration `'binlog retention hours'`, ainsi que le nombre d’heures pendant lequel conserver les fichiers journaux binaires sur le cluster de bases de données. L’exemple suivant définit la période de rétention des fichiers journaux binaires à 48 heures. ``` CALL mysql.rds_set_configuration('binlog retention hours', 48); ``` ## mysql.rds\$1start\$1replication Lance la réplication à partir d’un cluster de bases de données Aurora MySQL. **Note** Vous pouvez utiliser la procédure stockée [mysql.rds\$1start\$1replication\$1until (Aurora MySQL version 3)](#mysql_rds_start_replication_until) ou [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL version 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) pour lancer la réplication à partir d’une instance de base de données Aurora MySQL et arrêter la réplication à la position spécifiée dans le fichier journal binaire. ### Syntaxe ``` CALL mysql.rds_start_replication; ``` ### Notes d’utilisation L’utilisateur principal doit exécuter la procédure `mysql.rds_start_replication`. Pour importer des données à partir d’une instance de MySQL externe à Amazon RDS, appelez `mysql.rds_start_replication` sur le réplica en lecture pour démarrer le processus de réplication après avoir appelé [mysql.rds\$1set\$1external\$1master (Aurora MySQL version 2)](#mysql_rds_set_external_master)ou [mysql.rds\$1set\$1external\$1source (Aurora MySQL version 3)](#mysql_rds_set_external_source) pour créer la configuration de réplication. Pour plus d’informations, 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). Pour exporter des données vers une instance de MySQL extérieure à Amazon RDS, appelez `mysql.rds_start_replication` et `mysql.rds_stop_replication` sur le réplica en lecture pour contrôler certaines actions de réplication, telles que la purge des journaux binaires. Pour plus d’informations, 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). Vous pouvez aussi appeler `mysql.rds_start_replication` sur le réplica en lecture pour redémarrer un processus de réplication que vous avez précédemment arrêté en appelant `mysql.rds_stop_replication`. Pour de plus amples informations, veuillez consulter [Erreur d’arrêt de réplication](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicationStopped). ## mysql.rds\$1start\$1replication\$1until (Aurora MySQL version 3) Lance la réplication à partir d’un cluster de bases de données Aurora MySQL et arrête la réplication à la position spécifiée dans le fichier journal binaire. ### Syntaxe ``` CALL mysql.rds_start_replication_until ( replication_log_file , replication_stop_point ); ``` ### Parameters *replication\$1log\$1file* Nom du journal binaire sur l’instance de base de données source qui contient les informations de réplication. *replication\$1stop\$1point * Position dans le journal binaire `replication_log_file` à laquelle la réplication s’arrêtera. ### Notes d’utilisation L’utilisateur principal doit exécuter la procédure `mysql.rds_start_replication_until`. Cette procédure est prise en charge pour Aurora MySQL versions 3.04 et ultérieures. La procédure `mysql.rds_start_replication_until` stockée n’est pas prise en charge pour la réplication gérée, qui inclut les éléments suivants : + [Réplication de clusters de bases de données Amazon Aurora MySQL dans différentes Régions AWS](AuroraMySQL.Replication.CrossRegion.md) + [Migration des données d’une instance de base de données RDS for MySQL vers un cluster de bases de données Amazon Aurora MySQL à l’aide d’un réplica en lecture Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md) Le nom de fichier spécifié pour le paramètre `replication_log_file` doit correspondre au nom du fichier binlog de l’instance de base de données source. Lorsque le paramètre `replication_stop_point` spécifie une position d’arrêt survenant dans le passé, la réplication est arrêtée immédiatement. ### Exemples L’exemple suivant lance la réplication et réplique les modifications jusqu’à ce qu’il atteigne la position `120` dans le fichier journal binaire `mysql-bin-changelog.000777`. ``` call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120); ``` ## mysql.rds\$1stop\$1replication Arrête la réplication à partir d’une instance de base de données MySQL. ### Syntaxe ``` CALL mysql.rds_stop_replication; ``` ### Notes d’utilisation L’utilisateur principal doit exécuter la procédure `mysql.rds_stop_replication`. Si vous configurez la réplication pour importer des données à partir d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS, vous appelez `mysql.rds_stop_replication` sur le réplica en lecture pour arrêter le processus de réplication après que l’importation soit terminée. Pour plus d’informations, 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). Si vous configurez la réplication pour exporter les données vers une instance de MySQL extérieure à Amazon RDS, vous appelez `mysql.rds_start_replication` et `mysql.rds_stop_replication` sur le réplica en lecture pour contrôler certaines actions de réplication, telles que la purge des journaux binaires. Pour plus d’informations, 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). La procédure `mysql.rds_stop_replication` stockée n’est pas prise en charge pour la réplication gérée, qui inclut les éléments suivants : + [Réplication de clusters de bases de données Amazon Aurora MySQL dans différentes Régions AWS](AuroraMySQL.Replication.CrossRegion.md) + [Migration des données d’une instance de base de données RDS for MySQL vers un cluster de bases de données Amazon Aurora MySQL à l’aide d’un réplica en lecture Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md) # Mettre fin à une session ou à une requête Les procédures stockées suivantes mettent fin à une session ou à une requête. **Topics** + [mysql.rds\$1kill](#mysql_rds_kill) + [mysql.rds\$1kill\$1query](#mysql_rds_kill_query) ## mysql.rds\$1kill Termine une connexion au serveur MySQL. ### Syntaxe ``` CALL mysql.rds_kill(processID); ``` ### Paramètres *processID* Identité du thread de connexion à terminer. ### Notes d'utilisation Chaque connexion au serveur MySQL s'exécute dans un thread distinct. Pour terminer une connexion, utilisez la procédure `mysql.rds_kill` et transmettez-lui l'ID de thread de cette connexion. Pour obtenir l'ID de thread, utilisez la commande MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html). ### Exemples L'exemple suivant termine une connexion avec l'ID de thread 4243 : ``` CALL mysql.rds_kill(4243); ``` ## mysql.rds\$1kill\$1query Termine une requête s'exécutant sur le serveur MySQL. ### Syntaxe ``` CALL mysql.rds_kill_query(processID); ``` ### Paramètres *processID* Identité du processus ou du thread qui exécute la requête à terminer. ### Notes d’utilisation Pour arrêter une requête en cours d'exécution sur le serveur MySQL, utilisez la procédure `mysql_rds_kill_query` et transmettez l'ID de connexion du thread qui exécute la requête. La procédure met alors fin à la connexion. Pour obtenir l'ID, interrogez la table MySQL [INFORMATION\$1SCHEMA PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html) ou utilisez la commande MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html). La valeur figurant dans la colonne ID de `SHOW PROCESSLIST` ou `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` est le *processID*. ### Exemples L'exemple suivant arrête une requête dont l'ID de thread de requête est 230040 : ``` CALL mysql.rds_kill_query(230040); ``` # Répliquer des transactions à l'aide de GTIDs Les procédures stockées suivantes contrôlent la manière dont les transactions sont répliquées à l'aide des identificateurs de transaction globaux (GTIDs) avec Aurora MySQL. Pour savoir comment utiliser la réplication basée sur GTIDs Aurora MySQL, consultez[Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md). **Topics** + [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL version 3)](#mysql_assign_gtids_to_anonymous_transactions) + [mysql.rds\$1gtid\$1purged (Aurora MySQL version 3)](#mysql_rds_gtid_purged) + [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versions 2 et 3)](#mysql_rds_skip_transaction_with_gtid) + [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL version 3)](#mysql_rds_start_replication_until_gtid) ## mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL version 3) Configure l’option `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS` de l’instruction `CHANGE REPLICATION SOURCE TO`. Elle force le canal de réplication à attribuer un GTID à des transactions répliquées qui n’en possèdent pas. Vous pouvez ainsi effectuer une réplication de journaux binaires à partir d’une source qui n’utilise pas la réplication GTID vers un réplica qui l’utilise. Pour plus d'informations, consultez les sections [CHANGE REPLICATION SOURCE TO Statement](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html) et [Replication From a Source Without GTIDs to a Replica With GTIDs](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon.html) dans le *manuel de référence MySQL*. ### Syntaxe ``` CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option); ``` ### Parameters *gtid\$1option* Valeur de chaîne. Les valeurs autorisées sont : `OFF`, `LOCAL` ou un UUID spécifié. ### Notes d’utilisation Cette procédure a le même effet que l’émission de l’instruction `CHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option` dans Community MySQL. Le GTID doit être converti en UUID `ON` *gtid\$1option* pour être défini sur un `LOCAL` UUID spécifique. La valeur par défaut est `OFF`, ce qui signifie que la fonctionnalité n’est pas utilisée. `LOCAL` attribue un GTID incluant le propre UUID du réplica (paramètre `server_uuid`). La transmission d’un paramètre correspondant à un UUID attribue un GTID qui inclut l’UUID spécifié, tel que le paramètre `server_uuid` pour le serveur source de réplication. ### Exemples Pour désactiver cette fonction : ``` mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('OFF'); +-------------------------------------------------------------+ | Message | +-------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: OFF | +-------------------------------------------------------------+ 1 row in set (0.07 sec) ``` Pour utiliser l’UUID du réplica : ``` mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('LOCAL'); +---------------------------------------------------------------+ | Message | +---------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: LOCAL | +---------------------------------------------------------------+ 1 row in set (0.07 sec) ``` Pour utiliser un UUID spécifié : ``` mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('317a4760-f3dd-3b74-8e45-0615ed29de0e'); +----------------------------------------------------------------------------------------------+ | Message | +----------------------------------------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: 317a4760-f3dd-3b74-8e45-0615ed29de0e | +----------------------------------------------------------------------------------------------+ 1 row in set (0.07 sec) ``` ## mysql.rds\$1gtid\$1purged (Aurora MySQL version 3) Définit la valeur globale de la variable système `gtid_purged` sur un ensemble d’identifiants de transaction globaux (GTID) donné. La variable `gtid_purged` système est un ensemble GTID qui comprend toutes les transactions qui ont été validées sur le serveur, mais qui n'existent dans aucun fichier journal binaire du serveur. GTIDs Pour permettre la compatibilité avec MySQL 8.0, il existe deux manières de définir la valeur de `gtid_purged` : + Remplacez la valeur de `gtid_purged` par l’ensemble d’identifiants GTID que vous avez spécifié. + Ajoutez l’ensemble GTID que vous avez spécifié à l’ensemble d’identifiants GTID que `gtid_purged` contient déjà. ### Syntaxe Pour remplacer la valeur de `gtid_purged` par l’ensemble d’identifiants GTID que vous avez spécifié : ``` CALL mysql.rds_gtid_purged (gtid_set); ``` Pour ajouter la valeur de `gtid_purged` à votre ensemble d’identifiants GTID que vous avez spécifié : ``` CALL mysql.rds_gtid_purged (+gtid_set); ``` ### Parameters *gtid\$1set* La valeur de *gtid\$1set* doit être un sur-ensemble de la valeur actuelle de`gtid_purged`, et ne peut pas se croiser avec. `gtid_subtract(gtid_executed,gtid_purged)` En d'autres termes, le nouvel ensemble de GTID doit inclure ceux GTIDs qui y figuraient déjà`gtid_purged`, et ne peut pas inclure ceux `gtid_executed` qui n'ont pas encore été purgés. GTIDs Le *gtid\$1set* paramètre ne peut pas non plus inclure GTIDs celles figurant dans l'`gtid_owned`ensemble global, GTIDs pour les transactions en cours de traitement sur le serveur. ### Notes d’utilisation L’utilisateur principal doit exécuter la procédure `mysql.rds_gtid_purged`. Cette procédure est prise en charge pour Aurora MySQL versions 3.04 et ultérieures. ### Exemples L’exemple suivant attribue le GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` à la variable globale `gtid_purged`. ``` CALL mysql.rds_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` ## mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL versions 2 et 3) Ignore la réplication d’une transaction avec l’identifiant de transaction global (GTID) spécifié sur une instance principale Aurora. Vous pouvez utiliser cette procédure pour la reprise après sinistre lorsqu’il est avéré qu’une transaction GTID entraîne des problèmes. Utilisez cette procédure stockée pour ignorer la transaction problématique. Les transactions problématiques sont par exemple celles qui désactivent la réplication, suppriment des données importantes ou entraînent l’indisponibilité de l’instance de base de données. ### Syntaxe ``` CALL mysql.rds_skip_transaction_with_gtid ( gtid_to_skip ); ``` ### Parameters *gtid\$1to\$1skip* GTID de la transaction de réplication à ignorer. ### Notes d’utilisation L’utilisateur principal doit exécuter la procédure `mysql.rds_skip_transaction_with_gtid`. Cette procédure est prise en charge pour Aurora MySQL versions 2 et 3. ### Exemples L’exemple suivant ignore la réplication de la transaction avec le GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` ## mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL version 3) Lance la réplication à partir d’un cluster de bases de données Aurora MySQL et arrête la réplication immédiatement après l’identifiant de transaction global (GTID) spécifié. ### Syntaxe ``` CALL mysql.rds_start_replication_until_gtid(gtid); ``` ### Parameters *gtid* Identifiant de transaction global (GTID) après lequel la réplication s’arrête. ### Notes d’utilisation L’utilisateur principal doit exécuter la procédure `mysql.rds_start_replication_until_gtid`. Cette procédure est prise en charge pour Aurora MySQL versions 3.04 et ultérieures. La procédure `mysql.rds_start_replication_until_gtid` stockée n’est pas prise en charge pour la réplication gérée, qui inclut les éléments suivants : + [Réplication de clusters de bases de données Amazon Aurora MySQL dans différentes Régions AWS](AuroraMySQL.Replication.CrossRegion.md) + [Migration des données d’une instance de base de données RDS for MySQL vers un cluster de bases de données Amazon Aurora MySQL à l’aide d’un réplica en lecture Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md) Lorsque le paramètre `gtid` spécifie une transaction ayant déjà été exécutée par le réplica, la réplication est immédiatement arrêtée. ### Exemples L’exemple suivant lance la réplication et réplique les modifications jusqu’à ce que le GTID soit atteint `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` # Rotation des journaux de requêtes Les procédures stockées suivantes effectuent la rotation des journaux MySQL vers des tables de sauvegarde. Pour plus d’informations, consultez [Fichiers journaux de base de données Aurora MySQL](USER_LogAccess.Concepts.MySQL.md). **Topics** + [mysql.rds\$1rotate\$1general\$1log](#mysql_rds_rotate_general_log) + [mysql.rds\$1rotate\$1slow\$1log](#mysql_rds_rotate_slow_log) ## mysql.rds\$1rotate\$1general\$1log Convertit la table `mysql.general_log` en table de sauvegarde. ### Syntaxe ``` CALL mysql.rds_rotate_general_log; ``` ### Notes d’utilisation Vous pouvez convertir la table `mysql.general_log` en table de sauvegarde en appelant la procédure `mysql.rds_rotate_general_log`. Lors de la rotation des tables de journaux, la table de journal actuelle est copiée vers une table de journal de sauvegarde et les entrées de la table de journal actuelle sont supprimées. Si la table du journal de sauvegarde existe déjà, elle est supprimée avant que la table du journal active ne soit copiée dans la sauvegarde. Si besoin, vous pouvez interroger la table de journal de sauvegarde. La table de journal de sauvegarde de la table `mysql.general_log` est nommée `mysql.general_log_backup`. Vous ne pouvez exécuter cette procédure que lorsque le paramètre `log_output` est défini sur `TABLE`. ## mysql.rds\$1rotate\$1slow\$1log Convertit la table `mysql.slow_log` en table de sauvegarde. ### Syntaxe ``` CALL mysql.rds_rotate_slow_log; ``` ### Notes d’utilisation Vous pouvez convertir la table `mysql.slow_log` en table de sauvegarde en appelant la procédure `mysql.rds_rotate_slow_log`. Lors de la rotation des tables de journaux, la table de journal actuelle est copiée vers une table de journal de sauvegarde et les entrées de la table de journal actuelle sont supprimées. Si la table du journal de sauvegarde existe déjà, elle est supprimée avant que la table du journal active ne soit copiée dans la sauvegarde. Si besoin, vous pouvez interroger la table de journal de sauvegarde. La table de journal de sauvegarde de la table `mysql.slow_log` est nommée `mysql.slow_log_backup`. # Configuration et affichage de la configuration du journal binaire Les procédures stockées suivantes définissent et affichent les paramètres de configuration, tels que la conservation des fichiers journaux binaires. **Topics** + [mysql.rds\$1set\$1configuration](#mysql_rds_set_configuration) + [mysql.rds\$1show\$1configuration](#mysql_rds_show_configuration) ## mysql.rds\$1set\$1configuration Spécifie le nombre d’heures pendant lequel les journaux binaires doivent être conservés ou le nombre de secondes pendant lequel retarder la réplication. ### Syntaxe ``` CALL mysql.rds_set_configuration(name,value); ``` ### Parameters *name* Nom du paramètre de configuration à définir. *value* Valeur du paramètre de configuration. ### Notes d’utilisation La procédure `mysql.rds_set_configuration` prend en charge des paramètres de configuration suivants : + [nombre d’heures de conservation du journal binaire](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours) Les paramètres de configuration sont stockés de manière permanente et survivent à tout redémarrage ou basculement d’une instance de base de données. #### nombre d’heures de conservation du journal binaire Le paramètre `binlog retention hours` est utilisé pour spécifier le nombre d’heures de rétention des fichiers journaux binaires. Amazon Aurora purge normalement un journal binaire dès que possible, mais il se peut que le journal binaire soit encore requis pour la réplication avec une base de données MySQL extérieure à Aurora. La valeur par défaut de `binlog retention hours` est `NULL`. Pour Aurora MySQL, `NULL` signifie que les journaux binaires sont nettoyés lentement. Les journaux binaires Aurora MySQL peuvent rester dans le système pendant un certain temps, qui ne dépasse généralement pas un jour. Pour spécifier le nombre d’heures pendant lesquelles conserver les journaux binaires sur un cluster de bases de données, utilisez la procédure stockée `mysql.rds_set_configuration` et spécifiez une période suffisamment longue pour que la réplication se produise, comme illustré dans l’exemple suivant. `call mysql.rds_set_configuration('binlog retention hours', 24);` **Note** Vous ne pouvez pas utiliser la valeur `0` pour `binlog retention hours`. Pour des clusters de bases de données Aurora MySQL versions 2.11.0 et ultérieures et version 3, la valeur `binlog retention hours` maximale est 2 160 (90 jours). Après avoir défini la période de rétention, surveillez l’utilisation du stockage de l’instance de base de données afin de garantir que les journaux binaires conservés n’utilisent pas un espace de stockage trop grand. ## mysql.rds\$1show\$1configuration Nombre d’heures pendant lequel les journaux binaires sont conservés. ### Syntaxe ``` CALL mysql.rds_show_configuration; ``` ### Notes d’utilisation Pour vérifier le nombre d’heures pendant lequel Amazon RDS conserve les journaux binaires, utilisez la procédure stockée `mysql.rds_show_configuration`. ### Exemples L’exemple suivant affiche la période de rétention : ``` call mysql.rds_show_configuration; name value description binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted. ``` # Tables information\$1schema spécifiques à Aurora MySQL Aurora MySQL possède certaines tables `information_schema` spécifiques à Aurora. ## information\$1schema.aurora\$1global\$1db\$1instance\$1status La table `information_schema.aurora_global_db_instance_status` contient des informations sur l’état de toutes les instances de base de données dans les clusters de bases de données principal et secondaire d’une base de données globale. Les colonnes que vous pouvez utiliser sont indiquées dans le tableau suivant. Les colonnes restantes sont destinées à un usage interne d’Aurora uniquement. **Note** Cette table de schéma d’informations n’est disponible qu’avec les bases de données globales Aurora MySQL 3.04.0 et versions ultérieures. | Colonne | Type de données | Description | | --- | --- | --- | | SERVER\$1ID | varchar(100) | Identifiant de l’instance DB. | | SESSION\$1ID | varchar(100) | Identifiant unique de la session en cours. La valeur MASTER\$1SESSION\$1ID identifie l’instance de base de données d’enregistreur (principale). | | AWS\$1REGION | varchar(100) | La Région AWS dans laquelle cette instance de base de données globale s’exécute. Pour obtenir la liste des régions, consultez [Disponibilité dans les Régions](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability). | | DURABLE\$1LSN | bigint unsigned | Numéro de séquence de journal (LSN) rendu durable dans le stockage. Un numéro de séquence de journal (LSN) est un numéro séquentiel unique qui identifie un enregistrement dans le journal des transactions de la base de données. Les LSN sont classés de telle sorte qu’un LSN plus grand représente une transaction ultérieure. | | HIGHEST\$1LSN\$1RCVD | bigint unsigned | LSN le plus élevé reçu par l’instance de base de données en provenance de l’instance de base de données d’enregistreur. | | OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint unsigned | ID de la transaction la plus ancienne vers laquelle l’instance de base de données d’enregistreur peut effectuer une purge. | | OLDEST\$1READ\$1VIEW\$1LSN | bigint unsigned | LSN le plus ancien utilisé par l’instance de base de données pour lire à partir du stockage. | | VISIBILITY\$1LAG\$1IN\$1MSEC | float(10,0) unsigned | Pour les lecteurs dans le cluster de bases de données principal, retard accumulé par cette instance de base de données par rapport à l’instance de base de données d’enregistreur en millisecondes. Pour les lecteurs dans un cluster de bases de données secondaire, retard accumulé par cette instance de base de données par rapport au volume secondaire en millisecondes. | ## information\$1schema.aurora\$1global\$1db\$1status La table `information_schema.aurora_global_db_status` contient des informations sur divers aspects du retard de la base de données globale Aurora, en particulier le retard du stockage Aurora sous-jacent (appelé « retard de durabilité ») et le retard entre l’objectif de point de reprise (RPO). Les colonnes que vous pouvez utiliser sont indiquées dans le tableau suivant. Les colonnes restantes sont destinées à un usage interne d’Aurora uniquement. **Note** Cette table de schéma d’informations n’est disponible qu’avec les bases de données globales Aurora MySQL 3.04.0 et versions ultérieures. | Colonne | Type de données | Description | | --- | --- | --- | | AWS\$1REGION | varchar(100) | La Région AWS dans laquelle cette instance de base de données globale s’exécute. Pour obtenir la liste des régions, consultez [Disponibilité dans les Régions](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability). | | HIGHEST\$1LSN\$1WRITTEN | bigint unsigned | Numéro de séquence de journal (LSN) le plus élevé qui existe actuellement sur ce cluster de bases de données. Un numéro de séquence de journal (LSN) est un numéro séquentiel unique qui identifie un enregistrement dans le journal des transactions de la base de données. Les LSN sont classés de telle sorte qu’un LSN plus grand représente une transaction ultérieure. | | DURABILITY\$1LAG\$1IN\$1MILLISECONDS | float(10,0) unsigned | Différence dans les valeurs d’horodatage entre HIGHEST\$1LSN\$1WRITTEN sur un cluster de bases de données secondaire et HIGHEST\$1LSN\$1WRITTEN sur le cluster de bases de données principal. Cette valeur est toujours égale à 0 sur le cluster de bases de données principal de la base de données globale Aurora. | | RPO\$1LAG\$1IN\$1MILLISECONDS | float(10,0) unsigned | Retard de l’objectif de point de reprise (RPO). Le retard RPO correspond au temps nécessaire au stockage de la transaction utilisateur COMMIT la plus récente sur un cluster de bases de données secondaire, après qu’elle a été stockée sur le cluster de bases de données principal de la base de données globale Aurora. Cette valeur est toujours égale à 0 sur le cluster de bases de données principal de la base de données globale Aurora. En termes simples, cette métrique calcule l’objectif de point de reprise pour chaque cluster de bases de données Aurora MySQL dans la base de données globale Aurora, c’est-à-dire la quantité de données qui risque d’être perdue en cas de panne. Comme pour la latence, le RPO est mesuré dans le temps. | | LAST\$1LAG\$1CALCULATION\$1TIMESTAMP | datetime | Horodatage qui spécifie l’heure à laquelle les valeurs ont été calculées pour la dernière fois pour DURABILITY\$1LAG\$1IN\$1MILLISECONDS et RPO\$1LAG\$1IN\$1MILLISECONDS. Une valeur temporelle telle que 1970-01-01 00:00:00\$100 signifie qu’il s’agit du cluster de bases de données principal. | | OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint unsigned | ID de la transaction la plus ancienne vers laquelle l’instance de base de données d’enregistreur peut effectuer une purge. | ## information\$1schema.replica\$1host\$1status La table `information_schema.replica_host_status` contient des informations de réplication. Les colonnes que vous pouvez utiliser sont indiquées dans la table suivante. Les colonnes restantes sont destinées à un usage interne d’Aurora uniquement. | Colonne | Type de données | Description | | --- | --- | --- | | CPU | double | Pourcentage d’utilisation du processeur par l’hôte de réplication. | | IS\$1CURRENT | tinyint | Si la réplique est à jour. | | LAST\$1UPDATE\$1TIMESTAMP | datetime(6) | Heure de la dernière mise à jour. Utilisé pour déterminer si un enregistrement est périmé. | | REPLICA\$1LAG\$1IN\$1MILLISECONDS | double | Le retard de réplica en millisecondes. | | SERVER\$1ID | varchar(100) | ID du serveur de base de données. | | SESSION\$1ID | varchar(100) | ID de session de la base de données. Utilisé pour déterminer si une instance de base de données est une instance d’enregistreur ou de lecture. | **Note** Lorsqu’une instance de réplica prend du retard, les informations demandées dans sa table `information_schema.replica_host_status` peuvent être obsolètes. Dans ce cas, nous vous recommandons plutôt d’effectuer une requête à partir de l’instance d’enregistreur. La table `mysql.ro_replica_status` contient des informations similaires, mais nous vous déconseillons de l’utiliser. ## information\$1schema.aurora\$1forwarding\$1processlist La table `information_schema.aurora_forwarding_processlist` contient des informations sur les processus impliqués dans le transfert d’écriture. Le contenu de cette table est visible uniquement sur l’instance de base de données d’enregistreur pour un cluster de bases de données sur lequel le transfert d’écriture global ou intracluster est activé. Un jeu de résultats vide est renvoyé sur les instances de base de données de lecteur. | Champ | Type de données | Description | | --- | --- | --- | | ID | bigint | L’identifiant de la connexion sur l’instance de base de données d’enregistreur. Cet identifiant est la même valeur que celle affichée dans la colonne Id de l’instruction SHOW PROCESSLIST et renvoyée par la fonction CONNECTION\$1ID() dans le thread. | | USER | varchar(32) | Utilisateur MySQL qui a émis l’instruction. | | HOST | varchar(255) | Client MySQL qui a émis l’instruction. Pour les instructions transférées, ce champ indique l’adresse hôte du client d’application qui a établi la connexion sur l’instance de base de données du lecteur de transfert. | | BdD | varchar(64) | Base de données par défaut pour le thread. | | COMMAND | varchar(16) | Le type de commande que le thread exécute pour le compte du client, ou Sleep si la session est inactive. Pour une description des commandes de thread, consultez la documentation MySQL sur [Valeurs de Command de thread](https://dev.mysql.com/doc/refman/8.0/en/thread-commands.html) (langue française non garantie) dans la documentation MySQL. | | TIME | int | Durée en secondes pendant laquelle le thread est resté dans son état actuel. | | STATE | varchar(64) | Action, événement ou état qui indique ce que fait le thread. Pour une description des valeurs d’état, consultez [États de thread généraux](https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html) (langue française non garantie) dans la documentation MySQL. | | INFO | longtext | Instruction que le thread exécute, ou NULL s’il n’exécute pas d’instruction. L’instruction peut être celle qui est envoyée au serveur ou une instruction interne si l’instruction exécute d’autres instructions. | | IS\$1FORWARDED | bigint | Indique si le thread est transféré depuis une instance de base de données de lecteur. | | REPLICA\$1SESSION\$1ID | bigint | Identifiant de connexion sur le réplica Aurora. Cet identifiant est la même valeur que celle affichée dans la colonne Id de l’instruction SHOW PROCESSLIST sur l’instance de base de données du lecteur Aurora de transfert. | | REPLICA\$1INSTANCE\$1IDENTIFIER | varchar(64) | Identifiant de l’instance de base de données du thread de transfert. | | REPLICA\$1CLUSTER\$1NAME | varchar(64) | Identifiant du cluster de bases de données du thread de transfert. Pour le transfert d’écriture intracluster, cet identifiant est le même pour le cluster de bases de données et pour l’instance de base de données d’enregistreur. | | REPLICA\$1REGION | varchar(64) | La Région AWS d’où provient le thread de transfert. Pour le transfert d’écriture intracluster, cette région est la même Région AWS que pour l’instance de base de données d’enregistreur. |