Surveiller la réplication pglogical dans AlloyDB Omni

Cette page explique comment surveiller et dépanner les implémentations pglogical en vérifiant et en validant les bases de données du fournisseur et des abonnés.

Les informations de cette page ne s'appliquent qu'aux déploiements AlloyDB Omni sur un seul serveur. Il ne s'applique pas aux déploiements AlloyDB Omni basés sur Kubernetes.

Avant de commencer

Avant de commencer à surveiller et à résoudre les problèmes d'implémentation de pglogical, vérifiez les bases de données du fournisseur et des abonnés, comprenez l'implémentation de pglogical et vérifiez sa configuration.

Pour en savoir plus sur l'extension pglogical, consultez À propos de pglogical.

Pour en savoir plus sur la réplication de données à l'aide de pglogical, consultez Répliquer des données entre Google Cloud AlloyDB et AlloyDB Omni et Répliquer des données entre AlloyDB Omni et d'autres bases de données.

Vérifier les paramètres pglogical, de réplication et des paramètres de AlloyDB Omni

Un certain nombre de paramètres de configuration affectent le fonctionnement de l'extension pglogical. Vous pouvez le vérifier dans les bases de données du fournisseur et des abonnés. Notez que les valeurs des paramètres peuvent varier.

1. Afficher le paramètre actuel des paramètres spécifiques à pglogical:

   SELECT name,
       setting,
       source,
       short_desc
   FROM pg_catalog.pg_settings
   WHERE name LIKE '%pglogical%' AND name NOT LIKE '%alloydb%'
   ORDER BY category, name;
   

2. Afficher d'autres paramètres liés à la réplication logique:

   SELECT name,
       setting,
       source,
       short_desc
   FROM pg_catalog.pg_settings
   WHERE name IN ('wal_level',
                'max_worker_processes',
                'max_replication_slots',
                'max_wal_senders',
                'shared_preload_libraries',
                'track_commit_timestamp')
   ORDER BY name;
   

3. Afficher les paramètres spécifiques à AlloyDB Omni:

   SELECT name,
       setting,
       source,
       short_desc
   FROM pg_catalog.pg_settings
   WHERE name LIKE '%alloydb%'
   ORDER BY category, name;
   

Remarque :Nous vous recommandons de vérifier les paramètres des paramètres sur tous les nœuds.

Répertorier les nœuds dans la configuration

1. Répertoriez les nœuds locaux et distants dans la configuration de réplication pglogical:

   SELECT node_id,
       if_nodeid AS node_id,
       if_name AS node_name,
       if_dsn AS dsn
   FROM pglogical.node_interface
   LEFT JOIN pglogical.local_node ON (node_id = if_nodeid AND node_local_interface = if_id)
   ORDER BY node_name;
   

   Si la colonne node_id est NOT NULL, il s'agit du nœud local.

2. Examinez les informations dsn en détail. Toute information de chaîne de connexion incorrecte ou obsolète peut entraîner des échecs de réplication. Pour en savoir plus sur le dépannage de dsn, consultez Résoudre les problèmes de réplication des abonnements.

Vérifier l'état de l'abonnement et le point de réplication de la table

L'état de l'abonnement est toujours vérifié dans la base de données des abonnés. L'abonnement affiche un état initializing ou replicating. Il affiche également un état down. Pour en savoir plus sur l'état down, consultez Résoudre les problèmes de réplication des abonnements.

