管理唯讀備用資源

本頁面說明如何管理讀取用途備用機器。這些作業包括停用和啟用複製作業、推送備用資源、設定並行複製作業,以及檢查複製作業狀態。

如要進一步瞭解複製功能的運作方式,請參閱「Cloud SQL 中的複製功能」。

停用複製功能

備用資源預設會在啟用複製的情況下啟動,但是您也可以將其停用以進行其他工作,例如進行偵錯作業或分析執行個體的狀態。準備就緒後,請明確重新啟用複製功能。停用或重新啟用複製功能不會重新啟動備用資源執行個體。

停用複製作業不會停止備用資源執行個體;它會變成只讀執行個體,不再從主要執行個體複製資料。系統會繼續向您收取執行個體的費用。在停用的備用資源上,您可以重新啟用複製功能、刪除備用資源,或將備用資源推送至獨立的執行個體。

如果您長時間停用複寫功能,磁碟儲存空間需求可能會增加。舉例來說,執行個體可能會累積交易記錄,以便您重新啟用複製作業時繼續複製。為避免增加磁碟儲存空間需求,建議您升級副本或建立主要執行個體的複本,而非長時間停用複製功能。

停用複製功能:

控制台

  1. 前往 Google Cloud 控制台的「Cloud SQL 執行個體」頁面。

    前往 Cloud SQL 執行個體

  2. 按一下備用資源執行個體的名稱來選取備用資源執行個體。
  3. 按一下按鈕列中的「Disable replication」
  4. 按一下 [確定]

gcloud

gcloud sql instances patch REPLICA_NAME \
--no-enable-database-replication

REST v1

如要在指令列提示下執行這個 cURL 指令,您可以使用 gcloud auth print-access-token 指令取得存取憑證。您也可以使用 Instances:patch 頁面上的 APIs Explorer 傳送 REST API 要求。

使用任何要求資料之前,請先替換以下項目:

  • project-id:專案 ID
  • replica-name:備援執行個體的名稱

HTTP 方法和網址:

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

JSON 要求主體:

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

如要傳送要求,請展開以下其中一個選項:

您應該會收到如下的 JSON 回應:

REST v1beta4

如要在指令列提示下執行這個 cURL 指令,您可以使用 gcloud auth print-access-token 指令取得存取憑證。您也可以使用 Instances:patch 頁面上的 APIs Explorer 傳送 REST API 要求。

使用任何要求資料之前,請先替換以下項目:

  • project-id:專案 ID
  • replica-name:備援執行個體的名稱

HTTP 方法和網址:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

JSON 要求主體:

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

如要傳送要求,請展開以下其中一個選項:

您應該會收到如下的 JSON 回應:

啟用複製功能

如果備用資源已許久未複製,則需要更長的時間才能趕上主要執行個體。在這種情況下,請刪除副本並建立新的副本。

啟用複製功能:

控制台

  1. 前往 Google Cloud 控制台的「Cloud SQL 執行個體」頁面。

    前往 Cloud SQL 執行個體

  2. 按一下備用資源執行個體的名稱來選取備用資源執行個體。
  3. 按一下「啟用複製功能」
  4. 按一下 [確定]。

gcloud

gcloud sql instances patch REPLICA_NAME \
--enable-database-replication

REST v1

如要在指令列提示下執行這個 cURL 指令,您可以使用 gcloud auth print-access-token 指令取得存取憑證。您也可以使用 Instances:patch 頁面上的 APIs Explorer 傳送 REST API 要求。

使用任何要求資料之前,請先替換以下項目:

  • project-id:專案 ID
  • replica-name:備援執行個體的名稱

HTTP 方法和網址:

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

JSON 要求主體:

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

如要傳送要求,請展開以下其中一個選項:

您應該會收到如下的 JSON 回應:

REST v1beta4

如要在指令列提示下執行這個 cURL 指令,您可以使用 gcloud auth print-access-token 指令取得存取憑證。您也可以使用 Instances:patch 頁面上的 APIs Explorer 傳送 REST API 要求。

使用任何要求資料之前,請先替換以下項目:

  • project-id:專案 ID
  • replica-name:備援執行個體的名稱

HTTP 方法和網址:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

JSON 要求主體:

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

如要傳送要求,請展開以下其中一個選項:

您應該會收到如下的 JSON 回應:

推送備用資源

將唯讀備用資源升級,執行個體就會停止複製資料,並轉換為具備讀寫能力的獨立 Cloud SQL 主要執行個體。

升級後,系統會自動為唯讀備用資源設定備份,但不會自動將其設為高可用性 (HA) 執行個體。您可以將備用資源升級後啟用高可用性,就像對任何非備用資源執行個體一樣。設定高可用性的唯讀備用資源,與主要執行個體相同。進一步瞭解如何設定高可用性的執行個體

