後續SQL端點疑難排解 - AWS Database Migration Service
在來源上長時間執行的交易來源工作負載很大高網路輸送量在 Aurora 波斯特里溢出文件 SQL

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

後續SQL端點疑難排解

本節包含 Postgre SQL 特定的複寫案例。

在來源上長時間執行的交易

當來源資料庫中有長時間執行的交易 (例如單一交易中的幾千個插入) 時，DMSCDC事件和交易計數器在交易完成之前不會增加。此延遲可能會導致延時問題，而您可以使用 CDCLatencyTarget 指標來測量這些問題。

若要檢閱長時間執行的交易，請執行下列其中一項：

  • 使用 pg_replication_slots 檢視。如果restart_lsn值未更新，則 Postgre 可能因為長時間執行SQL的作用中交易而無法釋放「預寫記錄」(WALs)。如需pg_replication_slots檢視的相關資訊，請參閱下載 15.4 文件中的 pg_複製插槽。SQL

  • 使用下列查詢來傳回資料庫中所有使用中查詢的清單，以及相關資訊：

    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;

    在查詢結果中，age 欄位會顯示每個查詢的作用中持續時間，您可以使用此值來識別長時間執行的查詢。

來源工作負載很大

如果您的來源 Postgre SQL 具有很高的工作負載，請檢查以下內容以減少延遲：

  • 在使用test_decoding外掛程式時，從來源資料庫遷移具有高每秒交易 (TPS) 值的資料表子集時，您可能會遇到很高的延遲。這是因為test_decoding外掛程式會將所有資料庫變更傳送至複寫執行個體，DMS然後根據工作的表格對應進行篩選。不屬於任務資料表對應一部分的資料表事件可能會增加來源延時。

  • 使用下列其中一種方法檢查TPS輸送量。

    • 對於 Aurora 波斯特SQL來源，請使用CommitThroughput CloudWatch 量度。

    • 對於在 Amazon RDS 或現場部署上SQL執行的 Postgre，請使用 11 或更高版本的用PSQL戶端使用以下查詢 (在查詢enter期間按下以推進結果)：

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

  • 為了減少使用 test_decoding 外掛程式時的延時，請考慮改用 pglogical 外掛程式。與test_decoding外掛程式不同，pglogical外掛程式會篩選預先在來源處寫入 log (WAL) 變更，並且只會將相關變更傳送至複寫執行個體。如需搭配使用pglogical外掛程式的詳細資訊 AWS DMS，請參閱設定 pglogical 外掛程式。

高網路輸送量

使用 test_decoding 外掛程式時 (尤其是在交易量很大的期間)，複寫所佔的網路頻寬可能很多。這是因為 test_decoding 外掛程式會處理變更，並將其轉換為比原始二進位格式更大的人類可讀格式。

為了改善效能，請考慮改用 pglogical 外掛程式，也就是二進位外掛程式。與test_decoding插件不同，該pglogical插件生成二進制格式輸出，從而導致壓縮寫入 ahead log（WAL）流更改。

在 Aurora 波斯特里溢出文件 SQL

在 Postgre SQL 版本 13 及更高版本中，logical_decoding_work_mem參數決定用於解碼和流式傳輸的內存分配。如需有關參數的詳細資訊，請logical_decoding_work_mem參閱下一頁 SQL13.13 文件中的 Postgre SQL 中的資源消耗。

邏輯複寫會累積記憶體中所有交易的變更，直到這些交易認可為止。如果所有交易中儲存的資料量超過資料庫參數指定的數量logical_decoding_work_mem，則會將交易資料DMS溢出至磁碟以釋放記憶體以供新解碼資料使用。

長時間執行的交易或許多子交易可能會導致DMS消耗更多的邏輯解碼記憶體。如此增加的記憶體使用會導致磁碟上DMS建立溢滿檔案，進而在複寫期間造成較高的來源延遲。

若要減少來源工作負載增加所造成的影響，請執行下列動作：

  • 減少長時間執行的交易。

  • 減少子交易的數量。

  • 避免執行會產生大量記錄成組分解的作業，例如刪除或更新單一交易中的整個資料表。請改為以較小的批次執行作業。

您可以使用下列 CloudWatch 指標來監視來源上的工作負載：

  • TransactionLogsDiskUsage：邏輯目前佔用的字節數WAL。如果邏輯複寫插槽無法跟上新寫入的速度，或者如果任何長時間執行的交易阻止了舊檔案的記憶體回收，則此值會單調增加。

  • ReplicationSlotDiskUsage：邏輯複製插槽目前使用的磁碟空間量。

您可以透過調整logical_decoding_work_mem參數來減少來源延遲。此參數的預設值為 64 MB。此參數會限制每個邏輯串流複寫連線所使用的記憶體數量。我們建議您將logical_decoding_work_mem值設定為明顯大於該work_mem值，以減少DMS寫入磁碟的解碼變更量。

我們建議您定期檢查溢出檔案，特別是在大量移轉活動或延遲期間。如果DMS正在建立大量溢出檔案，這表示邏輯解碼無法有效運作，這可能會增加延遲。為了減輕這種情況，請增加logical_decoding_work_mem參數值。

您可以使用該aurora_stat_file功能檢查當前事務溢出。如需詳細資訊，請參閱 Amazon Relational Database Service 開發人員指南中的調整邏輯解碼的工作記憶體。