pglogical-Replikation in AlloyDB Omni überwachen

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite finden Sie Informationen dazu, wie Sie pglogical-Implementierungen überwachen und Fehler beheben können, indem Sie die Anbieter- und Abonnentendatenbanken prüfen und validieren.

Hinweise

Bevor Sie mit der Überwachung und Fehlerbehebung von pglogical-Implementierungen beginnen, sollten Sie die Anbieter- und Abonnentendatenbanken prüfen, die pglogical-Implementierung verstehen und die Konfiguration validieren.

Weitere Informationen zur Erweiterung pglogical finden Sie unter pglogical.

Informationen zur Datenreplikation mit pglogical finden Sie unter Daten zwischen AlloyDB for PostgreSQL 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 Funktionsweise der pglogical-Erweiterung aus. Sie können diese in den Provider- und Subscriber-Datenbanken prüfen. Die Parameterwerte können variieren.

  1. Aktuelle Einstellung der pglogical-spezifischen Parameter 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;

Knoten in der Konfiguration auflisten

  1. Listen Sie sowohl lokale als auch Remote-Knoten in der pglogical-Replikationskonfiguration auf:

    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 das der lokale Knoten.

  2. Sehen Sie sich die dsn-Informationen genau 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.

Abo-Status und Tabellenreplikationspunkt prüfen

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

  1. So listen Sie die Abos, ihren aktuellen Status und ihre Einstellungen in der aktuellen Datenbank auf:

    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 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. Listen Sie die Tabellen auf, die derzeit repliziert werden, und ihre aktuelle Logsequenznummer (LSN) nach 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;

    Die Ausgabe sieht 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 wird angezeigt, mit welcher LSN die Tabelle synchronisiert wird. Sie können diesen Wert mit dem LSN in der Anbieterdatenbank vergleichen, um die Replikationsverzögerung zu ermitteln.

  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 überprüfen

  1. Listen Sie die aktuellen Replikationssätze in der Anbieterdatenbank auf und prüfen Sie 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. Tabellen und Sequenzen auflisten, die 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-Verzögerung auf dem Anbieter prüfen

  1. Prüfen Sie den Status der einzelnen Abonnenten, indem Sie die Ansicht pg_stat_replication in der Datenbank des Anbieters generieren:

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

  2. Achten Sie auf die Spalte reply_delay. Dort sehen Sie, wann die Daten zuletzt aus der Abonnentendatenbank aktualisiert wurden.

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

Fehlerbehebung bei der Aboreplikation

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

Der Status down wird normalerweise angezeigt, nachdem versucht wurde, die Replikation zu starten, dies jedoch fehlgeschlagen ist. Das liegt an Verbindungsproblemen, die durch die Einstellung dsn verursacht werden, oder an fehlenden Datenbankberechtigungen beim Anbieter oder Abonnenten.

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

  1. Prüfen Sie das PostgreSQL-Log 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. Führe die Fehlerbehebung für die Einstellung dsn durch und stelle sicher, dass 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 keine Verbindung zur psql-Sitzung hergestellt werden kann, deutet dies auf Folgendes hin:
      • 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. Sie können eine Tabelle neu synchronisieren, wenn Sie das Abo nach Korrekturmaßnahmen nicht löschen und neu erstellen möchten:

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

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

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

Nächste Schritte