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à.
In questa sezione vengono descritti gli scenari di replica specifici di PostgreSQL.
Argomenti
Transazione di lunga durata sull'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 ilrestart_lsnvalore non si aggiorna, è probabile che PostgreSQL non sia in grado di rilasciare Write Ahead Logs WALs () a causa di transazioni attive di lunga durata. Per informazioni sulla vistapg_replication_slots, consulta pg_replication_slotsnella 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, query FROM pg_stat_activity WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' ORDER BY query_start desc;Nei risultati delle query, il campo
agemostra 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_decodingdurante la migrazione di un sottoinsieme di tabelle dal database di origine con un valore di transazioni al secondo (TPS) elevato. Questo perché il plug-intest_decodinginvia 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.
CommitThroughputCloudWatchPer PostgreSQL in esecuzione su Amazon RDS o on-premise, usa la seguente query con un client PSQL versione 11 o successiva (premi
enterdurante 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-inpglogical. A differenza del plug-intest_decoding, il plug-inpglogicalfiltra le modifiche WAL all'origine e invia solo le modifiche pertinenti all'istanza di replica. Per informazioni sull'utilizzo del plugin con, consulta.pglogicalAWS 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.
Versare file in Aurora PostgreSQL
Nella versione 13 e successive di PostgreSQL, il parametro determina l'allocazione della memoria per logical_decoding_work_mem la decodifica e lo streaming. Per ulteriori informazioni sul logical_decoding_work_mem parametro, vedere Consumo di risorse in PostgreSQL nella documentazione di PostgreSQL
La replica logica accumula le modifiche per tutte le transazioni in memoria fino al completamento 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 i nuovi dati di decodifica.
Le transazioni a esecuzione prolungata, o molte sottotransazioni, possono comportare un maggiore consumo di memoria di decodifica logica da parte del DMS. Questo maggiore utilizzo della memoria fa sì che DMS crei file di fuoriuscita su disco, il che causa un'elevata latenza del codice sorgente durante la replica.
Per ridurre l'impatto di un aumento del carico di lavoro di origine, procedi come segue:
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. Esegui invece operazioni in batch più piccoli.
Puoi utilizzare le seguenti CloudWatch metriche per monitorare il carico di lavoro sulla fonte:
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 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 della sorgente ottimizzando il parametro. logical_decoding_work_mem Il valore predefinito per questo parametro è 64 MB. Questo parametro limita la quantità di memoria utilizzata da ogni connessione di replica in streaming logico. Si consiglia di impostare un logical_decoding_work_mem valore significativamente più alto rispetto al work_mem valore per ridurre la quantità di modifiche decodificate che DMS scrive su disco.
Si consiglia di verificare periodicamente la presenza di file fuoriusciti, in particolare durante i periodi di intensa attività di migrazione o di latenza. Se DMS sta creando un numero significativo di file di spill, significa che la decodifica logica non funziona in modo efficiente, il che può aumentare la latenza. Per mitigare questo problema, aumentate il valore del parametro. logical_decoding_work_mem
È possibile controllare l'attuale eccesso di transazioni con la aurora_stat_file funzione. Per ulteriori informazioni, consulta Adjusting working memory for logical decoding nella Amazon Relational Database Service Developer Guide.