推送唯讀備用資源前,如果主要執行個體仍可使用且提供服務給用戶端,請執行下列操作:

  1. 停止對主要執行個體的所有寫入作業。
  2. 檢查備用資源的複寫狀態 (請按照「psql 用戶端」分頁中的操作說明進行)。
  3. 確認備份資源是否正在複製,然後等到 replay_lag 指標回報的複製延遲時間為 0。

否則,新升級的執行個體可能會遺漏已提交至主要執行個體的部分交易。

如要將備用資源升級為獨立執行個體,請按照下列步驟操作:

控制台

  1. 前往 Google Cloud 控制台的「Cloud SQL 執行個體」頁面。

    前往 Cloud SQL 執行個體

  2. 按一下備用資源執行個體的名稱來選取備用資源執行個體。
  3. 按一下「推送備用資源」
  4. 按一下 [確定]。

gcloud

gcloud sql instances promote-replica REPLICA_NAME
  

REST v1

如要在指令列提示下執行這個 cURL 指令,您可以使用 gcloud auth print-access-token 指令取得存取憑證。您也可以使用 Instances:promoteReplica 頁面上的 APIs Explorer 傳送 REST API 要求。

使用任何要求資料之前,請先替換以下項目:

  • project-id:專案 ID
  • replica-name:備援執行個體的名稱

HTTP 方法和網址:

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica

如要傳送要求,請展開以下其中一個選項:

您應該會收到如下的 JSON 回應:

REST v1beta4

如要在指令列提示下執行這個 cURL 指令,您可以使用 gcloud auth print-access-token 指令取得存取憑證。您也可以使用 Instances:promoteReplica 頁面上的 APIs Explorer 傳送 REST API 要求。

使用任何要求資料之前,請先替換以下項目:

  • project-id:專案 ID
  • replica-name:備援執行個體的名稱

HTTP 方法和網址:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica

如要傳送要求,請展開以下其中一個選項:

您應該會收到如下的 JSON 回應:

確認已正確設定升級的執行個體。特別是,視需要考慮將執行個體設為高可用性

檢查複製狀態

使用 Google Cloud 主控台查看複本執行個體,或使用管理用戶端登入執行個體時,您會取得複本的詳細資料,包括狀態和指標。使用 gcloud CLI 時,您會取得複製設定的簡短摘要。

在檢查 Cloud SQL 備用資源執行個體的複製狀態前,請先使用
gcloud sql instances describe 指令顯示執行個體的狀態。因此,您可以查看備用資源是否已啟用複製功能。

複本執行個體可使用下列指標。(進一步瞭解所有執行個體 (包括非複本執行個體) 適用的其他指標)。

指標說明
複製狀態
(cloudsql.googleapis.com/database/replication/state)

指出複製功能是否主動將記錄從主要執行個體串流至備用資源。可能的值包括:

  • Running
  • Stopped
  • Error

在下列情況下,這項指標會回報 Running

  1. pg_catalog.pg_stat_wal_receiver 回報「串流」的 status
  2. pg_catalog.pg_is_wal_replay_paused() 會回報「f」(false)。

詳情請參閱 PostgreSQL 參考手冊中的「統計資料收集器」和「系統管理函式」。

複製延遲時間
(cloudsql.googleapis.com/database/replication/replica_lag)

備用資源的狀態落後主要執行個體狀態的時間長度。這項差異是 (1) 目前時間與 (2) 主要執行個體目前在複本上套用的交易原始時間戳記之間的差異。特別是,如果備援機制尚未將寫入作業套用至資料庫,即使備援機制已收到寫入作業,系統仍可能將寫入作業計為延遲。

對於層疊備援,系統會分別監控每個主要/備援組合,因此沒有單一指標可產生端對端 (主要/備援) 延遲。

詳情請參閱「複製延遲」。

延遲位元組
(cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag)

回報唯讀備用資源落後主要執行個體的位元組數。每個複本都會產生四個時序,顯示主機預寫記錄中尚未寫入的位元組數量…

  • sent_location:…傳送至複本
  • write_location:…由備用資源寫入磁碟
  • flush_location:…由複本寫入磁碟
  • replay_location:…由備用機播放

這些指標的用途各有不同。舉例來說,replay_location 可用來表示複製延遲 (已提交至主要執行個體,但尚未套用至備用執行個體的交易次數),而 flush_location 則可用來表示尚未在備用執行個體上永久記錄的交易次數。

這些指標的計算方式是將 pg_catalog.pg_current_wal_lsn()pg_stat_replication 中的下列任一欄位進行比較:sent_lsnwrite_lsnflush_lsnreplay_lsn。詳情請參閱 PostgreSQL 參考手冊中的「統計資料收集器」一節。

