Pourquoi mon réplica en lecture Amazon Aurora est-il en retard et a-t-il redémarré ?

Brève description

AuroraReplicaLag est une mesure du retard en millisecondes lors de la réplication des modifications de l'instance d'enregistreur de base de données Aurora vers les instances de lecteur d'un cluster de base de données Aurora. Les réplicas Aurora se connectent au même volume de stockage que l'instance d'enregistreur. Pour mesurer le retard entre les instances d'enregistreur et de lecteur, utiliser la métrique AuroraReplicaLag dans Amazon CloudWatch.

Pour un cluster de base de données Aurora, la métrique AuroraReplicaLag indique le retard du cache de données du réplica Aurora comparé à l'instance d'enregistreur de base de données. Le cache de données inclut le pool de mémoire tampon ou le cache de pages. Les modifications sont écrites de manière synchrone sur le volume de stockage partagé. Cependant, les changements sont répliqués de manière asynchrone sur les instances de lecteur, où toutes les données mises en cache en mémoire associées à la modification sont invalidées pour des raisons de cohérence de lecture. Dans certains cas, il peut y avoir un décalage lors de la propagation des modifications entre les instances de lecteur. Ce délai apparaît sous la forme d'une hausse de la métrique AuroraReplicaLag dans CloudWatch, qui peut entraîner à terme un redémarrage.

Vous pouvez mesurer les métadonnées en temps quasi réel à propos de AuroraReplicaLag :

Pour l'édition compatible avec Amazon Aurora MySQL, sélectionnez des éléments dans la table INFORMATION_SCHEMA.REPLICA_HOST_STATUS :

mysql> 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;

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

Pour l'édition compatible avec Amazon Aurora PostgreSQL, appelez la fonction aurora_replica_status() et filtrez les résultats :

postgres=> 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();

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

Remarque : La solution proposée dans cet article s'applique aux clusters principaux de base de données globale et à région unique Amazon Aurora, et non aux clusters secondaires de base de données globale.

Résolution

Assurez-vous que toutes les instances du cluster ont la même spécification

Si la configuration de classe d'instance de base de données d'une instance de lecture est plus faible que celle d'une instance de base de données d'écriture, le volume de modifications est peut-être trop important. Dans ce cas, l'instance de lecteur ne peut pas être invalidée dans le cache, puis rattraper son retard. Ainsi, une bonne pratique consiste à ce que toutes les instances de base de données du cluster Aurora aient la même spécification.

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

Une instance de lecteur peut subir un retard lorsque plusieurs sessions s'exécutent en même temps. Le manque de ressources disponibles peut ralentir l'application des modifications nécessaires provenant de l'enregistreur par un réplica Aurora. Vous pouvez constater cette latence à l'aide de métriques comme CPUUtilization, DBConnections et NetworkReceiveThroughput. Vous pouvez également activer la surveillance améliorée avec une granularité de 1 ou 5 secondes pour comprendre l'utilisation des ressources sur le lecteur. Vous pouvez également utiliser l'analyse des performances pour visualiser sa charge de travail. Pour l'édition compatible avec Aurora PostgreSQL uniquement, utilisez la métrique ReadIOPS.

Visualiser l'activité d'écriture à l'aide de CloudWatch

Une hausse soudaine d'activité d'écriture au sein d'un cluster de production déjà intense en écriture peut entraîner une surcharge sur l'instance d'enregistreur de base de données. Le stress supplémentaire causé par cette hausse d'activité peut entraîner le retard d'une ou de plusieurs instances de lecteur. Vous pouvez le constater dans CloudWatch via l'affichage de pics soudains des métriques DMLThroughput, DDLThroughput et Requêtes.

Pour Aurora PostgreSQL, vous pouvez le constater dans la métrique WriteThroughput.

Enquêter sur une longueur de liste d'historique (HLL) de plus en plus élevée (édition compatible avec Aurora MySQL)

Le moteur InnoDB de MySQL intègre par défaut le contrôle de simultanéité multiversion (MVCC). Cela signifie que vous devez suivre toutes les modifications apportées à toutes les lignes concernées tout au long de la durée d'une transaction. Une fois les transactions de longue durée terminées, un pic d'activité du thread de purge commence. En raison du volume de fichiers en attente créés par des transactions de longue durée, la purge soudaine peut entraîner le retard d'un réplica Aurora.

Sur les versions 1.19.2, 2.06 et versions ultérieures, Aurora MySQL intègre la métrique RollbackSegmentHistoryListLength. Vous pouvez utiliser cette métrique dans CloudWatch pour visualiser la purge. Vous pouvez également l'observer sur la sortie de SHOW ENGINE INNODB STATUS ou en interrogeant le schéma d'informations comme suit :

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

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

Configurez des alarmes CloudWatch pour surveiller cette métrique afin qu'elle n'atteigne pas une valeur trop élevée. Cette bonne pratique en matière de bases de données relationnelles permet d'éviter les transactions de longue durée.

Éviter les brèves interruptions du réseau

Même s'ils restent rares, des échecs de communication réseau temporaire peuvent se produire entre les instances d'enregistreur et de lecteur, ou entre une instance et la couche de stockage Aurora. Les instances de lecteur peuvent prendre du retard ou redémarrer en raison d'une brève interruption de la mise en réseau. Le réplica Aurora peut également prendre du retard en raison de la saturation de la bande passante du réseau de l'instance occasionnée par un trop grand nombre de modifications. Une bonne pratique consiste à tenir compte de la taille de l'instance de base de données, ainsi que de ses capacités de mise en réseau.

---

Informations connexes

Ajout de réplicas Aurora à un cluster de bases de données

Réplication à partir d'un seul maître avec Amazon Aurora MySQL

Surveillance des métriques dans un cluster Amazon Aurora