¿Por qué se producen retrasos y errores de replicación en mi instancia de base de datos de RDS para PostgreSQL?

Descripción corta

Puede escalar las lecturas de la instancia de base de datos de Amazon RDS para PostgreSQL al añadir réplicas de lectura a la instancia. RDS para PostgreSQL utiliza la replicación de streaming nativa de PostgreSQL para crear una copia de solo lectura de una instancia de base de datos de origen. Esta instancia de base de datos de réplica de lectura es una réplica física creada de forma asíncrona de la instancia de base de datos de origen. Esto significa que, a veces, la réplica no puede seguir el ritmo de la instancia de base de datos principal. Como resultado, puede producirse un retraso en la replicación. La base de datos de réplica se crea mediante una conexión especial que transmite los datos de registro de escritura anticipada (WAL) desde la instancia de base de datos de origen a la réplica de lectura. Por lo tanto, la réplica de lectura comprueba los registros de WAL a fin de replicar los cambios realizados en la instancia principal. Cuando la réplica de lectura no encuentra el WAL en la instancia principal, la réplica de lectura se recupera de los datos de WAL archivados en Amazon Simple Storage Service (Amazon S3). Para obtener más información, consulte Cómo funciona la replicación de streaming para diferentes versiones de RDS para PostgreSQL.

Puede monitorear el retraso en la replicación en Amazon CloudWatch al consultar la métrica ReplicaLag de Amazon RDS. Esta métrica muestra hasta qué punto una réplica de lectura está atrasada en relación con su instancia de base de datos de origen. Amazon RDS supervisa el estado de replicación de la réplica de lectura. Luego, actualiza el campo Replication State (Estado de replicación) de la consola de Amazon RDS a Error si la replicación se detiene por algún motivo. La métrica ReplicaLag indica qué tan bien una réplica de lectura puede seguir el ritmo de la instancia de base de datos de origen y la cantidad de latencia entre la instancia de base de datos de origen y una instancia de lectura específica.

Resolución

Es posible que aparezca uno de los siguientes errores en los registros de errores de RDS para PostgreSQL si aumenta el retraso de la réplica:

• Streaming replication has stopped (La replicación de streaming se detuvo): aparece este error cuando se interrumpe la replicación de streaming entre la instancia principal y la de réplica. En este caso, la replicación comienza a reproducirse desde la ubicación del archivo en Amazon S3, lo que conduce a un mayor retraso de la réplica.
• Streaming replication has been terminated (Finalizó la replicación de streaming): aparece este error cuando la replicación se detiene durante más de 30 días consecutivos, ya sea de forma manual o debido a un error de replicación. En este caso, Amazon RDS finaliza la replicación entre la instancia de base de datos principal y todas las réplicas de lectura a fin de evitar el aumento de los requisitos de almacenamiento en la instancia principal y tiempos de conmutación por error más prolongados.

La instancia de réplica de lectura está disponible incluso después de finalizar la replicación. Sin embargo, la replicación no se puede reanudar porque los registros de transacciones requeridos por la réplica de lectura se eliminan de la instancia principal una vez finalizada la replicación.

Las razones más comunes del aumento del retraso de la réplica son las siguientes:

• Diferencias de configuración entre la instancia principal y la de réplica
• Carga de trabajo de escritura pesada en la instancia principal
• Transacciones que se ejecutan durante mucho tiempo
• Bloqueo exclusivo en tablas de instancias principales
• Archivo WAL dañado o faltante
• Problemas de red
• Configuración de parámetros incorrecta
• Ninguna transacción

Diferencias de configuración entre la instancia principal y la réplica de lectura

Las configuraciones incorrectas de la instancia de réplica pueden afectar el rendimiento de la replicación. La réplica de lectura gestiona una carga de trabajo de escritura similar a la de la instancia de origen, junto con consultas de lectura adicionales. Por lo tanto, utiliza réplicas de la misma clase de instancia y del mismo tipo de almacenamiento que la instancia de origen o superior. Como la réplica debe reproducir la misma actividad de escritura que la instancia de origen, el uso de una réplica de clase de instancia inferior puede provocar una latencia alta para la réplica y aumentar el retraso en la replicación. Las configuraciones de almacenamiento no coincidentes también aumentan el retraso en la replicación.

Carga de trabajo de escritura pesada en la instancia principal

Una carga de trabajo de escritura intensa en la instancia principal puede generar una gran afluencia de archivos WAL. Un aumento en el número de archivos WAL y la reproducción de estos archivos en réplicas de lectura podrían ralentizar el rendimiento general de la replicación. Por lo tanto, si observa un aumento en el retraso de la réplica, asegúrese de comprobar la actividad de escritura en la instancia principal. Puede utilizar las métricas de CloudWatch o Enhanced Monitoring para analizar esta carga de trabajo. Ver valores de TransactionLogsDiskUsage, TransactionLogsGeneration, WriteIOPS, WriteThroughput y WriteLatency para saber si la instancia de origen se somete a una carga de trabajo de escritura pesada. También puede comprobar si hay cuellos de botella a nivel de rendimiento. Cada tipo de instancia tiene su rendimiento dedicado. Para obtener más información, consulte Especificaciones de hardware para clases de instancias de base de datos.

Para evitar este problema, controle y distribuya la actividad de escritura de la instancia de origen. En lugar de realizar muchas actividades de escritura juntas, divida la tarea en paquetes de tareas más pequeños y, luego, distribuya dichos paquetes de manera uniforme en varias transacciones. Puede utilizar alertas de CloudWatch para las métricas, como Writelatency y WriteIOPS, a fin de recibir notificaciones de escrituras pesadas en la instancia de origen.

Transacciones que se ejecutan durante mucho tiempo

