¿Cómo soluciono los problemas de replicación lógica en un clúster de base de datos de origen compatible con Aurora PostgreSQL?

Resolución

Configuración de los parámetros de replicación

Antes de solucionar los problemas de replicación lógica, configura los siguientes parámetros del grupo de parámetros del clúster de base de datos:

• Establece el valor rds.logical_replication en 1 para activar la replicación lógica en el clúster de base de datos.
• Establece un valor para max_replication_slots que incluya suficientes ranuras para el recuento esperado de suscripciones y los procesos adicionales de sincronización de tablas.
• Establece max_wal_senders en un valor que respalde tu cuota max_replication_slots y tus réplicas físicas actuales.
• Establece max_logical_replication_workers en un valor que respalde el recuento de suscripciones y el número de trabajadores adicionales que el sistema de replicación necesita para la sincronización de las tablas.
• Establece max_worker_processes en un valor que sea al menos uno más que el valor max_logical_replication_workers. Por ejemplo, si max_logical_replication_workers es 25, definemax_worker_processes en 26.
• Si la copia de datos es lenta, aumenta el valor max_sync_workers_per_subscription para controlar la cantidad de trabajadores de sincronización que procesan la configuración de la suscripción y las nuevas adiciones a las tablas.

Importante: Para aplicar los cambios anteriores, debes reiniciar el clúster de base de datos compatible con Aurora PostgreSQL.

Comprobación de la configuración de publicaciones y suscripciones

Después de configurar los parámetros de replicación lógica, comprueba que has configurado correctamente las publicaciones y las suscripciones. Asegúrate de que la publicación incluya todas las tablas previstas, que los parámetros de suscripción sean correctos y que el usuario de replicación tenga los permisos adecuados.

Conéctate a la base de datos de origen y, a continuación, ejecuta los siguientes comandos.

Para comprobar la configuración de la publicación, ejecuta los siguientes comandos:

SELECT * FROM pg_publication;
SELECT * FROM pg_publication_tables;

Para comprobar la configuración de la suscripción, ejecuta los siguientes comandos:

SELECT * FROM pg_subscription;
SELECT * FROM pg_subscription_rel;

Confirmación de que las ranuras de replicación están activas

Conéctate a la base de datos de origen y, a continuación, ejecuta el siguiente comando:

SELECT slot_name, plugin, slot_type, active, restart_lsn,
       confirmed_flush_lsn, pg_current_wal_lsn(),
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag
FROM pg_replication_slots;

Si las ranuras están inactivas o muestran un retraso excesivo, revisa los trabajadores de replicación para solucionar el problema.

Confirmación de que los trabajadores de replicación están activos 

Conéctate a la base de datos de destino y, a continuación, ejecuta el siguiente comando:

SELECT pid, state, query, wait_event, backend_type
FROM pg_stat_activity
WHERE backend_type LIKE 'logical replication%';

Si no hay ningún trabajador de replicación, reinicia la suscripción.

Para desactivar la suscripción, ejecuta el siguiente comando:

ALTER SUBSCRIPTION subscription_name DISABLE;

Para activar la suscripción, ejecuta el siguiente comando:

ALTER SUBSCRIPTION subscription_name ENABLE;

Si aún no hay ningún trabajador de replicación después de reiniciar la suscripción, consulta los registros de errores de PostgreSQL para ver si hay mensajes de error.

Supervisión del progreso y el retraso de la replicación

Es posible que la replicación experimente retrasos debido al alto volumen de transacciones y a las grandes transacciones de la publicación. O bien, puede haber restricciones en la publicación o la suscripción.

Para determinar si la replicación se detuvo o es lenta, supervisa el progreso de la replicación durante algunos intervalos. 

Conéctate a tu clúster de base de datos y, a continuación, ejecuta los siguientes comandos.

Para comprobar el progreso de la replicación de la publicación, ejecuta el siguiente comando:

SELECT slot_name,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag,
       active
FROM pg_replication_slots
WHERE slot_type = 'logical';

Para comprobar el progreso de la replicación de la suscripción, ejecuta el siguiente comando:

SELECT subname, pid, received_lsn, latest_end_lsn,
       pg_size_pretty(pg_wal_lsn_diff(latest_end_lsn, received_lsn)) AS lag
FROM pg_stat_subscription;

