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

Dernière mise à jour : 22/06/2020

J'exécute un cluster de base de données Amazon Aurora de production et mon nœud de lecteur a redémarré en affichant 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. Vous pouvez le constater dans la 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 concernant AuroraReplicaLag via la table INFORMATION_SCHEMA.REPLICA_HOST_STATUS comme suit :
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 comme suit :

postgres=> select server_id, case when session_id= 'MASTER_SESSION_ID' then 'Writer' else 'Reader' end AS Role,
cur_replay_latency_in_usec*1000/60/60/60 as AuroraReplicaLag 
from aurora_replica_status();

  server_id   |  role  | aurorareplicalag 
--------------+--------+---------------------
 read-node-01 | Reader |                 71
 read-node-02 | Reader |                 79
 primary-node | Writer |                    

Solution

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

Si 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 rattraper le retard. Dans ce scénario, une bonne pratique consiste à s'assurer 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 maître, à cause du manque de ressources disponibles. Vous pouvez le constater à 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. Vous pouvez le constater dans Amazon CloudWatch, qui indique des pics soudains des métriques DMLThroughput, DDLThroughput et Requêtes.

Pour Aurora PostgreSQL, vous pouvez l'observer à l'aide de 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.

À partir des versions 1.19.2 et 2.06, Aurora MySQL inclut la métrique RollbackSegmentHistoryListLength, que vous pouvez utiliser dans CloudWatch pour visualiser 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 suite à un grand volume de modifications ou de brèves moments de perte de paquets Inter-AZ. Pour éviter ce problème, vous devez tenir compte de la taille de l'instance de base de données, ainsi que de ses capacités de mise en réseau.

Remarques importantes à prendre en compte

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 maître 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.