Las transacciones activas que se ejecutan durante mucho tiempo en la base de datos pueden interferir con el proceso de replicación de WAL, lo que aumenta el retraso en la replicación. Por lo tanto, asegúrese de monitorear el tiempo de ejecución de las transacciones activas con la vista pg_stat_activity de PostgreSQL.

Ejecute una consulta en la instancia principal similar a la siguiente a fin de encontrar el ID de proceso (PID) de la consulta que se está ejecutando durante mucho tiempo:

SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';

Después de identificar el PID de la consulta, puede optar por finalizar la consulta.

Ejecute una consulta en la instancia principal similar a la siguiente para finalizar la consulta:

SELECT pg_terminate_backend(PID);

También puede optar por reescribir o ajustar la consulta a fin de evitar transacciones que se ejecuten durante mucho tiempo.

Bloqueo exclusivo en tablas de instancias principales

Cuando ejecuta comandos, como DROP TABLE, TRUNCATE, REINDEX, VACUUM FULL, REFRESH MATERIALIZED VIEW (sin CONCURRENTLY), en la instancia principal, PostgreSQL procesa un bloqueo de Acceso Exclusivo. Este bloqueo impide que todas las demás transacciones accedan a la tabla durante la duración del bloqueo. Por lo general, la tabla permanece bloqueada hasta que finaliza la transacción. Esta actividad de bloqueo se graba en WAL y, luego, la réplica de lectura la reproduce y la retiene. Cuanto más tiempo permanezca la tabla con un bloqueo de acceso exclusivo, mayor será el retraso en la replicación.

Para evitar este problema, se recomienda supervisar las transacciones mediante la consulta periódica de las tablas de catálogo pg_locks y pg_stat_activity.

Ejemplo:

SELECT pid, usename, pg_blocking_pids(pid) AS blocked_by, QUERY AS blocked_query<br>FROM pg_stat_activity<br>WHERE cardinality(pg_blocking_pids(pid)) > 0;

Archivo WAL dañado o faltante

Un archivo WAL dañado o faltante puede provocar un retraso de la réplica. En este caso, aparecerá un error en los registros de PostgreSQL que indicará que no se puede abrir el WAL. También puede aparecer el error "requested WAL segment XXX has already been removed" (Ya se eliminó el segmento WAL XXX solicitado).

Problemas de red

Una interrupción de la red entre la instancia principal y la de réplica podría provocar problemas con la replicación de streaming que podrían provocar un aumento en el retraso de la réplica.

Configuración de parámetros incorrecta

La configuración incorrecta de algunos de los parámetros personalizados en el grupo de parámetros de configuración del servidor puede provocar un aumento del retraso de la réplica. Los siguientes son algunos de los parámetros que debe configurar correctamente:

• wal_keep_segments: este parámetro especifica el número de archivos WAL que la instancia principal mantiene en el directorio pg_wal. El valor predeterminado de este parámetro se establece en 32. Si este parámetro no se establece en un valor lo suficientemente alto para el despliegue, la réplica de lectura puede retrasarse y provocar que se detenga la replicación de streaming. En este caso, RDS genera un error de replicación e inicia la recuperación en la réplica de lectura mediante la reproducción de los datos WAL archivados de la instancia principal desde S3. Este proceso de recuperación continúa hasta que la réplica de lectura pueda continuar con la replicación de streaming.
  Nota: En la versión 13 de PostgreSQL, el parámetro wal_keep_segments se denomina wal_keep_size. Este parámetro tiene el mismo propósito que wal_keep_segments. Sin embargo, el valor predeterminado de este parámetro se define en MB (2048 MB) en lugar de según la cantidad de archivos.
• max_wal_senders: este parámetro especifica el número máximo de conexiones que la instancia principal puede admitir al mismo tiempo a través del protocolo de replicación de streaming. El valor predeterminado de este parámetro para RDS para PostgreSQL 13 y versiones posteriores es 20. Este parámetro debe establecerse en un valor ligeramente superior al número real de réplicas de lectura. Si este parámetro se establece en un valor inferior al número de réplicas de lectura, la replicación se detiene.
• hot_standby_feedback: este parámetro especifica si la instancia de réplica envía comentarios a la instancia principal sobre las consultas que se están ejecutando actualmente en la instancia de réplica. Al activar este parámetro, se selecciona el siguiente mensaje de error en la instancia de origen y se pospone la operación VACUUM en las tablas relacionadas, a menos que se complete la consulta de lectura en la instancia de réplica. Por lo tanto, una instancia de réplica que tenga activado hot_standby_feedback puede atender consultas de larga duración. Sin embargo, este parámetro puede sobrecargar las tablas en la instancia de origen. Asegúrese de monitorear las consultas de larga duración en las instancias de réplica a fin de evitar problemas graves, como la falta de almacenamiento o el ID de transacción envolvente en la instancia principal.

ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed

• max_standby_streaming_delay/max_standby_archive_delay: puede habilitar parámetros, como max_standby_archive_delay o max_standby_streaming_delay en la instancia de réplica a fin de completar consultas de lectura de larga duración. Estos parámetros detienen la reproducción de WAL en la réplica si los datos de origen se modifican al ejecutar consultas de lectura en la réplica. Un valor de -1 para estos parámetros permite que la reproducción de WAL espere hasta que se complete la consulta de lectura. Sin embargo, esta pausa aumenta el retraso en la replicación indefinidamente y provoca un alto consumo de almacenamiento en el origen debido a la acumulación de WAL.

Ninguna transacción

Si no se producen transacciones de usuarios en la instancia de base de datos de origen, la réplica de lectura de PostgreSQL informa un retraso en la replicación de hasta cinco minutos.

---

Información relacionada

Trabajo con réplicas de lectura de Amazon RDS para PostgreSQL

Documentación de PostgreSQL para la configuración del servidor