Comment résoudre le retard de réplication dans mon instance de base de données Amazon RDS pour PostgreSQL ?

Brève description

Lorsque les réplicas en lecture RDS pour PostgreSQL prennent du retard par rapport à l'instance principale, un retard de réplication peut survenir.

Le réplica en lecture utilise la réplication en continu native de PostgreSQL pour maintenir la synchronisation. Le récepteur Write Ahead Log (WAL) du réplica en lecture demande les données WAL à l'instance principale. Lorsque l'expéditeur WAL de l'instance principale ne trouve pas les données WAL demandées, il envoie une erreur à l'instance secondaire. Puis, RDS pour PostgreSQL essaie de récupérer les données WAL archivées à partir d'Amazon Simple Storage Service (Amazon S3). Si vous supprimez le WAL de l'instance principale, la réplication ne pourra pas reprendre, car Amazon S3 ne prend pas en charge la restauration de réplicas interrégionaux.

Pour plus d'informations, consultez la section Utilisation de réplicas en lecture pour Amazon RDS pour PostgreSQL.

Remarque : la résolution suivante concerne les problèmes de réplication en continu. Pour plus d'informations sur la réplication logique, consultez la section Comment utiliser la réplication logique pour répliquer des tables entre mes instances de bases de données Amazon RDS pour PostgreSQL ?

Résolution

Identifier les problèmes de réplication

Pour identifier votre problème de réplication spécifique, examinez les métriques suivantes :

• ReplicaLag dans Amazon CloudWatch : Cette métrique mesure le temps en secondes pendant lequel un réplica en lecture est en retard par rapport à l'instance de base de données source.
• État de réplication dans la console Amazon Aurora et RDS : Si la réplication s'arrête, ce champ devient Erreur.
• oldestreplicationslotlag dans PostgreSQL version 14.1 et versions ultérieures lorsque vous utilisez des emplacements de réplication : Cette métrique indique la quantité de données WAL en octets que le réplica le plus retardé n'a pas reçues.

Vous pouvez également consulter les paramètres qui contrôlent la réplication PostgreSQL.

Lorsque le retard de réplication augmente, vous pouvez recevoir des messages d'événement similaires aux suivants :

« La réplication en continu s'est arrêtée. » Cette erreur signifie que la réplication en continu entre l'instance principale et l'instance de réplication a échoué. La réplication passe en mode relecture à partir de l'archive d'Amazon S3.

« La réplication en continu a été arrêtée. » Cette erreur se produit après un arrêt de la réplication pendant 30 jours consécutifs. Amazon RDS arrête la réplication pour éviter une utilisation excessive de l'espace de stockage.

Remarque : une fois la réplication arrêtée, l'instance de réplica en lecture est disponible, mais vous ne pouvez pas reprendre la réplication. Pour revenir à cet état, recréez le réplica en lecture.

Vérifier les incohérences de configuration

Il est recommandé de configurer vos réplicas en lecture afin qu’ils correspondent ou dépassent les spécifications de l'instance principale. Une classe d'instance plus petite ou un type de stockage différent peuvent entraîner un retard. Le réplica doit traiter la même charge de travail d'écriture que le réplica principal et traiter également les requêtes de lecture. Modifiez votre instance de réplica en lecture, si nécessaire.

Vérifiez la charge d'écriture de l'instance principale et la charge de lecture du réplica.

Les opérations d'écriture sur l'instance principale créent de nombreux fichiers WAL. Pour identifier la pression d'écriture, surveillez les métriques CloudWatch et les valeurs de surveillance améliorée suivantes :

• TransactionLogsDiskUsage
• TransactionLogsGeneration
• WriteIOPS
• WriteThroughput
• WriteLatency

Vérifiez l'absence de goulots d'étranglement de débit pour le type de classe d’instance de base de données. Pour éviter les problèmes, répartissez les activités d'écriture sur plusieurs transactions. Vous pouvez configurer des alarmes CloudWatch pour WriteLatency et WriteIOPS afin d'identifier les charges élevées en écriture sur l'instance source.

Un taux d’activité de lecture élevé sur les réplicas peut ralentir la lecture des fichiers WAL. Pour analyser une charge de travail élevée et vérifier la présence de conflits de ressources, utilisez les métriques CloudWatch ou la surveillance améliorée sur l'instance de réplica. Si nécessaire, répartissez le trafic de lecture sur plusieurs réplicas en lecture.

Verrous de table de surveillance