1. Répertoriez les abonnements, leur état et leurs paramètres actuels dans la base de données actuelle:

   SELECT s.sub_name AS subscription_name,
       n1.node_name AS origin_name,
       n2.node_name AS target_name,
       x.status,
       sub_slot_name,
       sub_replication_sets,
       sub_forward_origins,
       sub_apply_delay,
       sub_force_text_transfer,
       sub_enabled AS enabled
   FROM pglogical.subscription s,
       (SELECT subscription_name, status FROM pglogical.show_subscription_status()) AS x,
       pglogical.node n1,
       pglogical.node n2
   WHERE s.sub_origin = n1.node_id
   AND s.sub_target = n2.node_id
   AND s.sub_name = x.subscription_name
   ORDER BY s.sub_name;
   

   Le résultat ressemble à ce qui suit :

   -[ RECORD 1 ]-----------+--------------------------------------
   subscription_id         | 3072625608
   subscription_name       | test_sub_1
   origin_name             | provider
   target_name             | subscriber
   status                  | replicating
   sub_slot_name           | pgl_my_test_db_provider_test_sub_1
   sub_replication_sets    | {default,default_insert_only,ddl_sql}
   sub_forward_origins     | {all}
   sub_apply_delay         | 00:00:00
   sub_force_text_transfer | f
   enabled                 | t
   my_test_db=#
   

2. Listez les tables actuellement répliquées et leur numéro de séquence de journal (LSN) actuel par abonnement:

   SELECT sync_nspname||'.'||sync_relname AS table_name,
       sync_status,
       sync_statuslsn
   FROM pglogical.local_sync_status
   WHERE sync_relname IS NOT NULL
   ORDER BY table_name;
   

   Le résultat ressemble à ce qui suit :

     table_name      | sync_status | sync_statuslsn 
   ---------------------+-------------+----------------
   public.test_table_1 | r           | 0/B891BC0
   (1 row)
   
   my_test_db=#
   

   La colonne sync_statuslsn indique à quel LSN la table est synchronisée. Vous pouvez le comparer au LSN de la base de données du fournisseur pour évaluer le décalage de réplication.

3. Vérifiez l'état de la réplication d'une table spécifique:

   SELECT * FROM pglogical.show_subscription_table('test_sub_1','test_table_1');
   

Vérifier les détails du jeu de réplication auprès du fournisseur

1. Répertoriez les ensembles de réplication actuels dans la base de données du fournisseur et vérifiez les éléments qui sont répliqués:

   SELECT set_name,
       node_name,
       replicate_insert,
       replicate_update,
       replicate_delete,
       replicate_truncate
   FROM pglogical.replication_set
   JOIN pglogical.node ON set_nodeid = node_id
   ORDER BY set_name, node_name;
   

2. Lister les tables et les séquences actuellement répliquées:

   -- Table details:
   SELECT set_name,
       set_reloid AS table_name,
       set_att_list,
       set_row_filter
   FROM pglogical.replication_set
   NATURAL JOIN pglogical.replication_set_table
   ORDER BY set_name, table_name;
   
   -- Sequence details:
   SELECT set_name,
       set_seqoid AS sequence_name
   FROM pglogical.replication_set
   NATURAL JOIN pglogical.replication_set_seq
   ORDER BY set_name, sequence_name;
   

Vérifier les informations de réplication et le décalage de l'emplacement chez le fournisseur

1. Vérifiez l'état de chaque abonné en générant la vue pg_stat_replication dans la base de données du fournisseur:

   SELECT application_name,
       state,
       sync_state,
       client_addr,
       client_hostname,
       pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) AS sent_lag,
       pg_wal_lsn_diff(sent_lsn,flush_lsn) AS receiving_lag,
       pg_wal_lsn_diff(flush_lsn,replay_lsn) AS replay_lag,
       pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) AS total_lag,
       now()-reply_time AS reply_delay
   FROM pg_stat_replication
   ORDER BY client_hostname;
   

   Le résultat ressemble à ce qui suit :

   -[ RECORD 1 ]----+------------------------------
   application_name | test_sub_1
   state            | streaming
   sync_state       | async
   client_addr      | 10.45.0.80
   client_hostname  | 
   sent_lag         | 0
   receiving_lag    | 0
   replay_lag       | 0
   total_lag        | 0
   reply_delay      | 00:00:26.203433
   
   my_test_db=#
   

   Attention :Assurez-vous de n'examiner que les entrées pglogical. Correlez la colonne application_name au nom de l'abonnement dans la base de données des abonnés.

