管理唯讀備用資源

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

如要進一步瞭解複製功能的運作方式,請參閱「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. 檢查備援資料庫的複寫狀態 (請按照 mysql 用戶端分頁中的指示操作)。
  3. 確認備份資源是否正在複製,然後等到 Seconds_Behind_Master 指標回報的複製延遲時間為 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 回應:

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

設定平行複製作業

減少複製延遲對於管理複製效能至關重要。當唯讀備用資源的更新內容落後於主要執行個體的更新內容,就會發生複製延遲。本節說明使用者如何啟用平行複寫功能,以便減少複寫延遲時間。

在 MySQL 複製作業中,複製 SQL 執行緒會用於執行在讀取用備用資源上中繼記錄中收集到的交易。並透過增加執行這些交易的 SQL 執行緒數量,減少複製延遲時間。啟用平行複寫功能的唯讀備用資源,有時稱為多執行緒備用資源。

在 MySQL 適用的 Cloud SQL 中,平行複製功能適用於以下三種情況:

為簡化說明,本頁面會使用「主要執行個體」和「讀取用副本」等術語。

變更平行複製標記的基本步驟

啟用並行複寫功能的步驟如下:

  1. 在唯讀備用資源上停用複製功能
  2. 在唯讀備用資源上設定平行複製的標記。請使用 gcloud 指令設定旗標。停用複製功能時, Google Cloud 主控台選項會停用。
  3. 在唯讀副本上啟用複製功能
  4. 您可以選擇在主要執行個體上設定旗標,以最佳化平行複製的效能

唯讀備用資源:平行複製的標記

MySQL 適用的 Cloud SQL 支援多個標記,可在唯讀備用資源上進行平行複製。如要瞭解標記的相關資訊,請點選下列 MySQL 8.0 說明文件的連結:

變更這些旗標不會重新啟動讀取/寫入備援機制。

下表列出這些旗標的允許範圍和預設值:

唯讀備用資源標記 接受的值 MySQL 5.7 預設值 MySQL 8.0 以上版本的預設值
replica_parallel_workers 0-1024 0 0 (MySQL 8.0.26 以下版本)
4 (MySQL 8.0.27 以上版本)
replica_parallel_type DATABASE, LOGICAL_CLOCK DATABASE DATABASE (MySQL 8.0.26 以下版本)
LOGICAL_CLOCK (MySQL 8.0.27 以上版本)
replica_preserve_commit_order ON, OFF OFF OFF (MySQL 8.0.26 以下版本)
ON (MySQL 8.0.27 以上版本)
replica_pending_jobs_size_max 1024-1GB 16MB 128 MB

replica_preserve_commit_order 旗標可避免從複本的轉送記錄執行的交易序列出現空白。

replica_preserve_commit_order=1 設定需要符合下列條件:

replica_pending_jobs_size_max 標記會設定可供保留未套用的事件的套用佇列使用的記憶體上限 (以位元組為單位)。

主要例項:平行複製的標記

MySQL 適用的 Cloud SQL 支援在主要執行個體上使用的多個標記。您可以使用這些旗標,針對已啟用平行複製的相關唯讀備用資源調整複製效能。如要瞭解標記的相關資訊,請點選下列連結,前往 MySQL 8.0 說明文件:

變更這些標記不會重新啟動主要執行個體。

下表列出這些旗標的允許範圍和預設值:

主要執行個體旗標 接受的值 MySQL 5.7 預設值 MySQL 8.0 預設值 MySQL 8.4 預設值
binlog_transaction_dependency_history_size 1-1000000 25000 25000 25000
binlog_transaction_dependency_tracking COMMIT_ORDER, WRITESET, WRITESET_SESSION COMMIT_ORDER WRITESET 不適用 (已在 MySQL 8.4 中淘汰)
transaction_write_set_extraction OFF, MURMUR32, XXHASH64 OFF XXHASH64 不適用 (已在 MySQL 8.4 中淘汰)

在 MySQL 5.7 中,如果 binlog_transaction_dependency_tracking 設為 WRITESETWRITESET_SESSION,則 transaction_write_set_extraction 應設為非 OFF 值 (XXHASH64MURMUR32)。

檢查複製狀態

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

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

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

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

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

  • Running
  • Stopped
  • Error

如果複本的 I/O 和 SQL 執行緒都回報正在執行,這項指標就會回報 Running。如需更多資訊,請參閱下方的從屬 I/O 執行緒執行狀態從屬 SQL 執行緒執行狀態指標,或參閱 MySQL 參考手冊中的「檢查複製狀態」。

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

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

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

這個指標會在備援機制上執行 SHOW REPLICA STATUS 時,回報 Seconds_Behind_Master 的值。如需更多資訊,請參閱 MySQL 參考手冊中的「檢查複製作業狀態」。

網路延遲
(cloudsql.googleapis.com/database/replication/network_lag)

從主要資料庫寫入 binlog 到備援資料庫的 IO 執行緒所需的時間 (以秒為單位)。

如果 network_lag 為零或可忽略,但 `replica_lag` 很高,表示 SQL 執行緒無法快速套用複製變更。

從屬 I/O 執行緒執行狀態
(cloudsql.googleapis.com/database/mysql/replication/slave_io_running_state)

指出用於讀取主要執行個體二進位記錄的 I/O 執行緒是否正在備用資源上執行。可能的值包括:

  • Yes
  • No
  • Connecting

