Optimisation de la réplication des journaux binaires pour Aurora My SQL - 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 My SQL

Vous découvrirez ci-dessous comment optimiser les performances de réplication des journaux binaires et résoudre les problèmes connexes dans Aurora MySQL.

Astuce

Cette discussion suppose que vous connaissez le mécanisme de réplication de mon journal SQL binaire et son fonctionnement. Pour obtenir des informations générales, consultez la section Implémentation de la réplication dans la section Ma SQL documentation.

Réplication de journaux binaires multithread

Avec la réplication de journaux binaires multithread, un SQL thread lit les événements du journal de relais et les met en file d'attente pour que les SQL threads de travail s'appliquent. Les SQL threads de travail sont gérés par un thread de coordination. Si cela est possible, les événements du journal binaire sont appliqués en parallèle.

La réplication de journaux binaires multithread est prise en charge dans Aurora My SQL version 3, ainsi que dans Aurora My SQL version 2.12.1 et versions supérieures.

Lorsqu'une instance de base de SQL données Aurora My 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 SQL versions d'Aurora My inférieures à 3.04. Pour activer la réplication multithread, mettez à jour le paramètre replica_parallel_workers sur une valeur supérieure à zéro dans votre groupe de paramètres personnalisés.

Pour Aurora My SQL version 3.04 et versions ulté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é.

Les options de configuration suivantes vous permettent d'affiner la réplication multithread. Pour plus d'informations sur l'utilisation, consultez la section Options et variables de réplication et de journalisation binaire dans le manuel My SQL Reference.

Une configuration optimale dépend 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_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

  • binlog_transaction_dependency_history_size

  • binlog_transaction_dependency_tracking

  • replica_preserve_commit_order

  • replica_parallel_type

  • replica_parallel_workers

Dans Aurora My SQL 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 My SQL 2.10 et versions ultérieures, Aurora applique automatiquement une optimisation connue sous le nom de cache d'E/S 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 fonctionnalité est indépendante du SQL binlog_cache paramètre My.

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 SQL les versions antérieures d'Aurora My, 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 SQL requête suivante calcule le pourcentage de demandes de lecture du journal binaire 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. Ce chiffre est différent du décalage du thread d'SQLapplication de la réplique, qui est représenté par la seconds_behind_master métrique sur la réplique du binlog. 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.