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. # Optimisation de la réplication des journaux binaires pour Aurora MySQL Découvrez ci-dessous comment optimiser les performances de réplication des journaux binaires et résoudre les problèmes connexes dans Aurora MySQL. **Astuce** Pour continuer, il est nécessaire de connaître le mécanisme de réplication de journaux binaires MySQL et son fonctionnement. Pour en savoir plus, consultez [Replication Implementation](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html) dans la documentation MySQL. ## Réplication des journaux binaires multithread Avec la réplication de journaux binaires multithreads, un thread SQL lit les événements du journal de relais et les met en file d’attente pour que les threads de travail SQL s’appliquent. Les threads de travail SQL sont gérés par un thread coordinateur. Si cela est possible, les événements du journal binaire sont appliqués en parallèle. Le niveau de parallélisme dépend de facteurs tels que la version, les paramètres, la conception du schéma et les caractéristiques de la charge de travail. La réplication multithread des journaux binaires est prise en charge dans Aurora MySQL version 3 et dans Aurora MySQL version 2.12.1 ou ultérieure. Pour qu’un réplica multithread traite efficacement les événements du journal binaire en parallèle, vous devez configurer la source pour la réplication des journaux binaires multithread. La source doit également utiliser une version qui inclut les informations de parallélisme sur ses fichiers journaux binaires. Lorsqu’une instance de base de données Aurora MySQL est configurée pour utiliser la réplication de journaux binaires, l’instance de réplica utilise par défaut la réplication à thread unique pour les versions d’Aurora MySQL inférieures à 3.04. Pour activer la réplication multithread, mettez à jour le paramètre `replica_parallel_workers` pour que sa valeur soit supérieure à `1` dans votre groupe de paramètres personnalisés. Pour Aurora MySQL 3.04 et versions ultérieures, la réplication est multithread par défaut. La valeur `replica_parallel_workers` est définie sur `4`. Vous pouvez modifier ce paramètre dans votre groupe de paramètres personnalisés. Pour augmenter la résilience de votre base de données face aux arrêts inattendus, nous vous recommandons d'activer la réplication GTID sur la source et d'autoriser GTIDs la réplication. Pour autoriser la réplication GTID, définissez `gtid_mode` sur `ON_PERMISSIVE` à la fois sur la source et le réplica. Pour en savoir plus sur les réplications basées sur des identifiants de transaction globaux (GTID), consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md). Les options de configuration suivantes vous permettent d’optimiser la réplication multithread. Pour plus d’informations, consultez [Options et variables de réplication et de journalisation binaire](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html) dans le *manuel de référence MySQL*. Pour plus d’informations sur la réplication multithread, consultez le blog MySQL [https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/](https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/). Les valeurs optimales des paramètres dépendent de plusieurs facteurs. Par exemple, les performances de la réplication des journaux binaires sont influencées par les caractéristiques de charge de travail de votre base de données, ainsi que la classe d’instance de base de données sur laquelle le réplica s’exécute. Dès lors, nous vous recommandons de tester minutieusement toutes les modifications apportées à ces paramètres de configuration avant d’appliquer de nouveaux paramètres à une instance de production : + `binlog_format recommended value` : défini sur `ROW` + `binlog_group_commit_sync_delay` + `binlog_group_commit_sync_no_delay_count` + `binlog_transaction_dependency_history_size` + `binlog_transaction_dependency_tracking` : la valeur recommandée est `WRITESET` + `replica_preserve_commit_order` + `replica_parallel_type` : la valeur recommandée est `LOGICAL_CLOCK` + `replica_parallel_workers` + `replica_pending_jobs_size_max` + `transaction_write_set_extraction` : la valeur recommandée est `XXHASH64` Les caractéristiques de votre schéma et de votre charge de travail sont des facteurs qui influent sur la réplication en parallèle. Les facteurs les plus courants sont les suivants. + Absence de clés primaires : RDS ne peut pas établir de dépendance entre les ensembles d’écritures pour les tables dépourvues de clés primaires. Avec le format `ROW`, une seule instruction à plusieurs lignes peut être exécutée avec une seule analyse de table complète au niveau de la source, mais il en résulte une analyse de table complète par ligne modifiée sur le réplica. L’absence de clés primaires réduit considérablement le débit de réplication. + Présence de clés étrangères : s’il existe des clés étrangères, Amazon RDS ne peut pas utiliser la dépendance entre les ensembles d’écritures pour le parallélisme des tables avec la relation FK. + Taille des transactions : si une seule transaction couvre des dizaines ou des centaines de mégaoctets ou de gigaoctets, le thread coordinateur et l’un des threads de travail peuvent passer beaucoup de temps à traiter uniquement cette transaction. Pendant ce temps, tous les autres threads de travail peuvent rester inactifs une fois qu’ils terminent le traitement de leurs transactions précédentes. Dans Aurora MySQL version 3.06 et versions ultérieures, vous pouvez améliorer les performances des réplicas de journaux binaires lors de la réplication des transactions pour de tables de grande taille comportant plusieurs index secondaires. Cette fonctionnalité introduit un groupe de threads permettant d’appliquer des modifications d’index secondaires en parallèle sur un réplica de journal binaire. Cette fonctionnalité est contrôlée par le paramètre de cluster de bases de données `aurora_binlog_replication_sec_index_parallel_workers`, qui contrôle le nombre total de threads parallèles disponibles pour appliquer les modifications d’index secondaires. Par défaut, ce paramètre est défini sur `0` (désactivé). L’activation de cette fonctionnalité ne nécessite pas le redémarrage de l’instance. Pour activer cette fonctionnalité, arrêtez la réplication en cours, définissez le nombre souhaité de threads de travail parallèles, puis relancez la réplication. ## Optimisation de la réplication des journaux binaires Dans Aurora MySQL 2.10 et versions ultérieures, Aurora applique automatiquement une optimisation connue sous le nom de I/O cache binlog à la réplication des journaux binaires. En mettant en cache les événements de journal binaire les plus récemment validés, cette optimisation est conçue pour améliorer les performances du thread de vidage des journaux binaires tout en limitant l’impact sur les transactions de premier plan sur l’instance source des journaux binaires. **Note** La mémoire utilisée pour cette fonction est indépendante du paramètre `binlog_cache` de MySQL. Cette fonction ne s’applique pas aux instances de base de données Aurora qui utilisent les classes d’instance `db.t2` et `db.t3`. Vous n’avez pas besoin d’ajuster les paramètres de configuration pour activer cette optimisation. En particulier, si vous aviez défini le paramètre de configuration `aurora_binlog_replication_max_yield_seconds` sur une valeur différente de zéro dans des versions antérieures d’Aurora MySQL, redéfinissez-le sur zéro pour les versions actuellement disponibles. Les variables `aurora_binlog_io_cache_reads` d'état vous `aurora_binlog_io_cache_read_requests` aident à surveiller la fréquence à laquelle les données sont lues à partir du I/O cache binlog. + `aurora_binlog_io_cache_read_requests`indique le nombre de demandes de I/O lecture du journal binaire depuis le cache. + `aurora_binlog_io_cache_reads`indique le nombre de I/O lectures du journal binaire qui extraient des informations du cache. La requête SQL suivante calcule le pourcentage de demandes de lecture de journaux binaires qui tirent parti des informations mises en cache. Dans ce cas, plus le ratio est proche de 100, mieux c’est. ``` mysql> SELECT (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads') / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests') * 100 as binlog_io_cache_hit_ratio; +---------------------------+ | binlog_io_cache_hit_ratio | +---------------------------+ | 99.99847949080622 | +---------------------------+ ``` La fonctionnalité de I/O cache binlog inclut également de nouvelles métriques liées aux threads de vidage de binlog. Les *threads de vidage* sont les threads créés lorsque de nouveaux réplicas de journaux binaires sont connectés à l’instance source des journaux binaires. Les métriques de thread de vidage sont imprimées dans le journal de la base de données toutes les 60 secondes avec le préfixe `[Dump thread metrics]`. Les métriques incluent des informations pour chaque réplica de journal binaire, telles que `Secondary_id`, `Secondary_uuid`, le nom du fichier journal binaire et la position que chaque réplica est en train de lire. Les métriques incluent également `Bytes_behind_primary`, qui représente la distance en octets entre la source de réplication et le réplica. Cette métrique mesure le décalage du I/O thread de réplication. Cette figure est différente du décalage du thread d’application SQL du réplica, représenté par la métrique `seconds_behind_master` sur le réplica du journal binaire. Vous pouvez déterminer si les réplicas de journaux binaires rattrapent la source ou sont en retard en vérifiant si la distance diminue ou augmente. ## Journal de relais en mémoire Dans Aurora MySQL 3.10 et versions ultérieures, Aurora introduit une optimisation connue sous le nom de « journal de relais en mémoire » afin d’améliorer le débit de réplication. Cette optimisation améliore les I/O performances des journaux de relais en mettant en cache tout le contenu des journaux de relais intermédiaires en mémoire. Par conséquent, il réduit la latence de validation en minimisant les I/O opérations de stockage puisque le contenu du journal du relais reste facilement accessible en mémoire. Par défaut, la fonctionnalité de journal de relais en mémoire est automatiquement activée pour les scénarios de réplication gérés par Aurora (y compris les déploiements bleu-vert, la réplication Aurora/Aurora et les réplicas entre régions) lorsque le réplica répond à l’une des configurations suivantes : + Mode de réplication à thread unique (replica\$1parallel\$1workers = 0) + Réplication multithread avec le mode GTID activé : + Positionnement automatique activé + Mode GTID activé sur le réplica + Réplication basée sur des fichiers avec replica\$1preserve\$1commit\$1order = ON La fonctionnalité de journal de relais en mémoire est prise en charge sur les classes d’instance supérieures à t3.large, mais n’est pas disponible sur les instances Aurora Serverless. La mémoire tampon circulaire du journal de relais a une taille fixe de 128 Mo. Pour contrôler la consommation de mémoire de cette version, vous pouvez exécuter la requête suivante : ``` SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache'; ``` La fonctionnalité de journal de relais en mémoire est contrôlée par le paramètre aurora\$1in\$1memory\$1relaylog, qui peut être défini au niveau du cluster de bases de données ou de l’instance de base de données. Vous pouvez activer ou désactiver cette version de manière dynamique sans avoir à redémarrer l’instance : 1. Arrêt de la réplication en cours 1. Définissez aurora\$1in\$1memory\$1relaylog sur ON (pour l’activer) ou OFF (pour le désactiver) dans le groupe de paramètres. 1. Redémarrage de la réplication Exemple : ``` CALL mysql.rds_stop_replication; set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group CALL mysql.rds_start_replication; ``` Même quand aurora\$1in\$1memory\$1relaylog est activé, la fonctionnalité de journal de relais en mémoire peut toujours être désactivée dans certaines conditions. Pour vérifier l’état actuel de cette fonctionnalité, vous pouvez utiliser la commande suivante : ``` SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status'; ``` Si la fonctionnalité est désactivée de façon inattendue, vous pouvez en identifier la raison en exécutant : ``` SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason'; ``` Cette commande renvoie un message expliquant pourquoi la fonctionnalité est actuellement désactivée.