AlloyDB 的架構將運算和儲存分開，因此兩者可獨立調整資源。雖然主要執行個體和讀取集區執行個體共用相同的底層儲存空間，但複製作業仍是維持唯讀副本資料一致性和最新狀態的重要程序。在 AlloyDB 叢集中，寫入作業會在主要執行個體上執行，然後記錄在預寫記錄檔 (WAL) 中。然後複製到讀取集區節點。如要排解任何問題，請務必瞭解這項複製程序的兩個主要步驟：
- WAL 清除：預寫記錄檔 (WAL) 包含資料庫的變更，會從主要執行個體傳送至副本。副本會立即將 WAL 永久儲存至磁碟。
- WAL 套用 (或重播)：在副本上重播永久 WAL，也就是將變更套用至副本的快取。
上述任一步驟發生延遲，都會導致所謂的複製延遲。不過，這個詞彙可能不夠明確。更精確地說，我們可以將複製延遲時間細分為下列兩個部分：
- 清除或網路延遲：這是 WAL 清除步驟中的延遲。也就是 WAL 從主要執行個體傳送並保存在副本所需的時間。
- 重播延遲：WAL 套用步驟的延遲時間。這是指副本套用 WAL 變更所需的時間。
您應更關注清除延遲還是重播延遲，取決於您的用途：
- 如果您擔心資料遺失 (例如次要叢集)，請務必密切注意清除延遲。如果 WAL 尚未保存在副本上，且主要執行個體當機，則從副本的角度來看，變更會遺失。
- 如果您擔心唯讀副本的資料是否為最新狀態，請務必密切注意清除延遲和重播延遲。無論是傳輸或套用 WAL，只要任一步驟延遲，唯讀副本就會出現過時資料。
檢查複製延遲
您可以在 Google Cloud 控制台監控讀取集區執行個體的複製延遲時間。詳情請參閱「監控執行個體」。您也可以使用「建立指標門檻警告政策」，監控讀取集區複製作業延遲時間，並在達到指定門檻時收到警告。
複製延遲的常見原因
以下是複製延遲的常見原因和解決方法。
資源爭用
如果系統資源 (例如 CPU 和記憶體) 發生爭用，也可能導致複製速度變慢。
- CPU 和記憶體壓力：讀取集區執行個體的讀取工作負載過重，可能會與複製程序爭奪 CPU 和記憶體資源。您可以在 Google Cloud 控制台查看執行個體的 CPU 和記憶體用量。如果資源使用率偏高，可能需要向上擴充或水平擴展讀取集區執行個體。
- 讀取集區節點大小：如果主要執行個體遠大於讀取集區節點，產生的複製記錄速度可能會超過讀取節點的處理速度。在這種情況下，建議使用較大的讀取節點，為副本提供更多資源。
複製衝突
讀取查詢有時會保留複製程序正在等待的資源，因此可能會封鎖複製程序。如果讀取查詢鎖定重播程序需要更新的資料庫物件，就會發生鎖定衝突。如果查詢在重播需要修改的資料緩衝區上保留固定，就會導致緩衝區固定衝突。在這兩種情況下，重播都會遭到封鎖，直到查詢釋出資源為止。
如要找出這些衝突，請在 Logs Explorer 的 postgres.log 檔案中尋找 canceling statement due to conflict with recovery 訊息。
如要減少複製衝突，您可以採取下列做法：
減少
max_standby_streaming_delay：這項參數會決定重播程序等待多久後，會取消阻礙重播的查詢。預設值為 30 秒。降低這個值有助於縮短複製延遲時間，但也可能導致更多讀取查詢遭到取消。您可以調整這項參數，找出最適合應用程式的平衡點。避免長時間執行的查詢：在讀取集區中長時間執行查詢，可能會增加複製衝突的可能性。建議將執行時間較長的查詢移至其他讀取集區，在該集區中，複製延遲時間較短並非關鍵。
確認
alloydb.promote_cancel_to_terminate已啟用：這個旗標預設為啟用，可讓 AlloyDB 強制終止未回應取消要求的查詢後端。這有助於避免無回應的後端長時間阻擋複製作業。
根據延遲時間限制讀取查詢
AlloyDB 也可讓您使用 google_storage.log_replay_throttle_read_transactions 旗標，控制是否要對讀取節點啟用讀取查詢延遲限制。如果參數設為預設值 on，當複製延遲時間超過一秒時，系統會暫停啟動新查詢，並暫停讀取新緩衝區最多一分鐘，藉此限制讀取查詢。這項功能會做出取捨，為重播作業提供更多資源，加快追上進度，進而改善複製延遲，但可能會增加讀取查詢延遲。如果應用程式對複製延遲不敏感，您可以將 google_storage.log_replay_throttle_read_transactions 設為 off，優先縮短讀取查詢延遲時間。
您可以透過下列方法，監控查詢節流的影響：
記錄：在 Logs Explorer 中搜尋
postgres.log檔案中的Delayed.*due to replica lag訊息，找出查詢因副本延遲而延遲的時間。Cloud Monitoring：使用
alloydb.googleapis.com/instance/postgresql/wait_count指標，查看有多少查詢遭到節流。方法是依wait_event_name篩選指標，然後找出HighLagThrottle。如要查看查詢受到限制的總時間，可以使用alloydb.googleapis.com/instance/postgresql/wait_time指標搭配相同篩選器。詳情請參閱「系統洞察指標參考資料」。查詢洞察：在「查詢洞察」資訊主頁中，如果查詢因複製延遲而受到節流，「執行中的查詢」檢視畫面會在「等待事件」欄中顯示
HighLagThrottle等待事件。詳情請參閱「監控執行中的查詢」。
工作量大
如果主要執行個體的寫入工作負載突然增加，可能會產生大量複製記錄，導致讀取集區執行個體不堪負荷，並造成複製作業延遲。您可以在 Google Cloud 控制台監控主要執行個體的寫入流量。
因 ScaNN 索引建構作業而產生大量預寫記錄檔
建構 ScaNN 索引時，可能會產生大量全頁寫入 WAL 記錄。這可能會導致從主要執行個體傳送 WAL 記錄至讀取執行個體時發生延遲。如果複製延遲時間與在大量嵌入上建構 ScaNN 索引有關，您可以在主要執行個體上啟用 wal_compression，以節省網路和磁碟 IO，並減少複製延遲時間。這可能會產生少量的額外 CPU 負擔。
wal_compression 只會壓縮整頁寫入記錄，對大多數 WAL 記錄沒有影響。變更這個旗標時，不需重新啟動，也不會造成停機。
大額交易
如果交易會修改大量資料列 (例如刪除多個資料表或大型資料表)，就會在預寫記錄檔 (WAL) 中產生極大的 COMMIT 或 ABORT 記錄。這些記錄可能需要相當長的時間，才能在讀取集區節點上重播，導致複製延遲時間暫時增加。
為避免這種情況，請勿在單一交易中執行超大型批次作業，例如刪除。建議您將這些作業拆成較小、較頻繁的交易。這可縮減個別 COMMIT 和 ABORT 記錄的大小，讓複製串流保持流暢，並減少複製延遲時間高峰。
排解導致無法複製的問題
必須有正常運作的讀取集區，才會發生複製延遲。下列問題可能會導致無法建立讀取集區，或造成唯讀副本停止運作，進而導致複製作業完全無法執行。
讀取集區執行個體當機
在 PostgreSQL 14 中，如果主要執行個體上的長時間執行交易含有大量專屬鎖定，可能會導致唯讀副本的記憶體用量增加，最終可能導致讀取集區執行個體當機。
如要解決這個問題，可以終止主要執行個體上長時間執行的交易。
調整執行個體大小對複製延遲時間的影響
AlloyDB 儲存空間架構可確保讀取集區清除延遲時間不受執行個體大小調整影響。不過，重播功能不適用這項規定。副本的重播能力取決於其負載。如果您更新執行個體設定 (例如調整大小)，視工作負載而定，副本在作業完成時可能不會有完全預熱的快取。這表示重播或處理尚未快取的記錄時，速度會較慢。在這種情況下，重播延遲時間可能會暫時增加。