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.

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 les GTID sur le réplica. 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).

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 dans le manuel de référence MySQL. Pour plus d’informations sur la réplication multithread, consultez le blog MySQL 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 :

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.

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 pool 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 versions 2.10 et ultérieures, Aurora applique automatiquement une optimisation connue sous le nom de cache d’I/O de journaux binaires à 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.

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 d’état aurora_binlog_io_cache_reads et aurora_binlog_io_cache_read_requests vous aident à surveiller la fréquence à laquelle les données sont lues à partir du cache d’E/S des journaux binaires.

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 fonction de cache d’I/O de journaux binaires inclut également de nouvelles métriques liées aux threads de vidage des journaux binaires. 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 thread d’I/O du réplica. 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 performances d’E/S du journal de relais en mettant en cache tout le contenu des journaux de relais intermédiaires en mémoire. Par conséquent, elle réduit la latence de validation en minimisant les opérations d’E/S du stockage, car le contenu du journal de 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 :

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_in_memory_relaylog, 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 :

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_in_memory_relaylog 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.