Pourquoi y a-t-il des retards de réplication et des erreurs dans l’instance de base de données RDS for PostgreSQL ?

Brève description

Vous pouvez faire évoluer les lectures de votre instance Amazon RDS for PostgreSQL DB en ajoutant des réplicas en lecture à l'instance. RDS for PostgreSQL utilise la réplication en continu native PostgreSQL pour créer une copie en lecture seule d'une instance de base de données source. Cette instance de base de données de réplica en lecture est une réplique physique créée de manière asynchrone de l'instance de base de données source. Cela signifie que, parfois, le réplica ne peut pas suivre le rythme de l'instance principale de la base de données. Un retard de réplication peut alors se produire. La base de données de réplica est créée par une connexion spéciale qui transmet les données du journal d'écriture anticipée (WAL) de l'instance de base de données source au réplica en lecture. Par conséquent, le réplica en lecture vérifie les journaux WAL pour répliquer les modifications apportées sur l'instance principale. Lorsque le réplica en lecture ne trouve pas le WAL sur l'instance principale, le réplica en lecture est récupéré à partir des données WAL archivées dans Amazon Simple Storage Service (Amazon S3). Pour plus d'informations, consultez Fonctionnement de la réplication en continu pour différentes versions de RDS for PostgreSQL.

Vous pouvez surveiller le retard de réplication dans Amazon CloudWatch en affichant la métrique Amazon RDS ReplicaLag. Cette métrique indique le retard d'un réplica en lecture par rapport à son instance de base de données source. Amazon RDS surveille l'état de réplication du réplica en lecture. Ensuite, il met à jour le champ Replication State (État de la réplication) dans la console Amazon RDS sur Error (Erreur) si la réplication s'arrête pour une raison quelconque. La métrique ReplicaLag indique dans quelle mesure un réplica en lecture suit le rythme de l'instance de base de données source et la quantité de latence entre l'instance de base de données source et une instance de lecture spécifique.

Solution

L'une des erreurs suivantes peut s'afficher dans les journaux d'erreurs RDS for PostgreSQL lorsque le retard de réplica augmente :

