管理唯讀備用資源

本頁說明如何管理唯讀副本。這些作業包括停用及啟用複製作業、升級備用資源、設定平行複製作業,以及檢查複製狀態。

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

停用複製功能

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

停用複製作業不會停止備用執行個體,而是會將其變成唯讀執行個體,不再從主要執行個體複製資料。系統會繼續收取執行個體費用。在已停用的備用資源上,您可以重新啟用複製功能、刪除備用資源,或將備用資源升級為獨立執行個體。

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

停用複製功能:

控制台

  1. 前往 Trusted Cloud 控制台的「Cloud SQL Instances」頁面。

    前往 Cloud SQL 執行個體

  2. 按一下備用資源執行個體的名稱來選取備用資源執行個體。
  3. 按一下按鈕列中的「停用複製功能」
  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. 前往 Trusted Cloud 控制台的「Cloud SQL Instances」頁面。

    前往 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 Client」分頁中的操作說明進行)。
  3. 確認備用資源正在複製,然後等待 Seconds_Behind_Master 指標回報的複製延遲為 0。

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

如要將副本升級為獨立執行個體,請按照下列步驟操作:

控制台

  1. 前往 Trusted Cloud 控制台的「Cloud SQL Instances」頁面。

    前往 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 指令設定旗標。停用複製功能時, Trusted 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)。

檢查複製狀態

使用 Trusted 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)

從主要資料庫寫入二進位記錄檔,到副本的 IO 執行緒收到記錄檔之間的時間長度 (以秒為單位)。

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

Slave I/O thread running state
(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. 前往 Trusted 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. 監控複寫延遲指標:在「Select a metric」(選取指標) 欄位中輸入 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_File,且 Read_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 執行緒無法跟上 IO 執行緒,就會發生複製延遲。某些查詢或工作負載可能會導致特定結構定義出現暫時或永久的高複製延遲。複製延遲的常見原因包括:
  • 副本上的查詢速度緩慢。找出並修正這些問題。
  • 所有資料表都必須有不重複/主索引鍵。如果資料表沒有唯一/主鍵,每次更新都會導致副本完整掃描資料表。
  • 如果使用以列為基礎的複寫功能,DELETE ... WHERE field < 50000000 這類查詢會造成複寫延遲,因為複本上會累積大量更新。

可能的解決方法包括:

複製延遲時間突然大幅增加。 這是因為交易執行時間過長所致。當交易 (單一陳述式或多個陳述式) 在來源執行個體上提交時,交易的開始時間會記錄在二進位記錄檔中。副本收到這個 binlog 事件時,會比較該時間戳記與目前的時間戳記,以計算複寫延遲。因此,來源上長時間執行的交易會導致副本立即出現大量複製延遲。如果交易中的資料列變更量很大,副本也會花費很長時間執行。這段時間內,複製延遲會增加。副本完成這項交易後,追趕期會視來源的寫入工作負載和副本的處理速度而定。

如要避免交易時間過長,可以嘗試以下解決方法:

  • 將交易拆分成多筆小額交易
  • 將單一大型寫入查詢分成較小的批次
  • 嘗試將包含 DML 的交易中冗長的 SELECT 查詢分開
變更平行複製旗標會導致錯誤。 一或多個標記的值不正確。

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

  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

建立副本時發生逾時錯誤。 主要執行個體上未提交的長期交易可能會導致唯讀備用資源建立失敗。

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

後續步驟