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

Dernière mise à jour : 10/07/2022

J'exécute un cluster de production de base de données Amazon Aurora. Mon instance de lecteur a redémarré avec le message d'erreur « Read Replica has fallen behind the master too much. Restarting MySQL » (Le réplica en lecture a pris trop de retard par rapport à l'élément maître. Redémarrage de MySQL) ou « Read Replica has fallen behind the master too much. Restarting postgres » (Le réplica en lecture a pris trop de retard par rapport à l'élément maître. Redémarrage de postgres). Pourquoi mon lecteur 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. Vous pouvez mesurer le retard entre les instances d'enregistreur et de lecteur à l'aide de 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 (pool de mémoires tampons ou cache de page) du réplica Aurora par rapport à celui de l'instance d'enregistreur de base de données. Les modifications sont écrites de manière synchrone sur le volume de stockage partagé, mais répliquées 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 Amazon Aurora à région unique, et non aux clusters de bases de données globales multirégion.

Solution

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

Lorsqu'une instance de lecteur a une configuration de classe d'instance de base de données plus faible que celle d'une instance d'enregistreur de base de données, le volume des modifications à invalider dans le cache peut être trop important pour le lecteur, qui ne peut donc rattraper le retard. Dans ce scénario, 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 d'Amazon 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 Amazon 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.