Monitora la replica pglogical in AlloyDB Omni

Seleziona una versione della documentazione:

Questa pagina fornisce informazioni su come monitorare e risolvere i problemi delle implementazioni di pglogical controllando e convalidando i database del fornitore e dell'abbonato.

Prima di iniziare

Prima di iniziare a monitorare e risolvere i problemi relativi alle implementazioni di pglogical, controlla i database del fornitore e dell'abbonato, comprendi l'implementazione di pglogical e verifica la sua configurazione.

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

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

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

Diversi parametri di configurazione influiscono sul funzionamento dell'estensione pglogical e puoi verificarlo nei database del fornitore e del sottoscrittore. Tieni presente che i valori dei parametri potrebbero variare.

  1. Mostra l'impostazione attuale 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 correlati 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 della 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. Informazioni sulla stringa di connessione errate o non aggiornate possono causare errori di replica. Per informazioni sulla risoluzione dei problemi relativi a dsn, vedi Risolvere i problemi relativi alla replica degli abbonamenti.

Controllare lo stato dell'abbonamento e il punto di replica della tabella

Lo stato dell'abbonamento viene sempre verificato dal database degli abbonati. L'abbonamento mostra lo stato initializing o replicating". Mostra anche lo stato down. Per ulteriori informazioni sullo stato down, consulta Risolvere i problemi relativi alla replica delle iscrizioni.

  1. Elenca gli abbonamenti, il loro stato e le impostazioni attuali nel database corrente:

    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 per l'abbonamento:

    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 con quale LSN è sincronizzata la tabella. Puoi confrontare questo valore con l'LSN nel database del fornitore 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 fornitore

  1. Elenca i set di replica correnti nel database del fornitore 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 di replica e il ritardo dello slot sul provider

  1. Controlla lo stato di ogni abbonato generando la visualizzazione 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 è stato ricevuto l'ultimo aggiornamento dal database degli abbonati.

  3. Monitora il ritardo della replica dello slot di replica sul fornitore perché pglogical crea slot di replica nel database del fornitore:

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

Risoluzione dei problemi di replica della sottoscrizione

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

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

Utilizza Esplora log e ispeziona i file di log di PostgreSQL in Google Cloud quando Google Cloud AlloyDB è uno degli endpoint, per informazioni aggiuntive che potrebbero indicare la causa del problema. I file di log forniscono i dettagli del problema, inclusi quelli specifici sulle autorizzazioni mancanti.

  1. Controlla il log di PostgreSQL sul server AlloyDB Omni:

    Docker 

    docker logs CONTAINER_NAME

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

    Podman 

    podman logs CONTAINER_NAME

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

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

    1. Copia la stringa di connessione dsn e prova una connessione manuale utilizzando psql e la stessa stringa. Se la sessione psql non riesce a connettersi, significa che:
      • Un problema di rete.
      • Un indirizzo IP, un nome utente o una password errati.
      • Un firewall che applica il blocco.
      • Il file pg_hba.conf dell'altro cluster non è configurato correttamente.

  3. Risincronizza una tabella se non vuoi eliminare e ricreare l'abbonamento dopo aver adottato misure correttive:

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

  4. In alternativa, annulla l'abbonamento e ricrealo:

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

Passaggi successivi