Comment résoudre le problème de délai dans mon réplica en lecture de RDS for SQL Server ?

Brève description

Amazon RDS for SQL Server Enterprise Edition prend en charge la création d'un réplica en lecture dans la même région. La réplication des données est asynchrone et utilise la technologie Always-On pour répliquer les données d'un maître vers une instance de réplica. RDS for SQL Server n'intervient pas pour atténuer le délai élevé des réplicas entre une instance de base de données source et ses réplicas en lecture.

Solution

1.    Vérifiez l'utilisation des ressources sur le maître et sur l'instance de réplica à l'aide d'Amazon CloudWatch. Utilisez les fonctions Enhanced Monitoring et Performance Insights pour vérifier l'utilisation des ressources à un niveau granulaire.

Considérations importantes pour les métriques sur les instances principales et de réplica :

• Assurez-vous que l'utilisation du CPU n'est pas limitée. Si vous exécutez une classe d'instance à capacité extensible, assurez-vous que des crédits CPU sont disponibles ou que vous exécutez en mode illimité.
• Assurez-vous qu'il y a suffisamment de FreeableMemory. Assurez-vous également que les ReadIOPS et WriteIOPS atteignent les limites provisionnées. Vérifiez qu'il y a suffisamment de solde de transmission en rafales disponible si vous utilisez un volume GP2. Pour plus d'informations, consultez Comment résoudre le problème de faible quantité de mémoire libérable dans mon instance RDS for SQL Server ?
• Assurez-vous que ReadThroughput et WriteThroughput n'atteignent pas les limites de classe d'instance.

2.    Créer les instances principales et de réplica avec la même classe d'instance, le même type de stockage et le même nombre d'IOPS constitue une bonne pratique. Cela permet d'éviter les délais de réplica causés par le manque de ressources dans l'instance de réplica. De plus, en fonction de la charge de travail, la réplica en lecture peut être augmentée ou réduite si l'utilisation est minime par rapport à l'instance principale.

3.    Identifiez le moment où le délai de réplica a commencé à augmenter, puis effectuez les opérations suivantes :

Vérifiez les métriques WriteIOPS, WriteThroughput, NetworkReceiveThroughput et NetworkTrasmitThroughput sur l'instance principale en fonction de l'heure de début du délai de réplica. Déterminez si le délai est dû à l'activité d'écriture. Vérifiez les mêmes métriques dans la même période de temps sur le réplica en lecture.

Vérifiez s'il y a des transactions de longue durée sur l'instance principale. Voici un exemple de requête pour vérifier le statut des transactions actives :

SELECT * FROM sys.sysprocesses WHERE open_tran = 1;

4.    Sur l'instance de réplica, vérifiez s'il y a des attentes de verrou importantes ou des blocages. Les blocages se produisent entre les transactions Select et DDL/DML et provoquent des délais dans l'application des journaux de transactions de l'instance principale.

Voici un exemple de requête pour vérifier les blocages :

SELECT * FROM sys.sysprocesses WHERE blocked > 0;

5.    Requête permettant de vérifier le délai de réplica et le délai de réplica maximum.

Délai de réplica

SELECT AR.replica_server_name
     , DB_NAME (ARS.database_id) 'database_name'
     , AR.availability_mode_desc
     , ARS.synchronization_health_desc
     , ARS.last_hardened_lsn
     , ARS.last_redone_lsn
     , ARS.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states ARS
INNER JOIN sys.availability_replicas AR ON ARS.replica_id = AR.replica_id
--WHERE DB_NAME(ARS.database_id) = 'database_name'
ORDER BY AR.replica_server_name;

Vérifiez que la valeur « last_hardened_lsn » progresse sur le réplica en lecture.

Délai maximal de réplica

Pour SQL Server, la métrique ReplicaLag correspond au délai maximal des bases de données qui ont pris du retard, en secondes. Par exemple, si vous avez deux bases de données qui ont un délai de 5 secondes et 10 secondes, respectivement, alors ReplicaLag est de 10 secondes. La métrique ReplicaLag renvoie la valeur de la requête suivante. Exécutez la requête sur l'instance principale.

select max(secondary_lag_seconds) max_lag  from sys.dm_hadr_database_replica_states;

6.    Après avoir lancé la création d'un réplica en lecture, un instantané est pris à partir de l'instance principale, puis restauré pour créer une instance de réplica en lecture. Les journaux des transactions sont rejoués pour synchroniser les données avec l'instance principale. Cependant, après la création d'une nouvelle instance, celle-ci subit un chargement différé, ce qui entraîne un délai de réplica. Ceci est un comportement attendu. Pour minimiser l'effet du chargement différé, utilisez un stockage de type IO1 pendant la création du réplica en lecture, puis reconvertissez-le en GP2, si nécessaire.

7.    Exécutez les transactions par lots sur l'instance principale. Cela permet d'éviter d'exécuter de longues transactions et de maintenir la taille du fichier journal des transactions à un niveau minimal. Ne redémarrez pas l'instance de réplica à moins que cela ne soit nécessaire lors d'un délai de réplica élevé, car cela retarde encore la relecture des journaux de transactions.

8.    La modification de la classe d'instance sur l'instance principale ou de réplica peut provoquer un délai de réplica temporaire. C'est un comportement attendu car les journaux sont traités à partir de l'instance principale.

La modification du type ou de la taille de stockage a un impact plus long sur le délai de réplica jusqu'à ce que l'optimisation du stockage soit terminée. Il n'est pas possible de savoir quel pourcentage de l'optimisation du stockage est terminé sur les instances RDS.

9.    Si le réplica en lecture atteint l'état de stockage plein, les journaux de transaction de l'instance principale ne sont pas traités et le délai de réplica augmente.

Si vous pensez que l'espace de stockage est dû à TempDB ou à des tables temporaires, redémarrez l'instance de réplica pour libérer temporairement de l'espace.

10.    Si le délai de réplica ne progresse pas, vérifiez l'état des bases de données utilisateur sur l'instance de réplica. Pour rejouer les journaux, l'état de la base de données doit être En ligne.

Soyez conscient des points suivants :

• Les bases de données nouvellement créées ne sont pas incluses dans le calcul du délai tant qu'elles ne sont pas accessibles sur le réplica en lecture.
• ReplicaLag renvoie -1 si RDS ne peut pas déterminer le délai, par exemple pendant la configuration du réplica, ou lorsque le réplica lu est en état d'erreur.

---

Informations connexes

Utilisation de réplicas en lecture pour Microsoft SQL Server dans Amazon RDS