• Streaming replication has stopped (La réplication en continu s'est arrêtée) : cette erreur s'affiche lorsque la réplication en continu entre l'instance principale et l'instance de réplica s’arrête. Dans ce cas, la réplication commence à être relue à partir de l'emplacement d'archivage dans Amazon S3, ce qui entraîne une augmentation supplémentaire du retard de réplica.
• Streaming replication has been terminated (La réplication en continu a été terminée) : cette erreur s'affiche lorsque la réplication est arrêtée pendant plus de 30 jours consécutifs, soit manuellement, soit en raison d'une erreur de réplication. Dans ce cas, Amazon RDS interrompt la réplication entre l'instance de base de données principale et tous les réplicas en lecture afin d'éviter des exigences de stockage accrues sur l'instance principale et des temps de basculement plus longs.

L'instance de réplica en lecture est disponible même après l'arrêt de la réplication. Cependant, la réplication ne peut pas être reprise car les journaux de transactions requis par le réplica en lecture sont supprimés de l'instance principale après l'interruption de la réplication.

Les raisons les plus courantes de l'augmentation du retard de réplica sont les suivantes :

• Différences de configuration entre l’instance principale et l’instance de réplica
• Charge de travail d'écriture importante sur l'instance principale
• Transactions en cours d’exécution pendant une longue période
• Verrou exclusif sur les tables de l'instance principale
• Fichier WAL corrompu ou manquant
• Problèmes de réseau
• Paramétrage incorrect
• Absence de transactions

Différences de configuration entre l'instance principale et le réplica en lecture

Des configurations d'instance de réplica incorrectes peuvent affecter les performances de réplication. Le réplica en lecture gère une charge de travail d'écriture similaire à celle de l'instance source, ainsi que des requêtes de lecture supplémentaires. Par conséquent, utilisez des réplicas de classe d'instance et de type de stockage identiques ou supérieurs à ceux de l'instance source. Comme le réplica doit relire la même activité d'écriture que l'instance source, l'utilisation d'un réplica de classe d'instance inférieure peut entraîner une latence élevée pour le réplica et augmenter le retard de réplication. Les configurations de stockage incompatibles augmentent également le retard de réplication.

Charge de travail d'écriture importante sur l'instance principale

Une charge de travail d'écriture importante sur l'instance principale peut créer un afflux important de fichiers WAL. L'augmentation du nombre de fichiers WAL et la relecture de ces fichiers sur des réplicas en lecture peuvent ralentir les performances globales de réplication. Par conséquent, lorsque vous constatez une augmentation du retard de réplica, veillez à vérifier l'activité d'écriture sur l'instance principale. Vous pouvez utiliser les métriques CloudWatch ou Enhanced Monitoring pour analyser cette charge de travail. Affichez les valeurs de TransactionLogsDiskUsage, TransactionLogsGeneration, WriteIOPS, WriteThroughput et WriteLatency afin de déterminer si l'instance source est soumise à une charge de travail d'écriture importante. Vous pouvez également vérifier les goulots d'étranglement au niveau du débit. Chaque type d'instance possède son débit dédié. Pour plus d'informations, consultez Spécifications matérielles pour les classes d'instance de base de données.

Pour éviter ce problème, contrôlez et distribuez l'activité d'écriture de l'instance source. Au lieu d'effectuer plusieurs activités d'écriture en même temps, divisez votre tâche en petits paquets de tâches, puis distribuez ces paquets uniformément sur plusieurs transactions. Vous pouvez utiliser les alertes CloudWatch pour les métriques, telles que Writelatency et WriteIOPS, afin d'être averti des écritures lourdes sur l'instance source.

Transactions en cours d’exécution pendant une longue période

Les transactions actives qui s'exécutent pendant une longue période dans la base de données peuvent interférer avec le processus de réplication de WAL, ce qui augmente le retard de réplication. Par conséquent, veillez à surveiller l'exécution des transactions actives avec la vue pg_stat_activity de PostgreSQL.

Exécutez une requête sur l'instance principale similaire à la suivante afin de trouver l'ID du processus (PID) de la requête qui s'exécute depuis une longue période :

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';

Après avoir identifié le PID de la requête, vous pouvez choisir de mettre fin à la requête.

Exécutez une requête sur l'instance principale similaire à la suivante pour mettre fin à la requête :

SELECT pg_terminate_backend(PID);

Vous pouvez également choisir de réécrire ou régler la requête afin d'éviter les transactions qui s'exécutent pendant de longues périodes.

Verrou exclusif sur les tables de l'instance principale

Lorsque vous exécutez des commandes, telles que DROP TABLE, TRUNCATE, REINDEX, VACUUM FULL, REFRESH MATERIALIZED VIEW (sans CONCURRENTLY), sur l'instance principale, PostgreSQL traite un verrou Access Exclusive. Ce verrou empêche toutes les autres transactions d'accéder à la table pendant la durée de maintien du verrou. Généralement, la table reste verrouillée jusqu'à la fin de la transaction. Cette activité de verrouillage est enregistrée dans le WAL, puis relu et conservée par le réplica en lecture. Plus la table reste longtemps sous un verrou Access Exclusive, plus le délai de réplication est long.

Pour éviter ce problème, il est recommandé de surveiller les transactions en interrogeant régulièrement les tables du catalogue pg_locks et pg_stat_activity.

Exemple :

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

Fichier WAL corrompu ou manquant

Un fichier WAL corrompu ou manquant peut entraîner un retard de réplica. Dans ce cas, vous voyez une erreur dans les journaux PostgreSQL indiquant que le WAL ne peut pas être ouvert. Vous pouvez également voir l'erreur « Requested WAL segment XXX has already been removed » (Le segment WAL XXX demandé a déjà été supprimé).

Problèmes de réseau

Une interruption du réseau entre l'instance primaire et l'instance de réplica peut entraîner des problèmes de réplication en continu qui peuvent se traduire par un retard de réplica accru.

Paramétrage incorrect

La configuration incorrecte de certains paramètres personnalisés dans le groupe de paramètres de configuration du serveur peut entraîner une augmentation du retard de réplica. Voici certains des paramètres que vous devez configurer correctement :

• wal_keep_segments : ce paramètre spécifie le nombre de fichiers WAL que l'instance principale conserve dans le répertoire pg_wal. La valeur par défaut de ce paramètre est 32. Si ce paramètre n'est pas défini sur une valeur suffisamment élevée pour le déploiement, le réplica en lecture risque de prendre du retard, ce qui entraîne l'arrêt de la réplication en continu. Dans ce cas, RDS génère une erreur de réplication et commence la restauration sur le réplica en lecture en relisant les données de WAL archivées de l'instance principale à partir de S3. Ce processus de restauration se poursuit jusqu'à ce que le réplica en lecture puisse poursuivre la réplication.
  Remarque : dans PostgreSQL version 13, le paramètre wal_keep_segments est nommé wal_keep_size. Ce paramètre a le même objectif que wal_keep_segments. Toutefois, la valeur par défaut de ce paramètre est définie en Mo (2 048 Mo) plutôt qu'en nombre de fichiers.
• max_wal_senders : ce paramètre spécifie le nombre maximum de connexions que l'instance principale peut prendre en charge simultanément via le protocole de réplication en continu. La valeur par défaut de ce paramètre pour RDS for PostgreSQL 13 et versions postérieures est 20. Ce paramètre doit être défini sur une valeur légèrement supérieure au nombre réel de réplicas en lecture. Si ce paramètre est défini sur une valeur inférieure au nombre de réplicas en lecture, la réplication s'arrête.
• hot_standby_feedback : ce paramètre indique si l'instance de réplica envoie des retours à l'instance principale concernant les requêtes en cours d'exécution dans l'instance de réplica. En activant ce paramètre, vous créez le message d'erreur suivant au niveau de l'instance source et vous reportez l'opération VACUUM sur les tables associées, sauf si la requête de lecture dans l'instance de réplica est terminée. Par conséquent, une instance de réplica sur laquelle hot_standby_feedback est activé peut traiter des requêtes de longue durée. Cependant, ce paramètre peut gonfler les tables au niveau de l'instance source. Veillez à surveiller les requêtes de longue durée dans les instances de réplica afin d'éviter des problèmes graves tels que le manque de stockage et l’enveloppement d’ID de transaction dans l'instance principale.

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

• max_standby_streaming_delay/max_standby_archive_delay : vous pouvez activer des paramètres, tels que max_standby_archive_delay ou max_standby_streaming_delay sur l'instance de réplica pour exécuter des requêtes de lecture de longue durée. Ces paramètres pausent la relecture de WAL dans le réplica si les données source sont modifiées lorsque des requêtes de lecture sont exécutées sur le réplica. Une valeur de -1 pour ces paramètres permet à la relecture de WAL d'attendre la fin de la requête de lecture. Cependant, cette interruption augmente le retard de réplication indéfiniment et entraîne une consommation de stockage élevée à la source en raison de l'accumulation de WAL.

Absence de transactions

Si aucune transaction utilisateur n'a lieu sur l'instance de base de données source, le réplica en lecture PostgreSQL signale un retard de réplication pouvant aller jusqu'à cinq minutes.

---

Informations connexes

Utilisation de réplicas en lecture pour Amazon RDS for PostgreSQL

Documentation PostgreSQL relative à la configuration du serveur