Monitorizar la replicación de pglogical en AlloyDB Omni

Selecciona una versión de la documentación: 15.7.0

• Actual (16.8.0)
• 16.8.0
• 16.3.0
• 15.12.0
• 15.7.1
• 15.7.0
• 15.5.5
• 15.5.4
• 15.5.2

En esta página se explica cómo monitorizar y solucionar problemas de implementaciones de pglogical comprobando y validando las bases de datos de proveedores y suscriptores.

La información de esta página solo se aplica a AlloyDB Omni para contenedores. No se aplica a AlloyDB Omni para Kubernetes.

Antes de empezar

Antes de empezar a monitorizar y solucionar problemas de implementaciones de pglogical, comprueba las bases de datos de proveedores y suscriptores, familiarízate con la implementación de pglogical y valida cómo está configurada.

Para obtener más información sobre la extensión pglogical, consulta el artículo Acerca de pglogical.

Para obtener información sobre la replicación de datos mediante pglogical, consulta los artículos Replicar datos entre AlloyDB para PostgreSQL y AlloyDB Omni y Replicar datos entre AlloyDB Omni y otras bases de datos.

Comprobar los ajustes de los parámetros de pglogical, la replicación y AlloyDB Omni

Hay varios parámetros de configuración que afectan al funcionamiento de la extensión pglogical, y puedes consultarlos en las bases de datos del proveedor y del suscriptor. Ten en cuenta que los valores de los parámetros pueden variar.

1. Para ver la configuración actual de los parámetros específicos de pglogical, sigue estos pasos:

   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 otros parámetros relacionados con la replicación 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 los parámetros específicos de AlloyDB Omni:

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

Nota: Te recomendamos que revises la configuración de los parámetros en todos los nodos.

Mostrar nodos de la configuración

1. Incluye los nodos locales y remotos en la configuración de replicación de 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;
   

   Si la columna node_id es NOT NULL, se trata del nodo local.

2. Revisa la información de dsn en detalle. Si la información de la cadena de conexión es incorrecta o está obsoleta, se producirán errores de replicación. Para obtener información sobre cómo solucionar problemas de dsn, consulta Solucionar problemas de replicación de suscripciones.

Comprobar el estado de la suscripción y el punto de replicación de la tabla

El estado de la suscripción siempre se verifica en la base de datos de suscriptores. La suscripción muestra el estado initializing o replicating". También muestra el estado down. Para obtener más información sobre el estado down, consulta el artículo Solucionar problemas con la replicación de suscripciones.

1. Lista las suscripciones, su estado y sus ajustes actuales en la base de datos actual:

   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;
   

   El resultado debería ser similar al siguiente:

   -[ 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. Lista de las tablas que se están replicando y su número de secuencia de registro (LSN) actual por suscripción:

   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;
   

   El resultado debería ser similar al siguiente:

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

   La columna sync_statuslsn muestra con qué LSN se sincroniza la tabla. Puedes comparar este valor con el LSN de la base de datos del proveedor para medir el retraso de la réplica.

3. Para comprobar el estado de la réplica de una tabla específica, sigue estos pasos:

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

Verificar los detalles del conjunto de réplicas en el proveedor

1. Lista los conjuntos de réplicas actuales de la base de datos del proveedor y comprueba los elementos que se replican:

   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. Mostrar las tablas y secuencias que se replican:

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

Comprobar la información de replicación y el retraso de la ranura en el proveedor

1. Comprueba el estado de cada suscriptor generando la vista pg_stat_replication en la base de datos del proveedor:

   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;
   

   El resultado debería ser similar al siguiente:

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

   Precaución: Asegúrate de revisar solo las entradas de pglogical. Correlaciona la columna application_name con el nombre de la suscripción de la base de datos de suscriptores.

2. Anota la columna reply_delay, que muestra la hora en la que se recibió la última actualización de la base de datos de suscriptores.

3. Monitoriza el retraso de la réplica de la ranura de réplica en el proveedor, ya que pglogical crea ranuras de réplica en la base de datos del proveedor:

   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;
   

   El resultado debería ser similar al siguiente:

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

   Importante: Otras herramientas y extensiones pueden crear ranuras de replicación. Debes asegurarte de que el espacio de réplica que se revisa corresponde a un conjunto de réplicas pglogical. Esto se incluye en el complemento, como '%pglogical%' query predicate
   .

Solucionar problemas de replicación de suscripciones

La suscripción que se comprueba en la base de datos de suscriptores debe tener el estado replicating o initializing si se ha creado recientemente. Si el estado es down, significa que se ha producido un problema.

El estado down suele mostrarse después de que la replicación haya intentado iniciarse, pero no lo haya conseguido. Esto se debe a problemas de conectividad causados por el ajuste de dsn o a que faltan permisos de base de datos, ya sea en el proveedor o en el suscriptor.

Usa el Explorador de registros e inspecciona los archivos de registro de PostgreSQL en Google Cloud cuandoGoogle Cloud AlloyDB sea uno de los endpoints para obtener más información que pueda indicar la causa del problema. Los archivos de registro proporcionan detalles sobre el problema, incluidos datos específicos sobre los permisos que faltan.

1. Consulta el registro de PostgreSQL en tu servidor AlloyDB Omni:

   Docker

   docker logs CONTAINER_NAME

   Sustituye CONTAINER_NAME por el nombre que asignaste al contenedor de AlloyDB Omni cuando lo instalaste.

   Podman

   podman logs CONTAINER_NAME

   Sustituye CONTAINER_NAME por el nombre que asignaste al contenedor de AlloyDB Omni cuando lo instalaste.

2. Soluciona los problemas de la configuración dsn y asegúrate de que la conectividad de red no sea la causa del problema:

   1. Copia la dsn cadena de conexión y prueba a conectarte manualmente con psql y la misma cadena. Si no se puede conectar la sesión psql, significa lo siguiente:
      • Un problema de red.
      • Una dirección IP, un nombre de usuario o una contraseña incorrectos.
      • Un cortafuegos que bloquea.
      • El archivo pg_hba.conf del otro clúster no está configurado correctamente.

3. Resincroniza una tabla si no quieres eliminar y volver a crear la suscripción después de tomar medidas correctivas:

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

   Precaución: Esta función trunca la tabla.

4. También puedes cancelar tu suscripción y volver a crearla:

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

Siguientes pasos

• Cambio y conmutación por error con la replicación pglogical
• Replicar datos entre Google Cloud AlloyDB y AlloyDB Omni
• Replicar datos entre AlloyDB Omni y otras bases de datos