最大延遲位元組數
(cloudsql.googleapis.com/database/postgresql/external_sync/max_replica_byte_lag)

對於外部主要備用資源,會針對所有複製到此執行個體的資料庫,回報最大複製延遲時間 (以位元組為單位)。對於每個資料庫,這項值的定義是主機預寫記錄中尚未確認備用機已收到的位元組數。

系統會傳送查詢至主要執行個體,比較 pg_catalog.pg_current_wal_lsn() 與每個複製至此備用資源例項的 confirmed_flush_lsn 值,藉此計算這個指標。詳情請參閱 PostgreSQL 參考手冊中的「統計資料收集器」一節。

檢查複製狀態:

控制台

Cloud SQL 會在預設 Cloud SQL 監控資訊主頁上回報 Replication State 指標。

如要查看區域內和跨區域備份、外部伺服器備份的其他指標,請建立自訂資訊主頁,並新增要監控的指標:

  1. 前往 Google Cloud 控制台的「Monitoring」頁面。

    前往「Monioring」

  2. 選取「資訊主頁」分頁標籤。
  3. 按一下「Create dashboard」(建立資訊主頁)
  4. 為資訊主頁命名,然後按一下「確定」。
  5. 按一下 [Add chart] (新增圖表)
  6. 在「Resource Type」(資源類型) 中,選取「Cloud SQL Database」(Cloud SQL 資料庫)
  7. 執行下列任一操作:
    1. 如要監控複製狀態指標:在「選取指標」欄位中,輸入 Replication state然後新增 state = "Running" 的篩選器。如果複製作業正在執行,圖表會顯示 1,否則為 0。
    2. 如要監控唯讀備用資源的複製延遲時間 (以位元組為單位):在「選取指標」欄位中,輸入 Lag Bytes。然後在 replica_lag_type = "replay_location" 上新增篩選器。這張圖表顯示與已在主機上提交但尚未在副本上重播的交易相關聯的位元組數。
    3. 如要監控外部主要主機副本的複寫延遲時間 (以位元組為單位):在「Select a metric」欄位中,輸入 Max Lag Bytes。這張圖表顯示與已在主機上提交但尚未確認已收到的複本相關聯的交易位元組數。

gcloud

針對備用資源執行個體,使用以下指令檢查複製狀態:

gcloud sql instances describe REPLICA_NAME

在輸出結果中,找出 databaseReplicationEnabledmasterInstanceName 屬性。

針對主要執行個體,檢查是否有備用資源:

gcloud sql instances describe PRIMARY_INSTANCE_NAME

在輸出結果中,找出 replicaNames 屬性。

psql 用戶端

部分複製狀態指標是由主要執行個體產生,部分則是由副本產生。在下列步驟中,請使用 PostgreSQL 用戶端連線至複本或主要執行個體 (如以下所述)。