RDS pour PostgreSQL traite un verrou Accès exclusif lorsque vous exécutez ces commandes sur l'instance principale : DROP TABLE, TRUNCATE, REINDEX, VACUUM FULL et REFRESH MATERIALIZED VIEW sans CONCURRENTLY. Pour plus d'informations, consultez la page Verrouillage explicite sur le site Web de PostgreSQL.

Le verrou Accès exclusif empêche l'accès à la table à partir d'autres transactions pendant la durée de blocage du verrouillage. La table reste verrouillée jusqu'à la fin de la transaction. WAL enregistre l'activité de verrouillage, et le réplica en lecture relit et bloque l'activité. Plus la table reste longtemps sous un verrou Accès exclusif, plus la latence de réplication est longue.

Pour éviter ce problème, il est recommandé d'interroger régulièrement les tables du catalogue pg_locks et pg_stat_activity.

Pour surveiller les verrous, exécutez la commande suivante :

SELECT pid, usename, pg_blocking_pids(pid) AS blocked_by, QUERY AS blocked_query FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;

La sortie affiche des informations sur les requêtes bloquées et leurs processus bloqués.

Vérifier les paramètres de réplication RDS pour PostgreSQL

Pour éviter les problèmes de réplication, passez en revue les paramètres qui contrôlent la réplication RDS pour PostgreSQL. Mettez à jour les valeurs des paramètres, si nécessaire.

Pour tenir compte du nombre total de connexions de réplication, vous pouvez configurer max_replication_slots. La valeur par défaut varie en fonction de la classe d'instance. Cette valeur doit être égale ou supérieure au nombre total de réplicas.

Les paramètres max_standby_streaming_delay et max_standby_archive_delay sur l'instance de réplica peuvent aider à effectuer des requêtes de lecture de longue durée. Si les requêtes de lecture exécutées sur le réplica modifient les données source, ces paramètres interrompent la relecture WAL. Si vous définissez la valeur sur -1, la rediffusion WAL attend la fin de la requête de lecture. Cependant, cette pause peut augmenter la latence de réplication indéfiniment et entraîner une consommation de stockage élevée à la source en raison de l'accumulation de WAL.

Pour assurer la stabilité de la réplication, RDS pour PostgreSQL gère automatiquement plusieurs paramètres : max_connections, max_worker_processes, max_wal_senders, max_prepared_transactions et max_locks_per_transaction. Sur votre réplica, RDS pour PostgreSQL définit ces paramètres afin qu'ils correspondent ou dépassent les valeurs de l'instance principale.

Le paramètre hot_standby_feedback permet aux réplicas de signaler les conflits de requêtes à l'instance principale. RDS pour PostgreSQL désactive ce paramètre par défaut. Si vous activez le paramètre, les tables de l'instance principale peuvent subir un gonflement. Si le message d'erreur suivant s'affiche, utilisez le paramètre hot_standby_feedback :

« ERROR: canceling statement due to conflict with recover. Detail: User query might have needed to see row versions that must be removed »

Examinez les bonnes pratiques relatives à la réplication RDS pour PostgreSQL et les réplicas en lecture interrégionaux

Vous pouvez également subir une latence de réplication pour les raisons suivantes :

• Interruptions du réseau entre les instances
• Fichiers WAL endommagés ou manquants
• Opérations de mise à l’échelle des instances
• Activités de maintenance
• Périodes sans transactions
  Remarque : pour plus d'informations, consultez la section Utilisation de réplicas en lecture pour Amazon RDS pour PostgreSQL.

Pour plus d'informations sur ces scénarios, consultez les sections Bonnes pratiques relatives à la réplication Amazon RDS PostgreSQL et Bonnes pratiques relatives aux réplicas en lecture interrégionaux Amazon RDS pour PostgreSQL.

Surveiller les transactions

Pour vérifier les transactions actives sur l'instance principale susceptibles d'affecter la réplication, exécutez la commande suivante :

SELECT datname, pid, usename, client_addr, backend_start, xact_start, current_timestamp - xact_start AS xact_runtime, state, backend_xmin FROM pg_stat_activity WHERE state='active' OR state='idle in transaction';

La sortie indique les transactions en cours et leur durée. Les transactions de longue durée peuvent affecter les performances de réplication.

Pour arrêter une requête problématique, exécutez la commande suivante :

SELECT pg_terminate_backend(PID);

Remarque : remplacez PID par le numéro d'identification du processus de la requête que vous souhaitez arrêter.

Informations connexes

Réplication sur le site Web de PostgreSQL

Utilisation de la réplication logique pour répliquer Amazon RDS pour PostgreSQL en mode géré et Amazon Aurora vers PostgreSQL en mode autogéré