Para minimizar el retraso de la replicación, supervisa la caché de escritura directa. Si el tamaño de la caché no es suficiente para las cargas de trabajo, puedes cambiar manualmente el valor rds.logical_wal_cache. Para obtener más información, consulta Achieve up to 17x lower replication lag with the new write-through cache for Aurora PostgreSQL (Consigue reducir el retraso de la replicación hasta 17 veces con la nueva caché de escritura directa de Aurora PostgreSQL).

Supervisión de las limitaciones de recursos

Para solucionar las limitaciones de recursos del editor y el suscriptor, activa la supervisión mejorada y supervisa CPUUtilization, FreeableMemory, SwapUsage y NetworkThroughput. Configura las alarmas de Amazon CloudWatch para recibir notificaciones cuando se produzcan problemas de replicación.

Para más información, consulta ¿Cómo puedo identificar y solucionar los problemas de rendimiento y las consultas de ejecución lenta en mi instancia de base de datos compatible con Amazon RDS para PostgreSQL o Aurora PostgreSQL?

Identificación de desajustes en los esquemas y solución de inconsistencias de datos

Conéctate a la base de datos de origen y a la base de datos de destino. A continuación, confirma que haya columnas en las tablas replicadas y que los tipos de datos sean compatibles. Además, asegúrate de que las claves principales y las restricciones únicas sean coherentes.

Para activar la suscripción, ejecuta el siguiente comando:

ALTER SUBSCRIPTION subscription_name ENABLE;

Para comparar las definiciones de tablas, ejecuta el siguiente comando en ambas bases de datos:

SELECT column_name, data_type, character_maximum_length
FROM information_schema.columns
WHERE table_name = 'your_table_name'
ORDER BY ordinal_position;

Nota: Sustituye your_table_name por el nombre de tu tabla.

Solución de conflictos

La replicación lógica nativa de PostgreSQL no puede detectar conflictos de datos de varios editores ni modificaciones replicadas que entren en conflicto con los datos que modificaste localmente. Si hay una fila actual con la misma clave, Aurora aplica la actualización y se produce un error en la inserción. 

Para identificar la causa del conflicto, consulta los registros de PostgreSQL. 

En el siguiente ejemplo de registro se muestra que la replicación devolvió un error porque intentó insertar un registro con un ID de activo que ya existe en la base de datos de destino:

ERROR: 23505: duplicate key value violates unique constraint "asset_pkey"
DETAIL: Key (asset_id)=(7) already exists.
CONTEXT: processing remote data for replication origin "pg_32796" during message type "INSERT" for replication target relation "public.asset" in transaction 315434, finished at 0/6A12458

El origen de la replicación es pg_32796 y termina en el número de secuencia lógica (LSN) 0/6A12458.

Para corregir los datos manualmente, puedes detener la replicación en caso de conflicto o configurar la suscripción con la opción disable_on_error.

O bien, puedes revisar los datos del origen y el destino para determinar si puedes omitir el LSN que provocó el conflicto. A continuación, usa la función pg_replication_origin_advance() para omitir el LSN que provocó el conflicto. Para obtener más información, consulta pg_replication_origin_advance (node_name text, lsn pg_lsn) en el sitio web de PostgreSQL.

Nota: Las versiones 15 y posteriores compatibles con Aurora PostgreSQL admiten la función ** pg_replication_origin_advance()**.

Para omitir el LSN, sigue estos pasos:

1. Ejecuta el siguiente comando SQL para desactivar temporalmente la suscripción:

   ALTER SUBSCRIPTION subscription_name DISABLE;

   Nota: Si configuraste la suscripción con la opción disable_on_error, la suscripción se desactivará automáticamente tras un error.

2. Usa la siguiente función pg_replication_origin_advance() para hacer avanzar el origen a Finish_LSN+1:

   SELECT pg_replication_origin_advance('node_name','Finish_LSN+1'::pg_lsn);

   Nota: Sustituye node_name por el nombre de tu nodo.

3. Ejecuta el siguiente comando para activar la suscripción:

   ALTER SUBSCRIPTION subscription-name ENABLE;

   Nota: Sustituye subscription-name por el nombre de tu suscripción.

Para resolver varias incoherencias de datos, es posible que tengas que limpiar la tabla de destino y volver a configurar la publicación y la suscripción.

Información relacionada

Replicación con Amazon Aurora PostgreSQL

Replicación lógica de PostgreSQL en el sitio web de PostgreSQL

Configuración de la replicación lógica para tu clúster de base de datos Aurora PostgreSQL

Supervisión de métricas de Amazon Aurora con Amazon CloudWatch