Monitorar a replicação pglógica no AlloyDB Omni

Selecione uma versão da documentação:

Esta página fornece informações sobre como monitorar e solucionar problemas de implementações do pglogical verificando e validando os bancos de dados do provedor e do assinante.

Antes de começar

Antes de começar a monitorar e solucionar problemas de implementações do pglogical, verifique os bancos de dados do provedor e do assinante, entenda a implementação do pglogical e valide como ela está configurada.

Para mais informações sobre a extensão pglogical, consulte Sobre o pglogical.

Para informações sobre replicação de dados usando pglogical, consulte Replicar dados entre o AlloyDB para PostgreSQL e o AlloyDB Omni e Replicar dados entre o AlloyDB Omni e outros bancos de dados.

Verificar as configurações de parâmetros do pglogical, da replicação e do AlloyDB Omni

Vários parâmetros de configuração afetam a operação da extensão pglogical, e você pode verificar isso nos bancos de dados do provedor e do assinante. Os valores dos parâmetros podem variar.

  1. Mostrar a configuração atual de parâmetros específicos do 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. Mostrar outros parâmetros relacionados à replicação lógica:

    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. Mostrar parâmetros específicos do AlloyDB Omni:

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

Listar nós na configuração

  1. Listar nós locais e remotos na configuração de replicação do 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 a coluna node_id for NOT NULL, esse será o nó local.

  2. Revise as informações dsn em detalhes. Qualquer informação incorreta ou desatualizada da string de conexão pode resultar em falhas na replicação. Para informações sobre dsn solução de problemas, consulte Resolver problemas de replicação de assinatura.

Verificar o status da assinatura e o ponto de replicação da tabela

O status da assinatura é sempre verificado no banco de dados do assinante. A assinatura mostra um status de initializing ou replicating". Ela também mostra um status de down. Para mais informações sobre o status down, consulte Resolver problemas de replicação de assinatura.

  1. Listar as assinaturas, o status e as configurações atuais no banco de dados atual:

    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;

    O resultado será assim:

    -[ 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. Listar as tabelas que estão sendo replicadas e o número de sequência de registro (LSN) atual delas pela assinatura:

    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;

    O resultado será assim:

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

my_test_db=#

    A coluna sync_statuslsn mostra para qual LSN a tabela está sincronizada. Você pode comparar isso ao LSN no banco de dados do provedor para avaliar o atraso de replicação.

  3. Verificar o status de replicação de uma tabela específica:

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

Verificar os detalhes do conjunto de replicação no provedor

  1. Listar os conjuntos de replicação atuais no banco de dados do provedor e verificar os itens replicados:

    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. Listar tabelas e sequências replicadas:

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

Verificar as informações de replicação e o atraso do slot no provedor

  1. Verificar o status de cada assinante gerando a visualização pg_stat_replication no banco de dados do provedor:

    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;

    O resultado será assim:

    -[ 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. Anote a coluna reply_delay, que mostra o horário em que ela recebeu a última atualização do banco de dados do assinante.

  3. Monitore o atraso de replicação do slot de replicação no provedor, porque o pglogical cria slots de replicação no banco de dados do provedor:

    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;

    O resultado será assim:

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

Resolver problemas de replicação de assinatura

A assinatura verificada no banco de dados do assinante precisa mostrar um status de replicating ou initializing se a assinatura tiver sido criada recentemente. Se o status for down, ocorreu um problema.

O status down geralmente é mostrado depois que a replicação tenta iniciar, mas falha. Isso ocorre devido a problemas de conectividade causados pela configuração dsn ou permissões de banco de dados ausentes, que estão no provedor ou no assinante.

Use a Análise de registros e inspecione os arquivos de registro do PostgreSQL em Google Cloud quando Google Cloud o AlloyDB for um dos endpoints, para mais informações que possam indicar a causa do problema. Os arquivos de registro fornecem detalhes do problema, incluindo detalhes específicos sobre permissões ausentes.

  1. Verifique o registro do PostgreSQL no servidor do AlloyDB Omni:

    Docker 

    docker logs CONTAINER_NAME

    Substitua CONTAINER_NAME pelo nome que você atribuiu ao contêiner do AlloyDB Omni ao instalá-lo.

    Podman 

    podman logs CONTAINER_NAME

    Substitua CONTAINER_NAME pelo nome que você atribuiu ao contêiner do AlloyDB Omni ao instalá-lo.

  2. Solucione problemas da configuração dsn e verifique se a conectividade de rede não é a origem do problema:

    1. Copie a string de conexão dsn e tente uma conexão manual usando psql e a mesma string. Se a sessão psql não puder se conectar, isso indica o seguinte:
      • Um problema de rede.
      • Um endereço IP, nome de usuário ou senha incorretos.
      • Um firewall de bloqueio.
      • O arquivo pg_hba.conf do outro cluster não está configurado corretamente.

  3. Sincronize novamente uma tabela se não quiser remover e recriar a assinatura depois de tomar ações corretivas:

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

  4. Como alternativa, remova a assinatura e recrie-a:

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

A seguir