Optimisation de la réplication des journaux binaires pour Aurora MySQL - Amazon Aurora
Réplication de journaux binaires multithreadOptimisation de la réplication des journaux binaires

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 dans la documentation MySQL.

Réplication de 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 le thread de coordination. 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 de journaux binaires multithread est prise en charge dans Aurora MySQL version 3, ainsi que dans Aurora MySQL version 2.12.1 et supérieure. Pour qu'une réplique 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, et la source doit 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éplique utilise par défaut la réplication monothread pour les versions d'Aurora MySQL inférieures à 3.04. Pour activer la réplication multithread, vous devez mettre à jour le replica_parallel_workers paramètre avec une valeur supérieure 1 à celle de votre groupe de paramètres personnalisé.

Pour Aurora MySQL version 3.04 et versions supérieures, la réplication est multithread par défaut, avec replica_parallel_workers la valeur définie sur. 4 Vous pouvez modifier ce paramètre dans votre groupe de paramètres personnalisé.

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 à la fois ON_PERMISSIVE sur la source et sur la réplique. Pour en savoir plus sur les réplications basées sur des identifiants de transaction globaux (GTID), consultez Utilisation de GTID la réplication basée.

Les options de configuration suivantes vous permettent d'affiner 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 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. Nous vous recommandons donc 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— réglé 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 ROW format, une seule instruction à plusieurs lignes peut être exécutée avec un seul scan complet du tableau sur la source, mais il en résulte un scan complet du tableau 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 — Si des clés étrangères sont présentes, Amazon RDS ne peut pas utiliser la dépendance aux 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 ont terminé 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épliques de journaux binaires lors de la réplication de transactions pour de grandes tables comportant plusieurs index secondaires. Cette fonctionnalité introduit un pool de threads permettant d'appliquer des modifications d'index secondaires en parallèle sur une réplique binlog. La fonctionnalité est contrôlée par le paramètre de aurora_binlog_replication_sec_index_parallel_workers cluster de base de données, qui contrôle le nombre total de threads parallèles disponibles pour appliquer les modifications d'index secondaires. Le paramètre est défini sur 0 (désactivé) par défaut. 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.

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 ajusté le paramètre de configuration aurora_binlog_replication_max_yield_seconds à une valeur différente de zéro dans les versions antérieures d'Aurora MySQL, remettez-le à 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 cache d'E/S binlog.

  • aurora_binlog_io_cache_read_requests affiche le nombre de demandes de lecture d'I/O de journaux binaires provenant du cache.

  • aurora_binlog_io_cache_reads affiche le nombre de lectures d'I/O de journaux binaires qui récupèrent 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 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.