2. Notez la colonne reply_delay, qui indique l'heure à laquelle elle a reçu la dernière mise à jour de la base de données des abonnés.

3. Surveillez le délai de réplication de l'emplacement de réplication sur le fournisseur, car pglogical crée des emplacements de réplication dans la base de données du fournisseur:

   SELECT slot_name,
       slot_type,
       database,
       active,
       COALESCE(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn),0) AS restart_lag,
       COALESCE(pg_wal_lsn_diff(pg_current_wal_lsn(),confirmed_flush_lsn),0) AS confirmed_flush_lag
   FROM pg_replication_slots
   WHERE plugin like '%pglogical%'
   ORDER BY slot_name;
   

   Le résultat ressemble à ce qui suit :

   -[ RECORD 1 ]-------+-----------------------------------
   slot_name           | pgl_my_test_db_provider_test_sub_1
   slot_type           | logical
   database            | my_test_db
   active              | t
   restart_lag         | 56
   confirmed_flush_lag | 0
   
   my_test_db=# 
   

   Important :D'autres outils et extensions peuvent créer des créneaux de réplication. Vous devez vous assurer que l'emplacement de réplication examiné correspond à un ensemble de réplication pglogical. Cette opération est gérée par le plug-in, tel que le prédicat de requête '%pglogical%'.

Résoudre les problèmes de réplication des abonnements

L'abonnement vérifié dans la base de données des abonnés doit afficher un état replicating ou initializing si l'abonnement a été créé récemment. Si l'état est down, un problème est survenu.

L'état down s'affiche généralement après une tentative de démarrage de la réplication, qui a échoué. Cela est dû à des problèmes de connectivité causés par le paramètre dsn ou à des autorisations de base de données manquantes, qui se trouvent soit chez le fournisseur, soit chez l'abonné.

Utilisez l'explorateur de journaux et inspectez les fichiers journaux PostgreSQL dans Google Cloud lorsqueGoogle Cloud AlloyDB est l'un des points de terminaison pour obtenir des informations supplémentaires susceptibles d'indiquer la cause du problème. Les fichiers journaux fournissent des informations détaillées sur le problème, y compris des informations spécifiques sur les autorisations manquantes.

1. Vérifiez le journal PostgreSQL sur votre serveur AlloyDB Omni:

   Docker

   docker logs CONTAINER_NAME

   Remplacez CONTAINER_NAME par le nom que vous avez attribué au conteneur AlloyDB Omni lorsque vous l'avez installé.

   Podman

   podman logs CONTAINER_NAME

   Remplacez CONTAINER_NAME par le nom que vous avez attribué au conteneur AlloyDB Omni lorsque vous l'avez installé.

2. Résolvez les problèmes liés au paramètre dsn et assurez-vous que la connectivité réseau n'est pas la source du problème:

   1. Copiez la chaîne de connexion dsn, puis essayez une connexion manuelle à l'aide de psql et de la même chaîne. Si la session psql ne parvient pas à se connecter, cela indique les éléments suivants :
      • Un problème de réseau.
      • Adresse IP, nom d'utilisateur ou mot de passe incorrects
      • Un pare-feu bloquant la connectivité.
      • Le fichier pg_hba.conf de l'autre cluster n'est pas configuré correctement.

3. Resynchronisez une table si vous ne souhaitez pas supprimer et recréer l'abonnement après avoir pris des mesures correctives:

   SELECT pglogical.alter_subscription_resynchronize_table(subscription_name := 'test_sub_1',relation := 'table_name');
   

   Attention :Cette fonction tronque le tableau.

4. Vous pouvez également résilier votre abonnement et le recréer:

   SELECT pglogical.drop_subscription(subscription_name := 'test_sub_1');
   

Étape suivante

• Passage et basculement avec réplication pglogical
• Repliquer des données entre Google Cloud AlloyDB et AlloyDB Omni
• Répliquer des données entre AlloyDB Omni et d'autres bases de données