View a markdown version of this page

Risoluzione dei problemi relativi all'endpoint PostgreSQL - AWS Servizio di migrazione del database
Long-running transazione all'origineCarico di lavoro elevato sull'origineVelocità di trasmissione effettiva della rete elevataSpargi i file in Aurora PostgreSQL

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risoluzione dei problemi relativi all'endpoint PostgreSQL

In questa sezione vengono descritti gli scenari di replica specifici di PostgreSQL.

Long-running transazione all'origine

Quando nel database di origine sono presenti transazioni di lunga durata, ad esempio migliaia di inserimenti in una singola transazione, i contatori degli eventi e delle transazioni DMS CDC non aumentano fino al completamento della transazione. Questo ritardo può causare problemi di latenza che è possibile misurare utilizzando la metrica CDCLatencyTarget.

Per esaminare le transazioni di lunga durata, effettua una delle operazioni riportate di seguito:

  • Usa la vista pg_replication_slots. Se il valore restart_lsn non si aggiorna, è probabile che PostgreSQL non sia in grado di rilasciare i log WAL (Write Ahead Log) a causa di transazioni attive di lunga durata. Per informazioni sulla vista pg_replication_slots, consulta pg_replication_slots nella documentazione di PostgreSQL 15.4.

  • Utilizza la seguente query per ottenere l'elenco di tutte le query attive nel database, insieme alle informazioni correlate: 

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

    Nei risultati delle query, il campo age mostra la durata attiva di ogni query, che è possibile utilizzare per identificare le query di lunga durata.

Carico di lavoro elevato sull'origine

Se l'origine PostgreSQL ha un carico di lavoro elevato, controlla quanto segue per ridurre la latenza:

  • Potresti riscontrare un'elevata latenza quando utilizzi il plug-in test_decoding durante la migrazione di un sottoinsieme di tabelle dal database di origine con un valore di transazioni al secondo (TPS) elevato. Questo perché il plug-in test_decoding invia tutte le modifiche del database all'istanza di replica, che DMS filtra in base alla mappatura delle tabelle dell'attività. Gli eventi delle tabelle che non fanno parte della mappatura delle tabelle dell'attività possono aumentare la latenza della origine.

  • Verifica la velocità di trasmissione effettiva TPS utilizzando uno dei metodi riportati di seguito.

    • Per i sorgenti Aurora PostgreSQL, usa la metrica. CommitThroughput CloudWatch

    • Per PostgreSQL in esecuzione su Amazon RDS o on-premise, usa la seguente query con un client PSQL versione 11 o successiva (premi enter durante la query per ottenere i risultati):

      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";

  • Per ridurre la latenza quando usi il plug-in test_decoding, puoi considerare di utilizzare il plug-in pglogical. A differenza del plug-in test_decoding, il plug-in pglogical filtra le modifiche WAL all'origine e invia solo le modifiche pertinenti all'istanza di replica. Per informazioni sull'utilizzo del plugin con, consultate. pglogical AWS DMSConfigurazione del plug-in pglogical

Velocità di trasmissione effettiva della rete elevata

La replica potrebbe richiedere un elevato utilizzo della larghezza di banda della rete quando si utilizza il plug-in test_decoding, specialmente durante transazioni con volumi elevati. Questo perché il plug-in test_decoding elabora le modifiche e le converte in un formato leggibile dall'uomo più grande del formato binario originale.

Per migliorare le prestazioni, considera di utilizzare pglogical che è un plug-in binario. A differenza del plug-in test_decoding, il plug-in pglogical genera un output in formato binario, con conseguenti modifiche del flusso WAL compresso.

Spargi i file in Aurora PostgreSQL

In PostgreSQL versione 13 e successive, il logical_decoding_work_mem parametro determina l'allocazione di memoria per la decodifica e lo streaming. Per ulteriori informazioni sul logical_decoding_work_mem parametro, vedere Consumo di risorse in PostgreSQL nella documentazione di PostgreSQL 13.13. https://www.postgresql.org/docs/13/

La replica logica accumula le modifiche per tutte le transazioni in memoria fino al commit di tali transazioni. Se la quantità di dati archiviati in tutte le transazioni supera la quantità specificata dal parametro del databaselogical_decoding_work_mem, DMS trasferisce i dati della transazione su disco per liberare memoria per nuovi dati di decodifica.

Le transazioni di lunga durata, o molte sottotransazioni, possono far sì che il DMS consumi una maggiore memoria di decodifica logica. Questo maggiore utilizzo della memoria fa sì che il DMS crei file di spill su disco, con conseguente elevata latenza all'origine durante la replica.

Per ridurre l'impatto di un aumento del carico di lavoro di origine, effettuate le seguenti operazioni:

  • Riduci le transazioni di lunga durata.

  • Riduci il numero di sottotransazioni.

  • Evita di eseguire operazioni che generano una grande quantità di record di log, come l'eliminazione o l'aggiornamento di un'intera tabella in una singola transazione. Eseguite invece le operazioni in batch più piccoli.

Puoi utilizzare le seguenti CloudWatch metriche per monitorare il carico di lavoro sull'origine:

  • TransactionLogsDiskUsage: il numero di byte attualmente occupati dal WAL logico. Questo valore aumenta in modo monotono se gli slot di replica logica non sono in grado di tenere il passo con il ritmo delle nuove scritture o se eventuali transazioni di lunga durata impediscono la raccolta indesiderata di file più vecchi.

  • ReplicationSlotDiskUsage: la quantità di spazio su disco attualmente utilizzata dagli slot di replica logica.

È possibile ridurre la latenza di origine regolando il parametro. logical_decoding_work_mem Il valore predefinito per questo parametro è 64 MB. Questo parametro limita la quantità di memoria utilizzata da ciascuna connessione logica di replica in streaming. Si consiglia di impostare un logical_decoding_work_mem valore significativamente più alto del work_mem valore per ridurre la quantità di modifiche decodificate che DMS scrive su disco.

Ti consigliamo di controllare periodicamente la presenza di file fuoriusciti, in particolare durante i periodi di forte attività di migrazione o latenza. Se DMS sta creando un numero significativo di file di fuoriuscita, significa che la decodifica logica non funziona in modo efficiente, il che può aumentare la latenza. Per ovviare a questo problema, aumentate il valore del parametro. logical_decoding_work_mem

È possibile controllare l'overflow della transazione corrente con la aurora_stat_file funzione. Per ulteriori informazioni, consulta Adjusting working memory for logical decoding nella Amazon Relational Database Service Developer Guide.