pglogical-Replikation in AlloyDB Omni überwachen

Auf dieser Seite findest du Informationen zum Überwachen und Beheben von Problemen bei pglogical-Implementierungen durch Prüfen und Validieren der Anbieter- und Abonnentendatenbanken.

Die Informationen auf dieser Seite gelten nur für Bereitstellungen mit einem einzelnen Server von AlloyDB Omni. Sie gilt nicht für Kubernetes-basierte AlloyDB Omni-Bereitstellungen.

Hinweise

Bevor du mit der Überwachung und Fehlerbehebung von pglogical-Implementierungen beginnst, solltest du die Anbieter- und Abonnentendatenbanken prüfen, die pglogical-Implementierung kennenlernen und die Konfiguration überprüfen.

Weitere Informationen zur pglogical-Erweiterung finden Sie unter pglogical.

Informationen zur Datenreplizierung mit pglogical finden Sie unter Daten zwischen Google Cloud AlloyDB und AlloyDB Omni replizieren und Daten zwischen AlloyDB Omni und anderen Datenbanken replizieren.

pglogical-, Replikations- und AlloyDB Omni-Parametereinstellungen prüfen

Eine Reihe von Konfigurationsparametern wirkt sich auf die Funktion der pglogical-Erweiterung aus. Sie können diese in den Anbieter- und Abonnentendatenbanken prüfen. Die Parameterwerte können variieren.

1. Aktuelle Einstellung von pglogical-spezifischen Parametern anzeigen:

   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. Andere Parameter für die logische Replikation anzeigen:

   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. AlloyDB Omni-spezifische Parameter anzeigen:

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

Hinweis: Wir empfehlen, die Parametereinstellungen auf allen Knoten zu überprüfen.

Knoten in der Konfiguration auflisten

1. Fügen Sie in der pglogical-Replikationskonfiguration sowohl lokale als auch Remote-Knoten hinzu:

   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;
   

   Wenn die Spalte node_id NOT NULL ist, ist dies der lokale Knoten.

2. Sehen Sie sich die dsn-Informationen im Detail an. Falsche oder veraltete Informationen zum Verbindungsstring können zu Replikationsfehlern führen. Informationen zur Fehlerbehebung bei dsn finden Sie unter Fehlerbehebung bei der Aboreplikation.

Abostatus und Replikationspunkt der Tabelle prüfen

Der Abostatus wird immer anhand der Abonnentendatenbank überprüft. Das Abo hat den Status initializing oder replicating. Außerdem wird der Status down angezeigt. Weitere Informationen zum Status down finden Sie unter Fehlerbehebung bei der Aboreplikation.

1. Liste der Abos, deren aktueller Status und die Einstellungen in der aktuellen Datenbank auflisten:

   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;
   

   Die Ausgabe sieht in etwa so aus:

   -[ 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. Liste der Tabellen, die derzeit vom Abo repliziert werden, und ihre aktuelle Logsequenznummer (LSN):

   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;
   

   Die Ausgabe sieht in etwa so aus:

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

   In der Spalte sync_statuslsn sehen Sie, mit welcher LSN die Tabelle synchronisiert ist. Sie können dies mit dem LSN in der Anbieterdatenbank vergleichen, um die Replikationsverzögerung zu messen.

3. So prüfen Sie den Replikationsstatus für eine bestimmte Tabelle:

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

Details zum Replikationssatz beim Anbieter prüfen

1. Liste die aktuellen Replikationssätze in der Anbieterdatenbank auf und prüfe die replizierten Elemente:

   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. Liste der Tabellen und Sequenzen, die derzeit repliziert werden:

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

Replikationsinformationen und Slot-Lag beim Anbieter prüfen

1. Prüfe den Status der einzelnen Abonnenten, indem du die pg_stat_replication-Ansicht in der Anbieterdatenbank generierst:

   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;
   

   Die Ausgabe sieht in etwa so aus:

   -[ 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=#
   

   Achtung :Prüfen Sie nur die pglogical-Einträge. Korrelier die Spalte application_name mit dem Abonamen aus der Abodatenbank.

2. Beachte die Spalte reply_delay, in der der Zeitpunkt angezeigt wird, zu dem die letzte Aktualisierung aus der Abonnentendatenbank empfangen wurde.

3. Überwachen Sie die Replikationsverzögerung des Replikationsslots beim Anbieter, da pglogical Replikationsslots in der Anbieterdatenbank erstellt:

   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;
   

   Die Ausgabe sieht in etwa so aus:

   -[ 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=# 
   

   Wichtig :Mit anderen Tools und Erweiterungen können Sie Replikationsslots erstellen. Der überprüfte Replikationsslot muss einem pglogical-Replikationssatz entsprechen. Das wird durch das Plug-in abgedeckt, z. B. durch das '%pglogical%'Abfrageprädikat
   .

Fehlerbehebung bei der Abo-Replikation

Das in der Abonnentendatenbank geprüfte Abo muss den Status replicating oder initializing haben, wenn es vor Kurzem erstellt wurde. Wenn der Status down lautet, ist ein Problem aufgetreten.

Der Status down wird in der Regel angezeigt, wenn der Versuch, die Replikation zu starten, fehlgeschlagen ist. Das liegt an Verbindungsproblemen, die durch die dsn-Einstellung oder fehlende Datenbankberechtigungen verursacht werden, die entweder beim Anbieter oder beim Abonnenten liegen.

Verwenden Sie den Log-Explorer und prüfen Sie die PostgreSQL-Protokolldateien in Google Cloud , wennGoogle Cloud AlloyDB einer der Endpunkte ist, um zusätzliche Informationen zur Ursache des Problems zu erhalten. Die Protokolldateien enthalten Details zum Problem, einschließlich genauer Angaben zu fehlenden Berechtigungen.

1. Prüfen Sie das PostgreSQL-Protokoll auf Ihrem AlloyDB Omni-Server:

   Docker

   docker logs CONTAINER_NAME

   Ersetzen Sie CONTAINER_NAME durch den Namen, den Sie dem AlloyDB Omni-Container bei der Installation zugewiesen haben.

   Podman

   podman logs CONTAINER_NAME

   Ersetzen Sie CONTAINER_NAME durch den Namen, den Sie dem AlloyDB Omni-Container bei der Installation zugewiesen haben.

2. Beheben Sie Probleme mit der Einstellung dsn und prüfen Sie, ob die Netzwerkverbindung nicht die Ursache des Problems ist:

   1. Kopieren Sie den dsn-Verbindungsstring und versuchen Sie, eine manuelle Verbindung mit psql und demselben String herzustellen. Wenn für die psql-Sitzung keine Verbindung hergestellt werden kann, bedeutet das Folgendes:
      • Ein Netzwerkproblem.
      • Eine falsche IP-Adresse, ein falscher Nutzername oder ein falsches Passwort.
      • Eine blockierende Firewall.
      • Die pg_hba.conf-Datei des anderen Clusters ist nicht richtig konfiguriert.

3. Synchronisieren Sie eine Tabelle noch einmal, wenn Sie das Abo nach der Korrektur nicht löschen und neu erstellen möchten:

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

   Achtung: Durch diese Funktion wird die Tabelle abgeschnitten.

4. Alternativ können Sie Ihr Abo kündigen und neu erstellen:

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

Nächste Schritte

• Switchover und Failover mit pglogical-Replikation
• Daten zwischen Google Cloud AlloyDB und AlloyDB Omni replizieren
• Daten zwischen AlloyDB Omni und anderen Datenbanken replizieren