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

Dernière mise à jour : 02/02/2021

J'exécute un cluster de production DB Amazon Aurora. Mon nœud 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 mises à jour de l'instance de base de données Aurora principale vers les nœuds 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 de base de données principale et prennent uniquement en charge les opérations de lecture. Vous pouvez mesurer le retard entre le nœud principal et les nœuds de lecteur à l'aide de la métrique AuroraReplicaLag dans Amazon CloudWatch.

Pour un cluster de base de données Aurora PostgreSQL, la métrique AuroraReplicaLag indique le retard du cache de page du réplica Aurora par rapport à celui de l'instance de base de données principale. Cela signifie qu'une fois que les données ont été écrites sur le volume de cluster, elles sont accessibles à la fois pour les nœuds d'enregistreur et de lecteur, en quasi temps réel.

Pour vous assurer que vos modifications sont propagées entre les nœuds de lecteur, vous devez invalider les données mises en cache à des fins de cohérence de lecture. Dans certains cas, il peut y avoir un décalage lors de la propagation des modifications entre les nœuds de lecteur. Ce délai apparaît sous la forme d'une hausse de la métrique AuroraReplicaLag dans CloudWatch, entraînant à terme le redémarrage.

Pour Aurora MySQL, vous pouvez mesurer les métadonnées quasiment en temps réel d'AuroraReplicaLag via 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  |
+---------------------+--------+-------------------+
| primary-instance    | writer |                 0 |
| reader-node-02      | reader | 5.150000095367432 |
| reader-node-03      | reader | 5.033999919891357 |
+---------------------+--------+-------------------+

Pour 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
-------------+--------+------------------
read-node-01 | Reader | 19.641
read-node-02 | Reader | 19.752
primary-node | Writer |
(3 rows)

Résolution

S'assurer que toutes les instances du cluster ont la même spécification

Lorsqu'un nœud de lecteur a une configuration de classe d'instance de base de données plus faible que celle d'une instance de base de données d'enregistreur, 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 ont la même spécification.

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

Un nœud de lecteur peut subir un retard lorsque plusieurs sessions s'exécutent en même temps. Un réplica Aurora peut être lent à appliquer les modifications nécessaires provenant de l'élément principal, à cause du manque de ressources disponibles. Vous pouvez constater cette latence à l'aide de métriques comme CPUUtilization, DBConnections, NetworkReceiveThroughput et ActiveTransactions.

Pour Aurora PostgreSQL, au lieu d'ActiveTransactions, utilisez la métrique ReadIOPS. Vous pouvez activer la surveillance améliorée avec une granularité d'au moins 5/1 en secondes pour comprendre l'utilisation du nœud de lecteur. Vous pouvez également utiliser l'analyse des performances pour visualiser la charge de travail.

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 de base de données de l'enregistreur. La sollicitation supplémentaire provoquée par cette augmentation peut entraîner le retard des nœuds de lecteur. Cela est visible dans Amazon CloudWatch via l'affichage de pics soudains des métriques DMLThroughput, DDLThroughput et Requêtes.

Pour Aurora PostgreSQL, cela est visible dans la métrique WriteThroughPut.

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

Le moteur InnoDB de MySQL intègre le contrôle de simultanéité multiversion (MVCC), par défaut. Cela signifie que vous devez suivre toutes les modifications qui ont eu lieu sur 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.

À compter des versions 1.19.2 et 2.06, Aurora MySQL intègre la métrique RollbackSegmentHistoryListLength. Vous pouvez utiliser cette métrique dans CloudWatch pour voir cette purge. On peut également l'observer à partir 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. Dans Aurora, il est recommandé d'incorporer des transactions à courte durée de vie simultanées élevées, afin d'éviter d'exécuter des transactions de longue durée.

Résoudre les problèmes de réseau transitoire

Bien que rare, un échec de communication réseau temporaire peut se produire entre les nœuds d'enregistreur et de lecteur, ou les nœuds et la couche de stockage Aurora. Les nœuds 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 prendre du retard en raison de la saturation du réseau à cause d'un grand volume de modifications ou de brèves moments de perte de paquets Inter-AZ. 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.

Important : certaines fonctionnalités notables d'Aurora MySQL 1.x, disponibles à partir de la version 1.17.4 sont importantes à connaître :

  • aurora_enable_replica_log_compression est un paramètre de cluster qui permet la compression des charges utiles de réplication afin d'améliorer l'utilisation de la bande passante réseau entre le réplica principal et les réplicas Aurora. Cela est utile lorsque la saturation du réseau est évidente.

  • aurora_enable_zdr est un paramètre de cluster que vous pouvez utiliser pour conserver toutes les connexions ouvertes et les préserver lors du redémarrage d'un réplica Aurora.

  • aurora_enable_staggered_replica_restart est un paramètre de cluster qui permet aux réplicas Aurora de suivre un calendrier de redémarrage échelonné pour augmenter la disponibilité du cluster.