如需相關資訊,請參閱「外部應用程式的連線選項」。

  1. 如要從主要執行個體檢查備用資源的狀態,請按照下列步驟操作:
    select * from pg_stat_replication;
    在指令輸出中,查看下列指標:
    • client_addr:複本執行個體的 IP 位址。
    • state:指出是否正在執行用於執行轉送記錄事件的 SQL 執行緒。開始複製時,這個值為 streaming
    • replay_lag:備用資源 SQL 執行緒落後於主要執行個體的位元組數。值為 O 或少量位元組。
  2. 如要從備用資源執行個體檢查備用資源的狀態,請按照下列步驟操作:
    select * from pg_stat_wal_receiver;

    在指令的輸出內容中,尋找下列指標:

    • sender_host:主要執行個體的 IP 位址。
    • status:指出是否正在執行用於執行轉送記錄事件的 SQL 執行緒。開始複製時,這個值為 streaming
    • last_msg_send_timelast_msg_receipt_time:這兩個時間戳記之間的差異就是延遲時間。

    如要檢查複製作業是否已暫停,請按照下列步驟操作:

    select pg_is_wal_replay_paused();

    如果複製作業已暫停,值為 t;否則為 f

    如要檢查是否有從主要資料來源收到但尚未套用的交易,請按照下列步驟操作:

    # for PostgreSQL 9.6
    select pg_catalog.pg_last_xlog_receive_location(), pg_catalog.pg_last_xlog_replay_location();
    # for PostgreSQL 10 and above
    select pg_catalog.pg_last_wal_receive_lsn(), pg_catalog.pg_last_wal_replay_lsn();

    如果兩個值相等,則表示備援機制已處理從主要機制收到的所有交易。

  • 如要進一步瞭解這些指令的輸出內容,請參閱 PostgreSQL 說明文件中的「統計資料收集器」一節。
  • 疑難排解

    問題 疑難排解
    唯讀副本在建立時未開始複製作業。 記錄檔中可能會有更具體的錯誤。請在 Cloud Logging 中檢查記錄,找出實際錯誤。
    無法建立唯讀副本 - invalidFlagValue 錯誤。 要求中有一項標記無效。這個旗標可以是您明確提供的旗標,也可以是設為預設值的旗標。

    首先,請確認 max_connections 標記的值大於或等於主要執行個體的值。

    如果 max_connections 標記設定正確,請在 Cloud Logging 中檢查記錄,找出實際錯誤。

    無法建立唯讀副本 - 發生不明錯誤。 記錄檔中可能會有更具體的錯誤。請在 Cloud Logging 中檢查記錄,找出實際錯誤。

    如果錯誤為 set Service Networking service account as servicenetworking.serviceAgent role on consumer project,請停用再重新啟用 Service Networking API。這個動作會建立繼續程序所需的服務帳戶。

    磁碟已滿。 在建立備援執行個體時,主要執行個體的磁碟空間可能會用盡。 編輯主要執行個體,將其升級為較大的磁碟大小。
    磁碟空間大幅增加。 如果未積極使用插槽追蹤資料,PostgreSQL 會無限期保留 WAL 區段,導致磁碟空間無限擴大。如果您在 Cloud SQL 中使用邏輯複製和解碼功能,系統會自動建立及刪除複製時段。您可以查詢 pg_replication_slots 系統檢視畫面,並篩選 active 資料欄,藉此偵測未使用的複寫時段。您可以使用 pg_drop_replication_slot 指令,捨棄未使用的插槽以移除 WAL 區段。
    副本執行個體使用太多記憶體。 備份資源會使用暫存記憶體快取常見的讀取作業,因此可能會比主要執行個體使用更多記憶體。

    重新啟動複本執行個體,以便回收暫時性記憶體空間。

    複製作業已停止。 已達儲存空間上限,且未啟用自動增加儲存空間功能。

    編輯執行個體,啟用 automatic storage increase

    複製延遲持續偏高。 寫入負載過高,複本無法處理。當備援機制上的 SQL 執行緒無法跟上 I/O 執行緒時,就會發生複製延遲。某些類型的查詢或工作負載,可能會導致特定結構定義的複製延遲時間暫時或永久性偏高。複製延遲的常見原因包括:
    • 複本上的查詢速度緩慢。找出並修正這些問題。
    • 所有資料表都必須有專屬/主索引鍵。在這種沒有唯一/主鍵的資料表上進行的每項更新,都會導致備援資料庫進行完整資料表掃描。
    • DELETE ... WHERE field < 50000000 這類查詢會導致以列為基礎的複製作業出現延遲,因為複本上會累積大量更新。

    可能的解決方法包括:

    • 編輯執行個體,以增加複本的大小。
    • 降低資料庫的負載。
    • 將讀取流量傳送至讀取備用資源。
    • 為資料表建立索引。
    • 找出並修正寫入查詢速度緩慢的問題。
    • 重新建立備用資源。
    在 PostgreSQL 9.6 中重新建立索引時發生錯誤。 PostgreSQL 會傳回錯誤訊息,指出您需要重建特定索引。這項操作只能在主要執行個體上執行。如果您建立新的複本執行個體,很快就會再次收到相同的錯誤。在 PostgreSQL 10 以下版本中,雜湊索引不會傳播至備援資料庫

    如果您必須使用雜湊索引,請升級至 PostgreSQL 10 以上版本。如果您也想使用備援機制,請勿在 PostgreSQL 9.6 中使用雜湊索引。

    主要例項的查詢一律會持續執行。 建立備援機制後,查詢 SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' 應會持續在主要執行個體上執行。
    備援機制建立作業因逾時而失敗。 主要執行個體上長時間執行未提交的交易,可能會導致建立唯讀備用資源失敗。

    停止所有執行中的查詢後,重新建立複本。

    如果主執行個體和副本的 vCPU 大小不同,查詢最佳化工具會考量 vCPU 大小,因此可能會發生查詢效能問題。

    如要解決這個問題,請完成下列步驟:

    1. 開啟 log_duration 標記,並將 log_statement 參數設為 ddl。這麼做可讓您同時取得查詢和資料庫的執行時間。不過,視工作負載而定,這可能會導致效能問題。
    2. 在主要執行個體和唯讀備用資源上,為查詢執行 explain analyze
    3. 比較查詢計畫並檢查差異。

    如果這是特定查詢,請修改查詢。舉例來說,您可以變更彙整順序,看看是否能獲得更佳成效。

    後續步驟