Comment résoudre les problèmes de réplication logique d'un cluster de bases de données source Aurora compatible avec PostgreSQL ?

Résolution

Configuration des paramètres de réplication

Avant de résoudre les problèmes de réplication logique, configurez les paramètres suivants pour le groupe de paramètres de votre cluster de bases de données :

• Définissez la valeur de rds.logical_replication sur 1 pour activer la réplication logique sur votre cluster de bases de données.
• Définissez une valeur pour max_replication_slots qui inclut suffisamment de slots pour le nombre d'abonnements prévu et pour des processus de synchronisation de tables supplémentaires.
• Définissez max_wal_senders sur une valeur qui prend en charge votre quota max_replication_slots et vos réplicas physiques actuels.
• Définissez max_logical_replication_workers sur une valeur qui prend en charge votre nombre d’abonnements et le nombre de workers supplémentaires dont le système de réplication a besoin pour la synchronisation des tables.
• Définissez max_worker_processes sur une valeur supérieure d'au moins un à la valeur de max_logical_replication_workers. Par exemple, si max_logical_replication_workers est 25, définissez max_worker_processes sur 26.
• Si la copie des données est lente, augmentez la valeur de max_sync_workers_per_subscription pour contrôler le nombre de workers de synchronisation qui traitent la configuration de l'abonnement et les ajouts de nouvelles tables.

Important : pour appliquer les modifications précédentes, vous devez redémarrer votre cluster de bases de données Aurora compatible PostgreSQL.

Vérifier la configuration des publications et des abonnements

Après avoir configuré les paramètres de réplication logique, vérifiez que vous avez correctement configuré les publications et les abonnements. Assurez-vous que la publication inclut toutes les tables prévues, que les paramètres d'abonnement sont corrects et que l'utilisateur de réplication dispose des autorisations appropriées.

Connectez-vous à votre base de données source, puis exécutez les commandes suivantes.

Pour vérifier la configuration de votre publication, exécutez les commandes suivantes :

SELECT * FROM pg_publication;
SELECT * FROM pg_publication_tables;

Pour vérifier la configuration de votre abonnement, exécutez les commandes suivantes :

SELECT * FROM pg_subscription;
SELECT * FROM pg_subscription_rel;

Vérifier que les slots de réplication sont actifs

Connectez-vous à votre base de données source, puis exécutez la commande suivante :

SELECT slot_name, plugin, slot_type, active, restart_lsn,
       confirmed_flush_lsn, pg_current_wal_lsn(),
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag
FROM pg_replication_slots;

Si les slots sont inactifs ou présentent un retard excessif, passez en revue les workers de réplication pour résoudre le problème.

Vérifier que les workers de réplication sont actifs

Connectez-vous à votre base de données cible, puis exécutez la commande suivante :

SELECT pid, state, query, wait_event, backend_type
FROM pg_stat_activity
WHERE backend_type LIKE 'logical replication%';

S'il n'existe aucun worker de réplication, redémarrez votre abonnement.

Pour désactiver votre abonnement, exécutez la commande suivante :

ALTER SUBSCRIPTION subscription_name DISABLE;

Pour activer votre abonnement, exécutez la commande suivante :

ALTER SUBSCRIPTION subscription_name ENABLE;

S'il n'existe toujours pas de workers de réplication après le redémarrage de l'abonnement, vérifiez la présence de messages d'erreur dans les journaux d'erreurs de PostgreSQL.

Surveiller la progression et la latence de la réplication

Votre réplication peut être retardée en raison d'un volume de transactions élevé et de transactions importantes sur la publication. Des contraintes peuvent également avoir été définies pour la publication ou l'abonnement.

Pour déterminer si la réplication s'est arrêtée ou est lente, surveillez la progression de la réplication pendant quelques intervalles.

Connectez-vous à votre cluster de bases de données, puis exécutez les commandes suivantes.

Pour vérifier la progression de la réplication de votre publication, exécutez la commande suivante :

SELECT slot_name,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag,
       active
FROM pg_replication_slots
WHERE slot_type = 'logical';

Pour vérifier la progression de la réplication de votre abonnement, exécutez la commande suivante :

SELECT subname, pid, received_lsn, latest_end_lsn,
       pg_size_pretty(pg_wal_lsn_diff(latest_end_lsn, received_lsn)) AS lag
FROM pg_stat_subscription;

