Comment puis-je résoudre les problèmes courants lors de l'utilisation de réplicas en lecture dans Amazon Aurora ?

Brève description

Amazon Aurora MySQL prend en charge les réplicas en lecture qui partagent un volume sous-jacent commun avec une instance de base de données d’écriture dans la même région AWS. Si vous modifiez votre instance de base de données d’écriture, les mises à jour sont visibles pour les instances de réplica dans le cluster de base de données. Vous pouvez également créer des réplicas en lecture MySQL entre régions. Ceux-ci sont implémentés à l'aide du moteur de réplication basé sur le binlog MySQL.

Il est recommandé d'utiliser des réplicas Aurora lors de la mise à l'échelle des opérations de lecture. Pour ce faire, vous réduisez la charge de travail de lecture sur le dispositif d’écriture. Ensuite, augmentez la disponibilité pour gérer les événements qui ralentissent ou bloquent la mise à l'échelle.

Résolution

Comment faire la promotion d'un réplica en lecture Aurora ?

Basculement manuel : effectuez un basculement manuel pour promouvoir une autre instance de réplica en lecture en tant qu'instance d’écriture en procédant comme suit :

1. Connectez-vous à la console Amazon Relational Database Service (Amazon RDS).
2. Choisissez Bases de données dans le volet de navigation.
3. Choisissez l'instance d’écriture pour votre cluster de base de données Aurora.
4. Choisissez Actions, puis Basculer.

Basculement automatique : Aurora bascule automatiquement vers une instance de réplica en lecture si l'instance d’écriture devient indisponible. Cela peut se produire pour un certain nombre de raisons, y compris les conflits de ressources et les activités de maintenance. Si vous avez plusieurs dispositifs de lecture, vous pouvez attribuer un niveau de priorité de promotion à chaque instance de votre cluster. Lorsque l'instance d’écriture échoue, Aurora promeut le réplica avec la plus haute priorité en tant que nouveau dispositif d’écriture.

Vous pouvez également promouvoir un réplica Aurora entre région en tant que cluster de base de données autonome. La réplication entre régions s'arrête quand le processus de promotion est lancé. Le cluster nouvellement promu fonctionne comme un cluster de base de données indépendant et gère les opérations de lecture et d'écriture.

Comment puis-je mesurer le décalage de réplication ?

Étant donné que toutes les instances de base de données Aurora d'un cluster de base de données unique partagent un volume de données commun, il y a un décalage de réplication minimal. Habituellement, les temps de décalage sont dans les 10 millisecondes. Cependant, vous pouvez observer un peu plus de décalage sur les dispositifs de lecture dans quelques situations spécifiques.

Remarque : Les réplicas entre régions utilisent une réplication logique et sont affectés par le taux de modification/application et les délais de communication réseau entre les régions spécifiques sélectionnées. Les réplicas entre régions utilisant les bases de données Aurora ont généralement un délai inférieur à une seconde.

Vous pouvez mesurer le décalage de réplication à l'aide des métriques Amazon CloudWatch suivantes :

• Utilisez AuroraReplicaLag pour mesurer le décalage de réplica entre le nœud d’écriture et de lecture en millisecondes (même région).
• Utilisez AuroraBinlogReplicaLag pour mesurer le décalage de réplica entre les clusters de base de données Aurora à l'aide de journaux binaires.

Comment puis-je améliorer les performances de réplication ?

Suivez ces recommandations pour diminuer le décalage de réplica :

• Si l'instance de lecture est plus petite que l'instance d’écriture, le volume des modifications peut être trop important pour que le dispositif de lecture puisse rattraper celui d’écriture. Il est recommandé que toutes les instances d'un cluster aient la même taille pour éviter toute surcharge de travail sur les instances du dispositif de lecture.
• S'il y a une charge de travail lourde sur le dispositif d’écriture, vous pouvez remarquer un décalage temporaire du réplica en lecture. Le décalage diminue après que l'instance de lecture rattrape l'instance d’écriture.
• Si des transactions de longue durée sont en cours, vous pouvez observer un décalage de réplica sur les dispositifs de lecture. Pour éviter le décalage de réplica, exécutez vos transactions par lots plus petits et exécutez des validations plus fréquemment.

Pour plus d'informations sur la résolution des problèmes de décalage de réplica élevé à l'aide de la réplication MySQL basée sur binlog natif, consultez Présentation de la sauvegarde et de la restauration d'un cluster de base de données Aurora.

Puis-je utiliser un identificateur de transaction global (GTID, global transaction identifier) ?

Un identificateur de transaction global est une chaîne unique qui est associée à une transaction sur sa validation. Un GTID est unique sur tous les serveurs et les modifications sont appliquées à la cible, en fonction de la valeur du GTID. Pour plus d'informations, reportez-vous à la documentation MySQL et les concepts du GTID.

Aurora n'utilise pas la réplication binlog native pour répliquer des données afin de lire les instances de réplica. Il n'est pas possible d'utiliser un GTID pour répliquer des données entre des instances du même cluster. Toutefois, vous pouvez configurer la réplication basée sur un GTID dans certains scénarios. Pour plus d'informations sur l'utilisation de la réplication basée sur un GTID dans Aurora MySQL, consultez le blog AWS sur le GTID.

Remarque : Vous pouvez configurer la réplication basée sur un GTID entre un Amazon RDS MySQL et un cluster Aurora, et entre les clusters Aurora (en supposant que la source est un administrateur externe). Assurez-vous d'activer le binlog sur la source avant de démarrer le processus de réplication.

---

Informations connexes

Réplication avec Amazon Aurora

Qu'est-ce qu'Amazon Aurora ?