Monitora la replica pglogical in AlloyDB Omni

Seleziona una versione della documentazione:

In questa pagina viene spiegato come monitorare e risolvere i problemi relativi alle implementazioni di pglogical controllando e convalidando i database dei provider e degli abbonati.

Prima di iniziare

Prima di iniziare a monitorare e risolvere i problemi delle implementazioni di pglogical, controlla i database dei provider e degli abbonati, comprendi l'implementazione di pglogical e convalida la sua configurazione.

Per saperne di più sull'estensione pglogical, consulta Informazioni su pglogical.

Per informazioni sulla replica dei dati utilizzando pglogical, consulta Replica i dati tra AlloyDB per PostgreSQL e AlloyDB Omni e Replica i dati tra AlloyDB Omni e altri database.

Controlla le impostazioni dei parametri di pglogical, della replica e di AlloyDB Omni

Il funzionamento dell'estensione pglogical è influenzato da una serie di parametri di configurazione, che puoi controllare nei database del provider e del sottoscrittore. Tieni presente che i valori dei parametri potrebbero variare.

  1. Mostra l'impostazione corrente dei parametri specifici di 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. Mostra altri parametri relativi alla replica logica:

    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. Mostra i parametri specifici di AlloyDB Omni:

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

Elenca i nodi nella configurazione

  1. Elenca i nodi locali e remoti nella configurazione di replica 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;

    Se la colonna node_id è NOT NULL, si tratta del nodo locale.

  2. Esamina in dettaglio le informazioni relative a dsn. Qualsiasi informazione errata o non aggiornata sulla stringa di connessione può causare errori di replica. Per informazioni sulla risoluzione dei problemi relativi a dsn, consulta Risolvi i problemi di replica delle sottoscrizioni.

Controlla lo stato della sottoscrizione e il punto di replica della tabella

Verifichi lo stato dell'abbonamento dal database degli abbonati. L'abbonamento mostra lo stato initializing o replicating. Potrebbe anche mostrare lo stato down. Per ulteriori informazioni sullo stato down, consulta Risolvi i problemi di replica delle sottoscrizioni.

  1. Elenca le sottoscrizioni del database corrente, nonché lo stato e le impostazioni delle sottoscrizioni.

    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;

    L'output è simile al seguente:

    -[ 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. Elenca le tabelle attualmente replicate e il relativo numero di sequenza di log (LSN) corrente dalla sottoscrizione:

    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;

    L'output è simile al seguente:

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

my_test_db=#

    La colonna sync_statuslsn mostra l'LSN con cui è sincronizzata la tabella. Puoi confrontarlo con l'LSN nel database del provider per valutare il ritardo di replica.

  3. Controlla lo stato della replica per una tabella specifica:

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

Verifica i dettagli del set di replica sul provider

  1. Elenca i set di replica correnti nel database del provider e controlla gli elementi replicati:

    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. Elenca le tabelle e le sequenze replicate:

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

Controlla le informazioni sulla replica e il ritardo dello slot sul provider

  1. Controlla lo stato di ogni abbonato generando la vista pg_stat_replication nel database del fornitore:

    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;

    L'output è simile al seguente:

    -[ 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. Prendi nota della colonna reply_delay, che mostra l'ora in cui ha ricevuto l'ultimo aggiornamento dal database degli abbonati.

  3. Monitora il ritardo di replica dello slot di replica sul provider, perché pglogical crea slot di replica sul database del provider:

    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;

    L'output è simile al seguente:

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

Risolvi i problemi di replica delle sottoscrizioni

L'abbonamento selezionato nel database degli abbonati deve avere lo stato replicating o initializing se è stato creato di recente. Se lo stato è down, si è verificato un problema.

Lo stato down viene solitamente visualizzato dopo che la replica ha tentato di avviarsi, ma non è riuscita. Ciò è dovuto a problemi di connettività causati dall'impostazione dsn o ad autorizzazioni del database mancanti, che si trovano nel provider o nel sottoscrittore.

Utilizza Esplora log ed esamina i file di log di PostgreSQL in Google Cloudquando Google Cloud AlloyDB è uno degli endpoint, per ottenere ulteriori informazioni che potrebbero indicare la causa del problema. I file di log forniscono dettagli sul problema, inclusi dettagli specifici sulle autorizzazioni mancanti.

Controlla il log di PostgreSQL sul server AlloyDB Omni:

Docker 

  docker logs CONTAINER_NAME

Sostituisci CONTAINER_NAME con il nome che hai assegnato al container AlloyDB Omni durante l'installazione.

Podman 

  podman logs CONTAINER_NAME

Sostituisci CONTAINER_NAME con il nome che hai assegnato al container AlloyDB Omni durante l'installazione.

  1. Risolvi i problemi relativi all'impostazione dsn e assicurati che la connettività di rete non sia la causa del problema:

    • Copia la stringa di connessione dsn e prova a stabilire una connessione manuale utilizzando psql e la stessa stringa. Se la sessione psql non riesce a connettersi, indica quanto segue:

      • Un problema di rete.
      • Indirizzo IP, nome utente o password errati.
      • Un firewall che applica il blocco.
      • Il file pg_hba.conf dell'altro cluster non è configurato correttamente.

  2. Dopo aver intrapreso azioni correttive, risincronizza una tabella o elimina e ricrea la sottoscrizione:

    • Per risincronizzare una tabella senza eliminare la sottoscrizione:

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

    • In alternativa, per eliminare e ricreare la sottoscrizione:

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

Passaggi successivi