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.
Esta sección contiene escenarios de replicación específicos de PostgreSQL.
Temas
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 elrestart_lsnvalor no se actualiza, es probable que PostgreSQL no pueda publicar Write Ahead Logs WALs () debido a que las transacciones activas llevan mucho tiempo ejecutándose. Para obtener información sobre la vista depg_replication_slots, consulte pg_replication_slotsen 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
agemuestra 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_decodingal 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 complementotest_decodingenví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.
CommitThroughputCloudWatchPara 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
enterdurante 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 complementopglogicalen su lugar. A diferencia del complementotest_decoding, el complementopglogicalfiltra 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 el uso delpglogicalcomplemento 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.
Archivos de volcado en Aurora PostgreSQL
En PostgreSQL versión 13 y posteriores, el parámetro logical_decoding_work_mem determina la asignación de memoria para la descodificación y la transmisión. Para obtener más información sobre el parámetro logical_decoding_work_mem, consulte Resource Consumption in PostgreSQL
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 por el parámetro logical_decoding_work_mem de la base de datos, DMS vuelca los datos de la transacción al disco a fin de liberar memoria para los nuevos datos de descodificación.
Las transacciones de larga duración, o un número elevado de subtransacciones, pueden provocar que DMS consuma más memoria de descodificación lógica. Este aumento del uso de la memoria hace que DMS cree archivos de volcado 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.
Puedes usar las siguientes CloudWatch métricas para monitorear la carga de trabajo en la fuente:
TransactionLogsDiskUsage: cantidad de bytes que ocupa actualmente el registro de escritura previa. 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 recopilación de elementos no utilizados en archivos más antiguos.ReplicationSlotDiskUsage: cantidad de espacio en disco que usan actualmente las ranuras de replicación lógica.
Puede reducir la latencia de origen si ajusta el parámetro logical_decoding_work_mem. El valor predeterminado para este parámetro es 64 MB. Este parámetro limita la cantidad de memoria que utiliza cada conexión de replicación de transmisión lógica. Recomendamos establecer logical_decoding_work_mem en un valor significativamente más alto que el valor work_mem para reducir la cantidad de cambios descodificados que DMS escribe en el disco.
Se recomienda comprobar de forma periódica si hay archivos de volcado, sobre todo durante periodos de intensa actividad de migración o latencia. Si DMS crea un número significativo de archivos de volcado significa que la descodificación lógica no funciona de manera eficaz, lo que puede aumentar la latencia. Para mitigar esta situación, aumente el valor del parámetro logical_decoding_work_mem.
Puede comprobar el desbordamiento actual de las transacciones con la función aurora_stat_file. Para obtener más información, consulte Ajuste de la memoria de trabajo para la descodificación lógica en la Guía para desarrolladores de Amazon Relational Database Service.
