Comment résoudre les problèmes qui entraînent le retard et le redémarrage de mon réplica en lecture Aurora ?

Résolution

Remarque : La résolution suivante s'applique aux clusters Aurora d'une seule région AWS et aux clusters principaux Global Database, et non aux clusters secondaires Global Database.

Mesurer AuroraReplicaLag

Les réplicas Aurora se connectent au même volume de stockage que l'instance d'écriture. Aurora écrit les modifications de manière synchrone sur le volume de stockage partagé, mais reproduit les modifications de manière asynchrone sur les instances de lecture. Pour garantir la cohérence de la lecture, Aurora invalide les données mises en cache en mémoire et liées à la modification. Le cache de données inclut le pool de mémoires tampons ou le cache de pages.

Dans certains cas, un délai peut survenir lorsque vous propagez les modifications entre les instances de lecture. Ce retard apparaît sous la forme d'une augmentation de la métrique AuroraReplicaLag dans Amazon CloudWatch, susceptible de provoquer des redémarrages. Le message d'erreur suivant peut s'afficher :

« Read Replica has fallen behind the master too much. Restarting ».

Pour Amazon Aurora édition compatible avec MySQL, exécutez la requête suivante dans la table INFORMATION_SCHEMA.REPLICA_HOST_STATUS pour mesurer AuroraReplicaLag :

select server_id AS Instance_Identifier, if(session_id = 'MASTER_SESSION_ID', 'writer', 'reader') as Role, replica_lag_in_milliseconds as AuroraReplicaLag from information_schema.replica_host_status;

Exemple de sortie :

+---------------------+--------+-------------------+  
| Instance_Identifier | Role   | AuroraReplicaLag  |  
+---------------------+--------+-------------------+  
| myamscluster-aza-1  | writer |                 0 |  
| myamscluster-azb-1  | reader | 5.150000095367432 |  
| myamscluster-aza-2  | reader | 5.033999919891357 |  
+---------------------+--------+-------------------+

Pour Amazon Aurora édition compatible avec PostgreSQL, exécutez la requête suivante pour obtenir la fonction aurora_replica_status() et filtrer les résultats :

select server_id, case when session_id= 'MASTER_SESSION_ID' then 'Writer' else 'Reader' end AS Role, replica_lag_in_msec as AuroraReplicaLag from aurora_replica_status();

Exemple de sortie :

server_id          | role   | aurorareplicalag  
-------------------+--------+------------------  
myapgcluster-aza-1 | Reader | 19.641  
myapgcluster-azb-1 | Reader | 19.752  
myapgcluster-aza-2 | Writer |  
(3 rows)

Assurez-vous que toutes les instances du cluster ont les mêmes spécifications

Si une instance de lecture utilise une configuration de classe d'instance de base de données inférieure à celle d'une instance de base de données d'écriture, le nombre de modifications est peut-être trop important. L'instance de lecture ne peut alors pas être invalidée dans le cache. Pour éviter ce problème, il est recommandé de conserver les mêmes spécifications pour toutes les instances de base de données du cluster Aurora.

Surveiller les sessions à l'aide de métriques et de la surveillance améliorée

Lorsque vous exécutez plusieurs sessions en même temps, une instance de lecture peut être retardée. Un réplica Aurora peut appliquer lentement les modifications nécessaires par rapport à l'auteur en raison du manque de ressources disponibles. Pour vérifier le retard, consultez les métriques CPUUtilization, DBConnections et NetworkReceiveThroughput. Vous pouvez également activer la surveillance améliorée avec une granularité de 1 à 5 secondes pour obtenir l'utilisation des ressources sur le lecteur. Vous pouvez également activer Performance Insights et utiliser Database Insights pour visualiser la charge de travail du lecteur. Pour qu'Aurora soit compatible avec PostgreSQL, vous pouvez utiliser la métrique ReadIOPS.

Important : Performance Insights atteindra sa fin de vie le 30 juin 2026. Vous pouvez effectuer une mise à niveau vers le mode Avancé de Database Insights avant le 30 juin 2026. Si vous n'effectuez pas de mise à niveau, les clusters de base de données qui utilisent Performance Insights passeront par défaut au mode Standard de Database Insights. Seul le mode Avancé de Database Insights prendra en charge les plans d'exécution et l’analyse à la demande. Si vos clusters passent par défaut en mode Standard, il est possible que vous ne puissiez pas utiliser ces fonctionnalités sur la console. Pour activer le mode Avancé, consultez les sections Activation du mode Avancé de Database Insights pour Amazon RDS et Activation du mode Avancé de Database Insights pour Amazon Aurora.

Utiliser CloudWatch pour visualiser l'activité d'écriture

Une augmentation soudaine de l'activité d'écriture dans un cluster de production déjà chargé en écriture peut surcharger l'instance de base de données d’écriture. La surcharge peut entraîner un ralentissement des instances de lecture. Utilisez CloudWatch pour afficher les métriques DMLThroughput, DDLThroughput et Requêtes qui indiquent des débordements soudains. Pour Aurora compatible avec PostgreSQL, consultez la métrique WriteThroughput.

Résoudre les problèmes liés aux transactions de longue durée pour Aurora compatible avec MySQL

Le moteur MySQL InnoDB utilise le contrôle de simultanéité multiversion (MVCC) par défaut. Vous devez donc suivre toutes les modifications apportées aux lignes pendant la durée d'une transaction. Une fois les transactions de longue durée terminées, un pic d'activité des threads de purge commence. La purge soudaine peut entraîner le retard d'un réplica Aurora en raison du volume du backlog créé par les transactions de longue durée.

Pour Aurora compatible avec MySQL, vérifiez la métrique RollbackSegmentHistoryListLength dans CloudWatch pour visualiser le pic de purge. Vous pouvez exécuter la commande SHOW ENGINE INNODB STATUS pour afficher la purge. Ou bien, exécutez la requête suivante :

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

Exemple de sortie :

+----------------------------------+-------+  
| RollbackSegmentHistoryListLength | COUNT |  
+----------------------------------+-------+  
| trx_rseg_history_len             |   358 |  
+----------------------------------+-------+  
1 row in set (0.00 sec)

Configurez des alarmes CloudWatch pour surveiller RollbackSegmentHistoryListoryLength afin de vous assurer qu'il n'atteint pas un nombre élevé. Il est recommandé d'éviter les transactions de longue durée dans les bases de données relationnelles.

Éviter les interruptions de réseau brèves

Bien que cela soit rare, des échecs de communication réseau transitoires entre les instances d'écriture et de lecture ou entre une instance et la couche de stockage Aurora peuvent survenir. Les instances de lecture peuvent être retardées ou redémarrées en raison d'une brève interruption du réseau. Le réplica Aurora peut également être retardé car un grand nombre de modifications ont surchargé la bande passante réseau de l'instance. Pour éviter ce problème, il est recommandé de modifier la taille de l'instance de base de données afin qu'elle puisse gérer le nombre de modifications.

Informations connexes

Ajouter des réplicas Aurora à un cluster de base de données

Réplication avec Amazon Aurora compatible avec MySQL

Surveillance des métriques dans un cluster Amazon Aurora

Métriques au niveau de l'instance pour Amazon Aurora