複製延遲時間

本頁說明如何排解及修正 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 執行作業。

此外，由於 DDL 陳述式 (例如 CREATE INDEX、ALTER INDEX 和 INDEX MAINTENANCE) 可能會產生大量交易記錄，因此可能會導致複製延遲。

備用資源超載

如果讀取副本收到的查詢過多，複製作業可能會遭到封鎖。建議您將讀取作業分散到多個備用資源，以減輕每個備用資源的負載。

為避免查詢量激增，建議您在應用程式邏輯中或代理層 (如有) 中，限制複本讀取查詢。

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

單體式主要資料庫

建議您將主要資料庫進行垂直 (或水平) 分割，以免一或多個延遲的資料表拖慢其他所有資料表。

監控複製延遲時間

您可以使用 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，則表示複製作業正常。

後續步驟：