Pour minimiser la latence de réplication, surveillez le cache d'écriture. Si la taille du cache n'est pas suffisante pour vos charges de travail, vous pouvez modifier manuellement la valeur de rds.logical_wal_cache. Pour plus d'informations, consultez la section Réduire la latence de réplication jusqu'à 17 fois grâce au nouveau cache d'écriture pour Aurora PostgreSQL.

Surveiller les contraintes de ressources

Pour résoudre les problèmes de ressources qui pèsent sur le diffuseur de publication et l'abonné, activez la surveillance améliorée, et surveillez CPUUtilization, FreeableMemory, SwapUsage et NetworkThroughput. Configurez des alarmes Amazon CloudWatch pour être averti en cas de problèmes de réplication.

Pour plus d’informations, consultez la section Comment puis-je identifier et résoudre les problèmes de performance et de lenteur d’exécution des requêtes dans mon instance Amazon RDS pour PostgreSQL ou Aurora compatible avec PostgreSQL ?

Identifier les incohérences entre les schémas et résoudre les incohérences de données

Connectez-vous à votre base de données source et à votre base de données cible. Vérifiez ensuite que les tables répliquées contiennent des colonnes et que les types de données sont compatibles. Assurez-vous également que les clés primaires et les contraintes uniques sont cohérentes.

Pour activer votre abonnement, exécutez la commande suivante :

ALTER SUBSCRIPTION subscription_name ENABLE;

Pour comparer les définitions de tables, exécutez la commande suivante sur les deux bases de données :

SELECT column_name, data_type, character_maximum_length
FROM information_schema.columns
WHERE table_name = 'your_table_name'
ORDER BY ordinal_position;

Remarque : remplacez your_table_name par le nom de votre table.

Résoudre les conflits

La réplication logique native de PostgreSQL ne peut pas détecter les conflits de données provenant de plusieurs diffuseurs de publication ni les modifications répliquées qui entrent en conflit avec les données que vous avez modifiées localement. S'il existe une ligne actuelle avec la même clé, Aurora applique la mise à jour et l'insertion échoue.

Pour identifier la cause du conflit, consultez les journaux PostgreSQL.

L'exemple de journal suivant montre que la réplication a échoué, car elle a tenté d'insérer un enregistrement avec un ID d'actif qui existe déjà dans la base de données cible :

ERROR: 23505: duplicate key value violates unique constraint "asset_pkey"
DETAIL: Key (asset_id)=(7) already exists.
CONTEXT: processing remote data for replication origin "pg_32796" during message type "INSERT" for replication target relation "public.asset" in transaction 315434, finished at 0/6A12458

L'origine de réplication est pg_32796 et se termine au numéro de séquence logique (LSN) 0/6A12458.

Pour corriger manuellement les données, vous pouvez arrêter la réplication en cas de conflit ou configurer l'abonnement à l'aide de l'option disable_on_error.

Vous pouvez également consulter les données relatives à la source et à la cible pour déterminer si vous pouvez ignorer le LSN à l'origine du conflit. Utilisez ensuite la fonction pg_replication_origin_advance() pour ignorer le LSN à l'origine du conflit. Pour plus d'informations, consultez la page pg_replication_origin_advance (node_name text, lsn pg_lsn) sur le site Web de PostgreSQL.

Remarque : les versions 15 et ultérieures d’Aurora compatible avec PostgreSQL prennent en charge la fonction pg_replication_origin_advance().

Pour ignorer le LSN, procédez comme suit :

1. Exécutez la commande SQL suivante pour désactiver temporairement l'abonnement :

   ALTER SUBSCRIPTION subscription_name DISABLE;

   Remarque : si vous avez configuré l'abonnement à l'aide de l'option disable_on_error, l'abonnement se désactive automatiquement en cas d'erreur.

2. Utilisez la fonction pg_replication_origin_advance() suivante pour faire avancer l'origine vers Finish_LSN+1 :

   SELECT pg_replication_origin_advance('node_name','Finish_LSN+1'::pg_lsn);

   Remarque : remplacez node_name par le nom de votre nœud.

3. Exécutez la commande suivante pour activer l’abonnement :

   ALTER SUBSCRIPTION subscription-name ENABLE;

   Remarque : remplacez subscription-name par le nom de votre abonnement.

Pour résoudre plusieurs incohérences de données, vous devrez peut-être nettoyer la table cible et reconfigurer la publication et l'abonnement.

Informations connexes

Réplication avec Amazon Aurora PostgreSQL

Réplication logique de PostgreSQL sur le site Web de PostgreSQL

Configuration de la réplication logique pour votre cluster de bases de données Aurora PostgreSQL

Surveillance des métriques Amazon Aurora avec Amazon CloudWatch