複製延遲時間

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

總覽

Cloud SQL 唯讀備用資源使用 PostgreSQL 串流複製。變更會寫入主要執行個體中的預寫記錄 (WAL)。WAL sender 會將 WAL 傳送至副本中的 WAL receiver，並套用這些 WAL。

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

  • 主要執行個體無法快速將變更傳送至副本。
  • 副本無法及時接收變更。
  • 副本無法及時套用變更。
您可以使用 network_lag 指標監控上述前兩個原因。 第三個是透過 replica_lag 指標觀察到的。高 replica_lag 表示副本無法快速套用複製變更。您可以透過 replica_byte_lag 指標觀察總延遲時間，該指標含有標籤，可指出更多詳細資料。下方的「監控複寫延遲」一節將說明這些指標。

確保備用資源已充分佈建

如果備用資源執行個體比主要執行個體小 (例如 vCPU 和記憶體較少)，可能會發生複製延遲。與較大的主要執行個體相比，較小的副本也可能具有不同的預設設定標記。建議副本執行個體至少要與主要執行個體一樣大，才能有足夠的資源處理複寫負載。

備用資源的 CPU 使用率偏高也可能導致複製延遲。如果副本的 CPU 使用率偏高 (例如超過 90%)，請考慮增加副本的 CPU 容量。

您可以使用 SHOW ALL 指令查看副本和主要執行個體設定，並比較兩者差異。

最佳化查詢和結構定義

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

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

備用資源中長時間執行的查詢可能會封鎖 Cloud SQL 的複製作業。如果複製作業嘗試將變更 (例如來自 VACUUM 作業) 套用至備用資源上查詢正在讀取的資料列，就可能發生這種情況。

您可能想為線上交易處理 (OLTP) 和線上分析處理 (OLAP) 分別建立副本，並只將長時間執行的查詢傳送至 OLAP 副本。

為解決長時間交易導致的複製延遲或封鎖問題，建議採取下列做法：

  • 調整待機延遲旗標。max_standby_archive_delay 和 max_standby_streaming_delay 旗標會控管副本在取消與複製作業衝突的待命查詢前，等待的時間長度。合理值通常約為 30 至 60 秒。您可以查看「查詢衝突」pg_stat_database_conflicts，取得查詢衝突的洞察資訊。
  • 啟用 hot_standby_feedback 標記。將副本中的 hot_standby_feedback 旗標設為 on，有助於延遲主要副本的清除作業。不過，這可能會導致主要資料表膨脹，因此需要權衡利弊。

詳情請參閱 PostgreSQL 說明文件。

網路延遲過高

網路延遲時間過長表示主要或副本伺服器無法快速傳送/接收 WAL 記錄。可能原因如下：

  • 跨區域複製。在不同區域之間複製資料可能會導致網路延遲時間較長。
  • 主要 CPU 使用率過高。如果主要 CPU 使用率超過 90%，WAL 傳送者程序可能無法取得足夠的 CPU 時間。建議您減輕主要執行個體的負載，或增加其 CPU。
  • 副本 CPU 使用率過高。如果副本的 CPU 使用率超過 90%，WAL 接收器程序可能就無法取得足夠的 CPU 時間。請考慮減少備用資源的負載，或增加其 CPU。
  • 網路頻寬問題或磁碟 I/O 瓶頸。較近的區域或總處理量較高的磁碟設定或許有幫助。請考慮修改主要執行個體中的 wal_compression 旗標值，以減少跨區域流量。
你可以使用 cloudsql.googleapis.com/database/replication/network_lag 指標監控網路延遲。 即使實際延遲時間較長，這項指標的上限仍為 25 秒。

這項 network_lag 指標與 cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag 指標類似，都是用來測量以位元組表示的 sent_location 延遲，如 replica_lag_type 標籤所示。

因 DDL 而遭專屬鎖定

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

詳情請參閱 PostgreSQL 說明文件。

過載的副本

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

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

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

單體式主要資料庫

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

監控複製延遲

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

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

備用資源狀態落後主要執行個體狀態的秒數。這是指目前時間與原始時間戳記之間的差異，原始時間戳記是指主要資料庫在副本上套用交易時，所提交交易的時間。具體來說，即使副本已收到寫入作業，但如果尚未將寫入作業套用至資料庫，系統仍可能將寫入作業視為延遲。

這項指標是使用副本中的 now() - pg_last_xact_replay_timestamp() 計算而得。這是估計值。如果複製作業中斷，副本就無法得知主要資料庫的領先程度，因此這項指標不會指出總延遲時間。
延遲位元組
(cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag)

備用資料庫狀態落後主要資料庫狀態的位元組數。replica_byte_lag 會匯出 4 個時間序列，而 replica_lag_type 標籤可指出下列任一項目：

  • sent_location:指出已產生但尚未傳送至副本的 WAL 位元組數。
  • write_location:「寫入減去傳送延遲」會顯示網路中的 WAL 位元組，這些位元組已傳送出去，但尚未寫入副本。
  • flush_location:Flush minus write lag 會顯示寫入副本的 WAL 位元組，但尚未在副本中排清。
  • replay_location:顯示以位元組為單位的總延遲時間。重播時間減去清除延遲時間，即為重播延遲時間。
網路延遲
(cloudsql.googleapis.com/database/replication/network_lag)

從主要資料庫中提交到副本的 WAL 接收器，所需的時間 (以秒為單位)。

如果 network_lag 為零或可忽略，但 replica_lag 很高，表示 WAL 接收器無法快速套用複製變更。

確認複製設定

如要確認複製功能是否正常運作，請對副本執行下列陳述式：

  select status, last_msg_receipt_time from pg_stat_wal_receiver;

如果正在進行複製作業，您會看到 streaming 狀態和最近的 last_msg_receipt_time：

  postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
    status   |     last_msg_receipt_time
  -----------+-------------------------------
  streaming | 2020-01-21 20:19:51.461535+00
  (1 row)

如果未發生複製作業，系統會傳回空白結果：

  postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
  status | last_msg_receipt_time
  --------+-----------------------
  (0 rows)

後續步驟：