SHOW REPLICA STATUS 在複本上執行時,這個指標會回報 Slave_IO_Running 的值。如需更多資訊,請參閱 MySQL 參考手冊中的「檢查複製作業狀態」。

從屬 SQL 執行緒執行狀態
(cloudsql.googleapis.com/database/mysql/replication/slave_sql_running_state)

指出用於執行轉送記錄事件的 SQL 執行緒是否在複本上執行。可能的值包括:

  • Yes
  • No
  • Connecting

SHOW REPLICA STATUS 在副本上執行時,這個指標會回報 Slave_SQL_Running 的值。如需更多資訊,請參閱 MySQL 參考手冊中的「檢查複製作業狀態」。

檢查複製狀態:

控制台

Cloud SQL 會在預設 Cloud SQL 監控資訊主頁中,回報 Replication StateReplication Lag 指標。

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

  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. 如要監控複製延遲指標:在「選取指標」欄位中,輸入 replica_lag這張圖表顯示副本狀態落後於主機狀態的時間長度。
    3. 如要監控複本的 I/O 執行緒狀態:在「Select a metric」欄位中,輸入 Slave I/O thread running state。然後在 state = "Yes" 上新增篩選器。如果執行緒正在執行,圖表會顯示 1,否則為 0。
    4. 如要監控複本的 SQL 執行緒狀態:在「Select a metric」欄位中輸入 Slave SQL thread running state。然後在 state = "Yes" 上新增篩選器。如果執行緒正在執行,圖表會顯示 1,否則為 0。

gcloud

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

gcloud sql instances describe REPLICA_NAME

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

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

gcloud sql instances describe PRIMARY_INSTANCE_NAME

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

MySQL 用戶端

  1. 使用 MySQL 用戶端連線至備援機制。

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

  2. 檢查備用資源的狀態:
    SHOW REPLICA STATUS \G

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

    • Master_Host:主要執行個體的名稱。
    • Slave_IO_RunningSlave_SQL_Running: 是否分別執行 I/O 和 SQL 執行緒。這些執行緒負責將事件從主要資料來源轉移至複本的轉送記錄,並從轉送記錄執行這些事件。如果執行緒正在執行,指標的值為 Yes。兩個執行緒都必須執行,才能啟用複製作業。
    • Seconds_Behind_Master:備援主機處理主要執行個體交易的延遲時間 (以秒為單位),也就是 (1) 目前時間與 (2) 主要執行個體提交目前套用於備援主機的交易原始時間戳記之間的差異。如果複製作業中斷,則值為 NULL
    • Master_Log_fileRead_Master_Log_PosRelay_Master_Log_FileExec_Master_Log_Pos:這些指標會顯示 I/O 執行緒讀取事件的座標 (Master_Log_fileRead_Master_Log_Pos),以及 SQL 執行緒執行事件的座標 (Relay_Master_Log_FileExec_Master_Log_Pos)。如果這些座標相同 (Master_Log_file 等於 Relay_Master_Log_FileRead_Master_Log_Pos 等於 Exec_Master_Log_Pos),表示副本已處理從主要來源收到的所有事件。

如要進一步瞭解此指令的輸出內容,請參閱 MySQL 說明文件中的「檢查複製作業狀態」一節。

疑難排解

問題 疑難排解
唯讀副本在建立時未開始複製作業。 記錄檔中可能會有更具體的錯誤。請在 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。這個動作會建立繼續程序所需的服務帳戶。

磁碟已滿。 在建立備援執行個體時,主要執行個體的磁碟空間可能會用盡。 編輯主要執行個體,將其升級為較大的磁碟大小。
副本執行個體使用太多記憶體。 備份資源會使用暫存記憶體快取常見的讀取作業,因此可能會比主要執行個體使用更多記憶體。

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

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

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

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

可能的解決方法包括:

複製延遲時間突然飆升。 這是因為長時間執行的交易。當交易 (單一陳述式或多個陳述式) 在來源執行個體上進行修訂時,系統會在二進位記錄中記錄交易的開始時間。當副本收到此 binlog 事件時,會將該時間戳記與目前的時間戳記進行比較,以計算複製延遲時間。因此,來源上長時間執行的交易會導致備援資料上立即出現大量複製延遲。如果交易中的資料列變更數量龐大,複本執行交易的時間也會很長。在這段期間,複製延遲時間會增加。副本完成這筆交易後,追趕期間將取決於來源的寫入工作負載和副本的處理速度。

為避免交易時間過長,可採用以下解決方案:

  • 將交易拆分為多筆小額交易
  • 將單一大型寫入查詢分割為較小的批次
  • 請嘗試將長時間執行的 SELECT 查詢與混合 DML 的交易分開
變更並行複製旗標會導致錯誤。 為一或多個標記設定了錯誤的值。

在顯示錯誤訊息的主執行個體上設定平行複製標記:

  1. 修改 binlog_transaction_dependency_trackingtransaction_write_set_extraction 標記:
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. 新增 slave_pending_jobs_size_max 旗標:

    slave_pending_jobs_size_max=33554432

  3. 修改 transaction_write_set_extraction 標記:

    transaction_write_set_extraction=XXHASH64

  4. 修改 binlog_transaction_dependency_tracking 標記:

    binlog_transaction_dependency_tracking=WRITESET

備援機制建立作業因逾時而失敗。 主要執行個體上長時間執行未提交的交易,可能會導致建立唯讀備用資源失敗。

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

後續步驟