Surveiller la réplication pglogical dans AlloyDB Omni

Sélectionnez une version de la documentation : Actuelle (16.8.0)

• Actuelle (16.8.0)
• 16.8.0
• 16.3.0
• 15.12.0
• 15.7.1
• 15.7.0
• 15.5.5
• 15.5.4
• 15.5.2

Cette page explique comment surveiller et résoudre les problèmes d'implémentation de pglogical en vérifiant et en validant les bases de données des fournisseurs et des abonnés.

Les informations de cette page ne s'appliquent qu'à AlloyDB Omni pour les conteneurs. Il ne s'applique pas à AlloyDB Omni pour Kubernetes.

Avant de commencer

Avant de commencer à surveiller et à résoudre les problèmes liés aux implémentations pglogical, vérifiez les bases de données des fournisseurs et des abonnés, comprenez l'implémentation pglogical et validez sa configuration.

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

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

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

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

1. Affichez 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. Affichez les 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 sur tous les nœuds.

Lister les nœuds de 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 en détail les informations de dsn. Toute information incorrecte ou obsolète concernant la chaîne de connexion 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 l'état initializing ou replicating. Il affiche également l'é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 actuel et leurs paramètres 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 le numéro de séquence du journal auquel la table est synchronisée. Vous pouvez comparer cette valeur au numéro de séquence du journal (LSN) dans la base de données du fournisseur pour évaluer le décalage de réplication.

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

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

Vérifier les détails de l'ensemble de réplication sur le fournisseur

1. Répertoriez les ensembles de réplication actuels dans la base de données du fournisseur et vérifiez les éléments 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 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 des emplacements sur 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. Associez 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 la dernière mise à jour a été reçue 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 sur 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 emplacements de réplication. Vous devez vous assurer que l'emplacement de réplication examiné correspond à un ensemble de réplication pglogical. Cela est couvert par le plug-in, comme le prédicat de requête '%pglogical%'.

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

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

L'état down s'affiche généralement après une tentative d'initialisation 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, au niveau du fournisseur ou de 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 qui pourraient indiquer la cause du problème. Les fichiers journaux fournissent des détails sur le problème, y compris des informations spécifiques sur les autorisations manquantes.

1. Consultez 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 lors de son installation.

   Podman

   podman logs CONTAINER_NAME

   Remplacez CONTAINER_NAME par le nom que vous avez attribué au conteneur AlloyDB Omni lors de son installation.

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

   1. Copiez la chaîne de connexion dsn et essayez une connexion manuelle à l'aide de psql et de la même chaîne. Si la session psql ne peut pas se connecter, cela indique les éléments suivants :
      • 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 la table.

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

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

Étapes suivantes

• Basculement et reprise après sinistre avec la réplication pglogical
• Répliquer 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