Comment résoudre les problèmes liés à l'utilisation de réplicas en lecture dans mon instance de base de données Aurora compatible avec MySQL ?

Résolution

Promouvoir un réplica en lecture Aurora compatible avec MySQL

Si l'instance en écriture requiert un redémarrage ou une maintenance, effectuez un basculement manuel pour promouvoir un réplica en lecture en tant qu'instance en écriture.

Pour effectuer un basculement manuel, procédez comme suit :

1. Ouvrez la console Amazon RDS.
2. Dans le volet de navigation, sélectionnez Bases de données.
3. Sélectionnez l’instance en écriture pour votre cluster de base de données Aurora.
4. Sélectionnez Actions, puis Basculement.

Si l’instance en écriture devient indisponible, Aurora bascule automatiquement sur une instance de réplica en lecture. Une instance en écriture peut devenir indisponible pour de multiples raisons, telles qu'un conflit de ressources ou une activité de maintenance.

Si vous disposez de plusieurs lecteurs, spécifiez un niveau de priorité de promotion pour chaque instance de votre cluster. En cas d’échec de l’instance en écriture, Aurora compatible avec MySQL promeut le réplica avec la priorité la plus élevée en tant que nouvel enregistreur.

Vous pouvez également promouvoir un réplica Aurora entre régions AWS en tant que cluster de base de données autonome. Une fois que vous avez lancé le processus de promotion, la réplication interrégionale s’arrête. Le cluster nouvellement promu fonctionne comme un cluster de bases de données indépendant et gère à la fois les opérations de lecture et d’écriture.

Évaluer le retard de réplication

Toutes les instances de base de données Aurora compatibles avec MySQL d’un cluster de base de données partagent un volume de données commun. Le retard de réplication est donc minime. Toutefois, il se peut que vous constatiez une léger retard accru sur les lecteurs dans certains scénarios.

Remarque : Les réplicas interrégionaux utilisent la réplication de journaux binaires. Les taux de changement et d’application, ainsi que les retards dans la communication réseau entre les régions sélectionnées peuvent affecter les réplicas interregionaux. Les réplicas interrégionaux qui utilisent des bases de données Aurora compatibles avec MySQL présentent un retard type de moins d'une seconde.

Pour mesurer le retard de réplication, utilisez les métriques Amazon CloudWatch suivantes :

• La métrique AuroraReplicaLag évalue le retard de réplica entre le nœud d’écriture et le nœud de lecture en millisecondes dans la même région.
• La métrique AuroraBinlogReplicaLag évalue le retard de réplica entre les clusters de bases de données Aurora qui utilisent des journaux binaires.

Pour plus d'informations sur les métriques précédentes, consultez la section Métriques au niveau de l'instance pour Amazon Aurora.

Améliorer les performances de réplication

Effectuez les opérations suivantes :

• Pour éviter les charges de travail importantes sur les instances en lecture, il est préférable que toutes les instances d’un cluster aient la même taille. Lorsque l'instance en lecture est plus petite que l'instance en écriture, elle ne peut pas suivre le volume de modifications. 
  Remarque : Si la charge de travail est importante sur l’instance en écriture, vous remarquerez peut-être un retard de réplica en lecture. Une fois que l’instance en lecture a rattrapé l’instance en écriture, le retard diminue.
• Pour éviter les retards de réplication lorsque des transactions de longue durée sont en cours, exécutez vos transactions par lots de plus petite taille et exécutez fréquemment des validations.

Pour plus d'informations sur l'utilisation de la réplication MySQL native basée sur les journaux binaires pour résoudre les problèmes de latence des réplicas, consultez la section Problèmes de réplication MySQL d’Amazon Aurora.

Résoudre les problèmes liés à un retard de réplication élevé

Utilisez la métrique CloudWatch AuroraReplicaLag pour vérifier le retard de réplication élevé. Un retard de réplication élevé peut entraîner le redémarrage d’une instance en lecture. Pour résoudre ce problème, consultez la section Pourquoi mon réplica en lecture Amazon Aurora a-t-il pris du retard et redémarre-t-il ?

Configurer la réplication basée sur les GTID

Aurora n’utilise pas la réplication native de journaux binaires pour répliquer les données vers les instances de réplica en lecture. Vous ne pouvez pas utiliser d’identifiant de transaction globale (GTID) pour répliquer les données entre les instances d’un même cluster. Toutefois, vous pouvez configurer la réplication basée sur les GTID dans certains scénarios. Pour plus d’informations sur l’utilisation de la réplication basée sur les GTID dans Aurora compatible avec MySQL, consultez la section La compatibilité MySQL d’Amazon Aurora prend désormais en charge la réplication basée sur les identifiants de transaction globaux (GTID).

Pour les versions 3.04 et supérieures d’Aurora compatibles avec MySQL, la réplication de journaux binaires multithread est activée et replica_parallel_workers est défini sur 4 par défaut. La réplication de journaux binaires multithread étant activée, vous devez renforcer la résilience de votre base de données en cas d'arrêt inattendu. Il est recommandé d'activer la réplication GTID sur votre source et d'autoriser les GTID sur le réplica.

Remarque : Vous pouvez configurer une réplication basée sur GTID entre des clusters Aurora ainsi qu'entre Amazon Relational Database Service (Amazon RDS) for MySQL et un cluster Aurora. La source doit être un serveur principal externe. Avant de démarrer le processus de réplication, veillez à activer la journalisation binaire sur la source.

Pour plus d’informations sur les GTID, consultez la page Format GTID et stockage sur le site Web de MySQL.

Informations connexes

Réplication de clusters de bases de données Amazon Aurora MySQL dans les régions AWS

Réplication avec Amazon Aurora