Solución de problemas de Postgre Endpoint SQL - AWS Database Migration Service
Transacciones de larga duración en el origenCarga de trabajo alta en el origenAlto rendimiento de redDerrame archivos en Aurora Postgre SQL

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 Postgre Endpoint SQL

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

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 DMS CDC eventos y transacciones 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 restart_lsn valor no se actualiza, es probable que Postgre SQL no pueda publicar Write Ahead Logs (WALs) debido a que las transacciones activas llevan mucho tiempo ejecutándose. Para obtener información sobre la pg_replication_slots vista, consulte pg_replication_slots en la documentación de Postgre 15.4. SQL

  • 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 su Postgre de origen SQL tiene una carga de trabajo elevada, compruebe lo siguiente para reducir la latencia:

  • Es posible que experimente una latencia alta al usar el test_decoding complemento 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 test_decoding complemento envía todos los cambios de la base de datos a la instancia de replicación, que DMS luego los 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 TPS el rendimiento mediante uno de los siguientes métodos.

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

    • Para que Postgre SQL se ejecute en Amazon RDS o de forma local, utilice la siguiente consulta con un PSQL cliente de versión 11 o superior (presione enter durante la consulta para avanzar en 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 test_decoding complemento, el pglogical complemento filtra los cambios que se escriben previamente en el registro (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 pglogical complemento con AWS DMS, consulteConfiguració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 test_decoding complemento, el pglogical complemento genera una salida en formato binario, lo que resulta en cambios de flujo comprimidos de write ahead log (WAL).

Derrame archivos en Aurora Postgre SQL

En la SQL versión 13 y posteriores de Postgre, el logical_decoding_work_mem 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 Postgre en la documentación de Postgre SQL 13.13. SQL

La replicación lógica acumula los cambios de todas las transacciones en 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, DMS los transfiere al disco para liberar memoria para nuevos datos de decodificación.

Las transacciones de larga duración, o muchas subtransacciones, pueden provocar un DMS consumo mayor de memoria de decodificación lógica. Este aumento del uso de memoria provoca la DMS creación de archivos innecesarios 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: el número de bytes que ocupa actualmente la lógicaWAL. 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. Se recomienda establecer el logical_decoding_work_mem valor significativamente más alto que el work_mem valor para reducir la cantidad de cambios decodificados que se DMS escriben 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 DMS está creando 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 valor del logical_decoding_work_mem 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.