本頁說明如何排解及修正 Cloud SQL 讀取複本的複製延遲問題。
總覽
Cloud SQL 唯讀備用資源會使用全域交易 ID (GTID) 的 MySQL 列式複製功能。變更會寫入主要執行個體的二進位記錄，並傳送至備用資源，在那裡接收並套用至資料庫。複製延遲可能會在以下情況下發生：
- 主要執行個體無法將變更內容快速傳送至副本。
- 副本無法快速接收變更。
- 副本無法快速套用變更。
network_lag 指標監控前兩種情況。
您可以使用 replica_lag 指標查看總延遲時間。replica_lag 和 network_lag 之間的差異，可以指出當複本無法快速套用複製變更時的第三個原因。如要瞭解這些指標，請參閱下方的「監控複製延遲」一節。
加快備用資源設定速度
我們提供兩種方法，讓 MySQL 複本更快套用變更。使用者可以使用下列選項設定複本：
- 平行複製
- 高效能沖洗
平行複製
平行複製功能可設定備用資源，讓備用資源使用多個並行執行的執行緒，以便套用備用資源上的變更，進而縮短複製延遲時間。如要瞭解如何使用平行複製功能，請參閱「 設定平行複製功能」。
高效能沖洗
根據預設，MySQL 適用的 Cloud SQL 會在每筆交易完成後，將重做記錄刷新至磁碟。高效清除可將重做記錄清除至磁碟的頻率降低至每秒一次，進而改善寫入效能。
將唯讀備用資料庫的 innodb_flush_log_at_trx_commit 標記設為 2。您也必須將 sync_binlog 標記設為較高的值，innodb_flush_log_at_trx_commit 標記才能生效。
如要進一步瞭解此標記，請參閱使用標記的提示。
在唯讀備用資源上設定 innodb_flush_log_at_trx_commit 旗標，如果 Cloud SQL 偵測到可能發生當機情形，就會自動重新建立備用資源。
最佳化查詢和結構定義
本節將提供一些常見的查詢和結構定義最佳化方式，協助您提升複製效能。
唯讀備用資料庫的查詢隔離層級
REPEATABLE READ 和 SERIALIZABLE 交易隔離層級會取得可能會阻斷複製變更的鎖定。建議您降低複本中查詢的隔離層級。READ COMMITTED 交易隔離等級的效能可能較佳。
主要資料庫中的長時間交易
如果在單一交易中更新大量資料列，可能會導致需要套用至主要執行個體，然後傳送至複本的變更數量突然激增。這項功能適用於一次影響多個資料列的單一陳述式更新或刪除作業。變更會在提交後傳送至複本。如果備用資源的查詢負載也偏高，在備用資源中套用突然大量變更的做法，可能會增加備用資源中發生鎖定爭用的可能性，導致複製作業延遲。
建議將大型交易分割成多項較小的交易。
缺少主鍵
Cloud SQL 唯讀備用資源使用列式複製功能，如果複製的 MySQL 資料表沒有主索引鍵，則效能會變差。建議所有複製的資料表都設有主索引鍵。
針對 MySQL 8 以上版本，建議您將旗標 sql_require_primary_key 設為 ON，要求資料庫中的資料表必須有主鍵。
因 DDL 而產生的專屬鎖定
資料定義語言 (DDL) 指令 (例如 ALTER TABLE 和 CREATE INDEX) 可能會因專屬鎖定而導致備援主機的複製延遲。為避免發生鎖定爭用情形，建議您在複本的查詢負載較低時，安排 DDL 執行作業。
備用資源超載
如果讀取副本收到的查詢過多，複製作業可能會遭到封鎖。建議您將讀取作業分散到多個備用資源，以減輕每個備用資源的負載。
為避免查詢量激增，建議您在應用程式邏輯中或代理層 (如有) 中，限制複本讀取查詢。
如果主要執行個體的活動量突然激增，請考慮分散更新作業。
單體式主要資料庫
建議您將主要資料庫進行垂直 (或水平) 分割，以免一或多個延遲的資料表拖慢其他所有資料表。
監控複製延遲時間
您可以使用 replica_lag 和 network_lag 指標監控複製延遲情形，並找出延遲的原因是主要資料庫、網路或備用資料庫。
| 指標 | 說明 |
|---|---|
| 複製延遲時間 ( cloudsql.googleapis.com) |
備用資源的狀態落後於主要執行個體的秒數。這是目前時間與原始時間戳記之間的差異，當初主要資料庫會在該時間戳記時刻，將目前套用在副本上的交易提交。特別是，如果副本尚未將寫入作業套用至資料庫，即使副本已收到寫入作業，系統仍可能將寫入作業計為延遲。 這個指標會在備援機制上執行 |
| 上一個 I/O 執行緒錯誤編號 ( cloudsql.googleapis.com) |
指出導致 I/O 執行緒失敗的最後一個錯誤。如果此值不為 0，表示複製作業已中斷。這種情況很少發生，但仍有可能發生。請查看 MySQL 說明文件，瞭解錯誤代碼代表的意思。舉例來說，主例項中的 binlog 檔案可能已在複本收到檔案前刪除。如果複製作業中斷，Cloud SQL 通常會自動重新建立備用資源。
這個 |
| 上一個 SQL 執行緒錯誤號碼 ( cloudsql.googleapis.com) |
指出導致 SQL 執行緒失敗的最後一個錯誤。如果此值不為 0，表示複製作業已中斷。這種情況很少發生，但仍有可能發生。請查看 MySQL 說明文件，瞭解錯誤代碼代表的意思。如果複製作業中斷，Cloud SQL 通常會自動重新建立備用資源。
這個 |
| 網路延遲 ( cloudsql.googleapis.com) |
從主要資料庫中寫入 binlog 到複本中的 IO 執行緒所需的時間長度 (以秒為單位)。 如果 |
確認複製設定
如要確認複製功能是否正常運作，請針對複本執行下列陳述式：
mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Queueing master event to the relay log
Master_Host: xx.xxx.xxx.xxx
Master_User: cloudsqlreplica
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.199927
Read_Master_Log_Pos: 83711956
Relay_Log_File: relay-log.000025
Relay_Log_Pos: 24214376
Relay_Master_Log_File: mysql-bin.199898
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 24214163
Relay_Log_Space: 3128686571
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File: master_server_ca.pem
Master_SSL_CA_Path: /mysql/datadir
Master_SSL_Cert: replica_cert.pem
Master_SSL_Cipher:
Master_SSL_Key: replica_pkey.pem
Seconds_Behind_Master: 2627
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 321071839
Master_UUID: 437d04e9-8456-11e8-b13d-42010a80027b
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: System lock
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:52111095710-52120776390
Executed_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:1-52113039508
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
如果正在進行複製作業，第一欄 Slave_IO_State 會顯示 Waiting
for master to send event 或類似訊息。此外，Last_IO_Error 欄位為空白。
如果沒有進行複製作業，Slave_IO_State 欄會顯示狀態 Connecting to master，Last_IO_Error 欄則會顯示狀態 error connecting to master cloudsqlreplica@x.x.x.x:3306。
根據 MySQL 說明文件，與複製延遲相關的其他有趣欄位包括：
| 欄位 | 說明 |
|---|---|
Master_Log_File |
I/O 執行緒目前正在讀取的來源二進位記錄檔名稱。 |
Read_Master_Log_Pos |
I/O 執行緒已讀取的目前來源二進位記錄檔位置。 |
Relay_Log_File |
SQL 執行緒目前讀取及執行的轉送記錄檔案名稱。 |
Relay_Log_Pos |
SQL 執行緒已讀取及執行的目前轉送記錄檔中位置。 |
Relay_Master_Log_File |
來源二進位記錄檔案的名稱，其中包含 SQL 執行緒執行的最新事件。 |
在上述範例中，Relay_Master_Log_File 的值為 mysql-bin.199898。Master_Log_File 的值為 mysql-bin.199927。數字後置字串 199898 小於 199927。也就是說，即使副本已收到較新的 mysql-bin.199927 記錄檔，仍會套用較舊的 mysql-bin.199898。
在這種情況下，SQL 執行緒在備援機制中會出現延遲。
您也可以連線至主要資料庫並執行下列指令：
SHOW MASTER STATUS;
這個指令會顯示主要資料庫中正在寫入的 binlog 檔案。
如果主要資料庫的二進位記錄檔比副本中的 Master_Log_File 還新，表示 I/O 執行緒有延遲。備份資源仍會從主要資料庫讀取較舊的二進位記錄檔案。
如果 I/O 執行緒延遲，network_lag 指標也會偏高。如果 SQL 執行緒延遲，但 I/O 執行緒沒有延遲，network_lag 指標就不會太高，但 replica_lag 會偏高。
先前的指令可讓您在延遲發生時觀察延遲詳細資料，但指標 network_lag 和 replica_lag 可讓您查看過去發生的延遲情形。
重新建立延遲的備用資源
當複製作業落後於可接受的時間長度時，重新建立落後的備援機制。
在 Cloud SQL 中，如果複製作業延遲時間超過可接受的時間長度，且延遲時間持續至少五分鐘，您可以設定唯讀備用資源自行重建。
如果您將可接受的複寫延遲時間定義為 360 秒 (六分鐘) 以下，且至少 361 秒的複寫延遲時間持續超過五分鐘，則在五分鐘後，主要執行個體會建立自身的新快照，並使用此快照重新建立讀取/寫入複本。
重建延遲的唯讀備用資料庫有以下優點：
- 您可以控制系統認為可接受的複製延遲範圍。
- 您可以縮短解決複製延遲問題所需的時間，甚至可縮短數小時或數天。
適用其他功能詳細資料：
- 相容版本：
- MySQL 5.7
- MySQL 8.0
- MySQL 8.4
- 複製延遲或延遲的接受範圍必須以秒為單位。
- 可接受的最低值為 300 秒或 5 分鐘。
- 可接受的最大值為 31,536,000 秒或一年。
- 如果您為執行個體啟用重新建立落後備用資源的功能，但未設定可接受的最大複製延遲時間，Cloud SQL 會使用預設值一年。
- 支援的執行個體類型：
- 唯讀備用資源
- 跨區域唯讀備用資源
- 分層備用資源
replicationLagMaxSeconds欄位的值會依複本例項而異。如果主要執行個體有多個複本執行個體，您可以為每個複本設定不同的值。- 重建副本時，使用者可能會在完成下列作業期間，遇到一些服務中斷時間：
- 複製作業已停止。
- 備份資源已刪除。
- 建立主要執行個體的快照。
- 系統會根據這項最新的快照重新建立複本。新的備援資源會使用與先前備援資源相同的名稱和 IP 位址。因此，MySQL 必須停止並重新啟動。
- 新的備援資源會開始複製資料。
replicationLagMaxSeconds是執行個體層級欄位。每個例項都有自己的值。如果同一個主要執行個體有多個唯讀備用資源，您可以為每個備用資源設定
replicationLagMaxSeconds欄位的不重複值。為不同複本定義不同的時間門檻，有助於避免所有複本同時發生故障。
啟用重新建立延遲備援機制
重建延遲備用資源功能預設為停用。如要在建立執行個體時啟用此功能，請使用下列任一方法：
gcloud
使用 gcloud sql instances create 指令，搭配
--replication-lag-max-seconds-for-recreate 標記建立新的讀取/複寫執行個體：
gcloud beta sql instances create REPLICA_INSTANCE_NAME \ --master-instance-name=PRIMARY_INSTANCE_NAME \ --database-version=DATABASE_VERSION \ --tier=TIER \ --edition=EDITION \ --region=REGION \ --root-password=PASSWORD \ --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS
其中：
REPLICA_INSTANCE_NAME是複本執行個體的名稱。PRIMARY_INSTANCE_NAME是主要例項的名稱。DATABASE_VERSION是執行個體的資料庫版本。例如：MYSQL_8_0_31。TIER是您要用於複本執行個體的機器類型。例如，db-perf-optimized-N-4。詳情請參閱「自訂執行個體設定」。EDITION是您要用於複本執行個體的版本。例如，ENTERPRISE_PLUS。詳情請參閱「建立執行個體」。REGION是您要用於複本執行個體的地區。例如：us-central1。PASSWORD是執行個體的根密碼。REPLICATION_LAG_MAX_SECONDS是可接受的複製延遲時間上限 (以秒為單位)。例如，600。可接受的最低值為 300 秒或 5 分鐘。最大可接受值為 31,536,000 秒或一年。
REST API
replicationLagMaxSeconds 欄位位於 DatabaseInstance 資源中。將這個欄位新增至要求主體：
{ "settings": { "replicationLagMaxSeconds" :REPLICATION_LAG_MAX_SECONDS, } ... }
其中：
REPLICATION_LAG_MAX_SECONDS是可接受的複製延遲時間上限 (以秒為單位)。例如：600。
更新複製延遲的重新建立時間範圍
如要查看執行個體的設定，請使用「查看執行個體摘要資訊」一文所述的任何方法。
有了這項資訊，您就可以選擇是否要更新在重新建立複本之前，您指定的接受範圍內的複製延遲時間。
gcloud
使用 gcloud sql instances patch 指令，根據複製延遲時間更新重新建立執行個體的時間範圍：
gcloud beta sql instances patch INSTANCE_NAME \ --replication-lag-max-seconds-for-recreate=REPLICATION_LAG_MAX_SECONDS
其中：
INSTANCE_NAME是執行個體的名稱。REPLICATION_LAG_MAX_SECONDS是可接受的複製延遲時間上限 (以秒為單位)。例如，700。如要還原為預設值一年，請輸入31536000。可接受的最低值為 300 秒或 5 分鐘。最大可接受值為 31,536,000 秒或一年。
REST API
您可以使用 instances.patch 和 instance.insert 更新政策。
如需使用 REST API 更新設定的範例，請參閱「編輯執行個體」。
限制
重建延遲的複本時，請注意下列限制：
replicationLagMaxSeconds的值只能以秒為單位。- 在重建作業之前，在讀取用途備用資源上建立的索引不會保留。如果已建立索引，請在重新建立複本後建立次要索引。
- 為避免唯讀備用資源經常發生停機情形，每個執行個體每天只能重新建立一次。
- 這項功能不支援外部伺服器的備用資源。
- 如果您在層疊備用資源上啟用落後備用資源的重建功能，Cloud SQL 會先重建葉節備用資源，以維持複製作業的一致性。
- 重新建立跨區域備用資源會產生額外費用。
- 您無法在 Google Cloud 主控台中啟用重建延遲備用資源的功能。