Solución de problemas de punto de conexión de PostgreSQL - AWS Database Migration Service

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Solución de problemas de punto de conexión de PostgreSQL

Esta sección contiene escenarios de replicación específicos de PostgreSQL.

Transacciones de larga duración en el origen

Cuando hay transacciones de larga duración en la base de datos de origen, como varios miles de inserciones en una sola transacción, los contadores de eventos y transacciones de DMS CDC no aumentan hasta que se completa la transacción. Este retraso puede provocar problemas de latencia que se pueden medir con la métrica CDCLatencyTarget.

Para revisar transacciones de larga data, realice una de las siguientes acciones:

  • Utilice la vista de pg_replication_slots. Si el valor restart_lsn no se actualiza, es probable que PostgreSQL no pueda publicar los registros de escritura anticipada (WAL) debido a que las transacciones activas llevan mucho tiempo ejecutándose. Para obtener información sobre la vista de pg_replication_slots, consulte pg_replication_slots en la documentación de PostgreSQL 15.4.

  • Utilice la siguiente consulta para obtener una lista de todas las consultas activas de la base de datos, junto con la información relacionada:

    SELECT pid, age(clock_timestamp(), query_start), usename, query FROM pg_stat_activity WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' ORDER BY query_start desc;

    En los resultados de la consulta, el campo age muestra la duración activa de cada consulta, que puede utilizar para identificar las consultas de larga duración.

Carga de trabajo alta en el origen

Si PostgreSQL de origen tiene una carga de trabajo alta, compruebe lo siguiente para reducir la latencia:

  • Es posible que experimente una latencia alta al utilizar el complemento test_decoding al migrar un subconjunto de tablas de la base de datos de origen con un valor alto de transacciones por segundo (TPS). Esto se debe a que el complemento test_decoding envía todos los cambios de la base de datos a la instancia de replicación, que luego DMS filtra en función de la asignación de tablas de la tarea. Los eventos de las tablas que no forman parte de la asignación de tablas de la tarea pueden aumentar la latencia del origen.

  • Compruebe el rendimiento de TPS mediante uno de los métodos siguientes.

    • Para las fuentes de Aurora PostgreSQL, utilice la métrica. CommitThroughput CloudWatch

    • Para ejecutar PostgreSQL en Amazon RDS o en las instalaciones, utilice la siguiente consulta con un cliente PSQL de la versión 11 o superior (pulse enter durante la consulta para avanzar los resultados):

      SELECT SUM(xact_commit)::numeric as temp_num_tx_ini FROM pg_stat_database; \gset select pg_sleep(60); SELECT SUM(xact_commit)::numeric as temp_num_tx_final FROM pg_stat_database; \gset select (:temp_num_tx_final - :temp_num_tx_ini)/ 60.0 as "Transactions Per Second";
  • Para reducir la latencia al usar el complemento test_decoding, considere usar el complemento pglogical en su lugar. A diferencia del complemento test_decoding, el complemento pglogical filtra los cambios del registro de escritura previa (WAL) en el origen y solo envía los cambios relevantes a la instancia de replicación. Para obtener información sobre cómo usar el complemento pglogical con AWS DMS, consulte Configuración del complemento pglogical.

Alto rendimiento de red

Es posible que la replicación utilice un ancho de banda de la red alto cuando utilice el complemento test_decoding, especialmente durante transacciones de gran volumen. Esto se debe a que el complemento test_decoding procesa los cambios y los convierte en un formato legible para las personas que es más grande que el formato binario original.

Para mejorar el rendimiento, considere usar el complemento pglogical en su lugar, que es un complemento binario. A diferencia del complemento test_decoding, el complemento pglogical genera una salida en formato binario, lo que resulta en cambios en el flujo del registro de escritura previa (WAL) comprimido.

Derrame archivos en Aurora PostgreSQL

En la versión 13 y posteriores de PostgreSQL, logical_decoding_work_mem el parámetro determina la asignación de memoria para la decodificación y la transmisión. Para obtener más información sobre el logical_decoding_work_mem parámetro, consulte Consumo de recursos en PostgreSQL en la documentación de PostgreSQL 13.13.

La replicación lógica acumula los cambios de todas las transacciones de la memoria hasta que esas transacciones se confirmen. Si la cantidad de datos almacenados en todas las transacciones supera la cantidad especificada en el parámetro de la base de datoslogical_decoding_work_mem, el DMS transfiere los datos de la transacción al disco para liberar memoria para nuevos datos de decodificación.

Las transacciones de larga duración, o muchas subtransacciones, pueden provocar que el DMS consuma más memoria de decodificación lógica. Este aumento del uso de memoria hace que el DMS cree archivos indirectos en el disco, lo que provoca una alta latencia de origen durante la replicación.

Para reducir el impacto de un aumento en la carga de trabajo de origen, haga lo siguiente:

  • Reduzca las transacciones de larga duración.

  • Reduzca el número de subtransacciones.

  • Evite realizar operaciones que generen una gran cantidad de registros, como eliminar o actualizar una tabla completa en una sola transacción. En su lugar, realice las operaciones en lotes más pequeños.

Puede utilizar las siguientes CloudWatch métricas para supervisar la carga de trabajo en la fuente:

  • TransactionLogsDiskUsage: La cantidad de bytes que ocupa actualmente la WAL lógica. Este valor aumenta de forma monótona si las ranuras de replicación lógica no pueden seguir el ritmo de las nuevas escrituras o si alguna transacción de larga duración impide la recolección de archivos antiguos como basura.

  • ReplicationSlotDiskUsage: La cantidad de espacio en disco que utilizan actualmente las ranuras de replicación lógica.

Puede reducir la latencia de origen ajustando el logical_decoding_work_mem parámetro. El valor predeterminado de este parámetro es 64 MB. Este parámetro limita la cantidad de memoria utilizada por cada conexión de replicación de streaming lógico. Recomendamos establecer el logical_decoding_work_mem valor significativamente más alto que el work_mem valor para reducir la cantidad de cambios decodificados que el DMS escribe en el disco.

Te recomendamos que compruebes periódicamente si hay archivos incompletos, especialmente durante los períodos de intensa actividad de migración o latencia. Si el DMS crea un número significativo de archivos indirectos, esto significa que la decodificación lógica no funciona de manera eficiente, lo que puede aumentar la latencia. Para mitigar esta situación, aumente el logical_decoding_work_mem valor del parámetro.

Puede comprobar el desbordamiento de transacciones actual con la aurora_stat_file función. Para obtener más información, consulte Ajustar la memoria de trabajo para la decodificación lógica en la Guía para desarrolladores de Amazon Relational Database Service.