Monitor pglogical replication in AlloyDB Omni

This page provides provides information about how to monitor and troubleshoot pglogical implementations by checking and validating the provider and subscriber databases.

Before you begin

Before you begin to monitor and troubleshoot pglogical implementations, check the provider and subscriber databases, understand the pglogical implementation, and validate how it is configured.

For more information about the pglogical extension, see About pglogical.

For information about data replication using pglogical, see Replicate data between Google Cloud AlloyDB and AlloyDB Omni and Replicate data between AlloyDB Omni and other databases.

Check pglogical, replication, and AlloyDB Omni parameter settings

A number of configuration parameters affect the operation of the pglogical extension, and you can check that in the provider and subscriber databases. Note that the parameter values might vary.

  1. Show the current setting of pglogical-specific parameters:

    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. Show other logical replication-related parameters:

    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. Show AlloyDB Omni-specific parameters:

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

List nodes in the configuration

  1. List both local and remote nodes in the pglogical replication configuration:

    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;

    If the node_id column is NOT NULL, then that's the local node.

  2. Review the dsn information in detail. Any incorrect or outdated connection string information can result in replication failures. For information about dsn troubleshooting, see Troubleshoot subscription replication.

Check the subscription status and table replication point

The subscription status is always verified from the subscriber database. The subscription shows a status of initializing or replicating". It also shows a status of down. For more information about the down status, see Troubleshoot subscription replication.

  1. List the subscriptions, their current status and settings, in the current database:

    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;

    The output is similar to the following:

    -[ 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. List that tables that are currently replicated and their current log sequence number (LSN) by the subscription:

    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;

    The output is similar to the following:

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

my_test_db=#

    The sync_statuslsn column shows to which LSN the table is synchronized. You can compare this to the LSN at the provider database to gauge replication lag.

  3. Check the replication status for a specific table:

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

Verify replication set details on the provider

  1. List the current replication sets in the provider database and check the items that are replicated:

    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. List tables and sequences that are currently replicated:

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

Check the replication information and slot lag on the provider

  1. Check the status of each subscriber by generating the pg_stat_replication view on the provider database:

    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;

    The output is similar to the following:

    -[ 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. Take note of the reply_delay column, which shows the time when it received the last update from the subscriber database.

  3. Monitor replication lag of the replication slot on the provider because pglogical creates replication slots on the provider database:

    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;

    The output is similar to the following:

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

Troubleshooting subscription replication

The subscription that's checked on the subscriber database must show a status of replicating or initializing if the subscription is recently created. If the status is down, then a problem has occurred.

The down status is usually shown after replication has attempted to initiate, but has failed. This is due to connectivity issues caused by the dsn setting, or missing database permissions, which is either at the provider or subscriber.

Use Log Explorer and inspect the PostgreSQL log files in Google Cloud when Google Cloud AlloyDB is one of the endpoints, for additional information that might indicate the cause of the problem. The log files provide details of the problem, including specific details on missing permissions.

  1. Check the PostgreSQL log on your AlloyDB Omni server:

    Docker 

    docker logs CONTAINER_NAME

    Replace CONTAINER_NAME with the name that you assigned to the AlloyDB Omni container when you installed it.

    Podman 

    podman logs CONTAINER_NAME

    Replace CONTAINER_NAME with the name that you assigned to the AlloyDB Omni container when you installed it.

  2. Troubleshoot the dsn setting and ensure that network connectivity isn't the source of the problem:

    1. Copy the dsn connection string and try a manual connection using psql and the same string. If the psql session cannot connect, it indicates the following:
      • A networking issue.
      • An incorrect IP address, username, or password.
      • A blocking firewall.
      • The other cluster's pg_hba.conf file is not properly configured.

  3. Resynchronize a table if you don't want to drop and re-create the subscription after taking corrective actions:

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

  4. Alternatively, drop your subscription and re-create it:

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

What's next