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.

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 ulté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 :

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 aurora_binlog_replication_sec_index_parallel_workers DB cluster, 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.

Vous pouvez également utiliser ce paramètre comme variable globale, où n est le nombre de threads de travail parallèles :

SET global aurora_binlog_replication_sec_index_parallel_workers=n;

Optimisation de la réplication des journaux binaires (Aurora My SQL 2.10 et versions ultérieures)

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.

Vous n'avez pas besoin d'ajuster les paramètres de configuration pour activer cette optimisation. En particulier, si vous réglez 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 Aurora My SQL 2.10 et versions ultérieures.

Les variables aurora_binlog_io_cache_reads d'état aurora_binlog_io_cache_read_requests sont disponibles dans Aurora My SQL 2.10 et versions ultérieures. Ces variables de statut vous aident à surveiller la fréquence à laquelle les données sont lues à partir du cache d'I/O des journaux binaires.

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.

Optimisation de la réplication des journaux binaires (Aurora My SQL versions 2 à 2.09)

Pour optimiser la réplication des journaux binaires pour Aurora MySQL, vous devez ajuster les paramètres d'optimisation suivants au niveau du cluster. Ils vous aident à spécifier le juste équilibre entre la latence sur l'instance source binlog et le retard de réplication.

Présentation du tampon de lecture de grande taille et des optimisations de rendement maximum

Les performances de réplication de journaux binaires peuvent diminuer lorsque le thread de vidage de journaux binaires accède au volume du cluster Aurora alors que le cluster traite un nombre élevé de transactions. Vous pouvez utiliser les paramètres aurora_binlog_use_large_read_buffer, aurora_binlog_replication_max_yield_seconds et aurora_binlog_read_buffer_size pour minimiser ce type de conflit.

Supposons que aurora_binlog_replication_max_yield_seconds soit défini sur une valeur supérieure à 0 et le fichier binlog actuel du thread de vidage soit actif. Dans ce cas, le thread de vidage de journaux binaires attend jusqu'à un nombre spécifié de secondes pour que le fichier binaire actuel soit rempli par les transactions. Ce temps d'attente évite les conflits pouvant résulter de la réplique de chacun des événements binlog. Cependant, il augmente le retard de réplica des réplicas de journaux binaires. Ces réplicas peuvent prendre du retard, par rapport à la source, du même nombre de secondes que le paramètre aurora_binlog_replication_max_yield_seconds.

Le fichier binlog « actuel » est celui qui est en train d'être lu par le thread de vidage pour effectuer la réplication. Nous considérons qu'un fichier binlog est actif lorsqu'il est en cours de mise à jour ou ouvert pour être mis à jour par les transactions entrantes. Une fois qu'Aurora My a SQL rempli le fichier binlog actif, My SQL crée et passe à un nouveau fichier binlog. L'ancien fichier binlog devient inactif. Il n'est plus mis à jour par les transactions entrantes.

Aurora My SQL reconnaît immédiatement toute modification apportée à la valeur du aurora_binlog_replication_max_yield_seconds paramètre. Vous n'avez pas besoin de redémarrer l'instance de base de données. Toutefois, lorsque vous activez ce paramètre, le thread de vidage commence à produire uniquement lorsque le fichier binlog actuel atteint sa taille maximale de 128 Mo et fait l'objet d'une rotation vers un nouveau fichier.

Paramètres connexes

Utilisez les paramètres de cluster de base de données suivants pour activer l'optimisation des journaux binaires.

Activation du mécanisme de rendement maximum de la réplication des journaux binaires

Vous pouvez activer l'optimisation du rendement maximum de la réplication de journaux binaires comme suit. Cela réduit la latence des transactions sur l'instance source binlog. Toutefois, le retard de réplication peut augmenter.

Désactivation de l'optimisation du rendement maximum de la réplication de journaux binaires

Vous pouvez désactiver l'optimisation du rendement maximum de la réplication de journaux binaires comme suit. Cela permet de réduire le retard de réplication. Toutefois, la latence des transactions sur l'instance source binlog peut augmenter.

Désactivation du tampon de lecture de grande taille

Vous pouvez désactiver l'ensemble de la fonction de tampon de lecture de grande taille comme suit.