複製延遲時間

本頁說明如何排解及修正 Cloud SQL 唯讀副本的複製延遲問題。

總覽

Cloud SQL 讀取備用資源使用 SQL Server Always-On 可用性群組進行複製。變更會寫入主要執行個體的交易記錄。主要執行個體會將交易轉送至任何次要副本執行個體，並套用變更。使用的可用性模式為非同步提交模式。

複製延遲可能發生在下列情況：

  • 主要執行個體無法快速將變更傳送至副本。
  • 副本無法及時接收變更。
  • 副本無法及時套用變更。
您可以使用 network_lag metric 監控上述前兩個原因。第三個原因可透過 seconds_behind_master 指標觀察。如果 seconds_behind_master 指標偏高，表示副本無法及時套用複製變更。下方的「監控複寫延遲」一節將說明這些指標。

最佳化查詢和結構定義

本節提供一些常見的查詢和結構定義最佳化建議，可提升複寫效能。

唯讀副本中長時間執行的查詢

備用資源中長時間執行的查詢可能會封鎖 Cloud SQL 的複製作業。您可能想為線上交易處理 (OLTP) 和線上分析處理 (OLAP) 分別建立副本，並只將長時間執行的查詢傳送至 OLAP 副本。

因 DDL 而鎖定

資料定義語言 (DDL) 指令 (例如 ALTER TABLE 和 CREATE INDEX) 可能會因獨占鎖定而導致副本出現複製延遲。為避免鎖定爭用，請考慮在副本的查詢負載較低時，排定 DDL 執行作業。

此外，CREATE INDEX、ALTER INDEX 和 INDEX MAINTENANCE 等 DDL 陳述式可能會產生大量交易記錄，導致複寫延遲。

過載的副本

如果唯讀副本收到太多查詢，複製作業可能會遭到封鎖。 請考慮將讀取作業分散到多個備用資源，以減輕每個資源的負擔。

為避免查詢量暴增，請考慮在應用程式邏輯或 Proxy 層 (如有使用) 中，調節副本讀取查詢。

如果主要執行個體上的活動量突然暴增，請考慮分散更新作業。

單體式主要資料庫

考慮垂直 (或水平) 分片主要資料庫，避免一或多個延遲資料表拖累所有其他資料表。

監控複製延遲

您可以使用 replica_lag 和 network_lag 指標監控複製延遲，並判斷延遲原因是否在於主要資料庫、網路或副本。

指標說明
複製延遲
(cloudsql.googleapis.com/database/replication/seconds_behind_master)

備用資源狀態落後主要執行個體狀態的秒數。這是指次要資料庫中最後一個重做記錄的時間戳記，與主要資料庫中最後一個傳送記錄的時間戳記之間的差異。
網路延遲
(cloudsql.googleapis.com/database/replication/network_lag)

備用資源上最後收到的記錄項目時間戳記，與主要資源上最後傳送的記錄項目時間戳記之間的差異。

確認複製設定

如要確認複製功能是否正常運作，請檢查主要執行個體上的 cloudsql.googleapis.com/database/replication/state 指標值。如果狀態為 Running，則代表複製作業正常。

後續情況：