設定 MySQL 適用的 Cloud SQL 執行個體的最佳做法

MySQL 適用的 Cloud SQL 是一項全代管資料庫服務，可協助您在 Google Cloud 中設定、維護及管理 MySQL 關聯資料庫。當您準備好建立 MySQL 適用的 Cloud SQL 執行個體時，可以選擇下列幾種方式，包括 UI 控制台、gcloud CLI、Terraform 和 REST API。您可以遵守這些說明文件來詳細瞭解這些路徑，但本文的目的，將會使用使用者介面進行說明；我們將介紹設定執行個體的各種最佳做法。

選用高強度密碼

這是將使用執行個體建立的預設 “root”@”%” 資料庫使用者的密碼。如果您想保留超級使用者做為管理員使用者，請務必在這裡選擇高強度的密碼。針對安全性考量，建議您使用不常見的管理員使用者，而非「根使用者」。請參閱「管理資料庫使用者」一節。

建立執行個體層級密碼政策

密碼政策功能可讓資料庫安全性提升。並可讓您設定密碼長度、複雜性、到期時間，以及複用性限制政策。詳情請參閱強化 MySQL 執行個體。

建議使用 8.0 版本來提高效能

MySQL 適用的 Cloud SQL 支援多個 8.0 子版本，目前預設為 v8.0.26。對一系列機器類型進行基準測試後，顯示 8.0 預設版本比 5.7 和 5.6 版本具有更好的查詢處理量。  

請勿將實際工作環境中的執行個體用於最新的正式發布版本

儘管 Oracle 和 Cloud SQL 進行了測試工作，但 MySQL 的重新整理版本尚未經過複雜的全面實際測試。因此，建議您讓實際工作環境執行個體保持穩定版，並使用開發與測試執行個體，測試 MySQL 適用的 Cloud SQL 最新子版本升級作業。

為實際工作環境執行個體設定多個可用區

MySQL 適用的 Cloud SQL 可自動容錯移轉至第二個可用區，藉以提供區域可用性，以此做為高可用性的解決方案。為獲得最佳可用性，請為實際工作環境執行個體設定多個可用區選項，讓系統自動進行每日備份和時間點復原 (詳情請參閱「備份時間表」一節)。

評估目前的 CPU/記憶體用量，為遷移作業做出明智決策

將現有執行個體遷移至 Cloud SQL 時，目前的工作負載可協助您選擇適當的 VM 大小。

• CPU：在一般工作負載條件下，CPU 用量如何？工作負載尖峰情況如何？執行個體受到 CPU 或 I/O 限制嗎？如果使用者和/或系統的 CPU 百分比相對偏高，表示工作負載受 CPU 限制。如果 I/O 百分比相對偏高，表示工作負載受 I/O 限制。
• 記憶體：同理，執行個體的一般記憶體用量多少？尖峰用量是多少？

例如，供 MySQL 適用的 Cloud SQL 使用 1 個 vCPU，最多可支援 6.5 GB 的記憶體。

規劃 CPU 和記憶體 20% 至 50% 的額外空間

即使在通常穩定的執行個體中，也請至少規劃 20% 的額外空間給 CPU 和記憶體，以便吸收非預期的尖峰用量。對持續成長的企業來說，這個做法尤為重要，請考量規劃 50% 的額外空間。

有了 Cloud SQL，就能輕鬆升級機器類型。請注意，升級作業會有停機時間。

使用 SSD 來提高資料庫效能

MySQL 適用的 Cloud SQL 提供經濟實惠的 HDD 儲存方案，但如果您知道需要高效能資料庫，請選擇 SSD 選項。以下是 I/O 成效的比較。

規劃儲存空間容量在效能與成本之間取得平衡

磁碟 IOPS 和處理量與永久磁碟大小相關。容量越大，就能在執行個體上限內提升 IOPS 和處理量。

以 SSD 來說，可用區和區域性設定會影響效能。詳情請參閱可用區與區域性 SSD 的效能資料。如果您已選取多個可用區可用性，請參閱區域性 SSD 效能資料。簡而言之，讀取和寫入 IOPS 為每 GB 30，處理量為每 GB 0.48 MB。使用區域性 SSD 時，效能資料會非常相似，但每個執行個體的寫入 IOPS 和寫入總處理量較低。

請注意，在 Cloud SQL 執行個體上，系統支援的儲存空間大小上限為 64 TB。

啟用自動增加儲存空間並監控磁碟容量擴充程度

Cloud SQL 提供自動增加儲存空間的功能，可避免執行個體耗盡磁碟空間 (OOD)。在您啟用這項功能後，系統會每 30 秒檢查一次儲存空間，並視需求增加額外儲存空間容量。

這項功能雖能防止 OOD，但增加的容量將永久生效，之後就無法縮減執行個體大小。請先設定磁碟大小警示，以便管理及規劃儲存空間容量。

熟悉加密選項

根據預設，Cloud SQL 會加密靜態資料。不過，如果更符合您的需求，您也可以選擇使用客戶自行管理的加密金鑰 (CMEK)，而非預設的 Google 擁有和代管的金鑰。

評估私人 IP 與公開 IP 之間的優劣取捨

私人 IP 和公開 IP 是指裝置於網路中使用的位址類型。與公開 IP 相比，私人 IP 可提供更好的網路安全性，並減少網路延遲時間。不過，私人 IP 需要另外設定 API 和 IAM 設定，且有時可能其實需要使用公開 IP。如果您知道必須使用公開 IP，但想要提升安全性，可以選擇要求授權網路或使用 Cloud SQL 驗證 Proxy。

考慮使用 Cloud SQL 驗證 Proxy 建立安全連線

Cloud SQL 驗證 Proxy 提供安全的方式存取 Cloud SQL 執行個體，而非設定 SSL 或授權網路。應用程式會進行通訊至本機環境中執行的驗證 Proxy 用戶端，並使用安全的通道與 Cloud SQL 執行個體上的 Proxy 伺服器進行通訊。

啟用備份與時間點復原功能，並查看資料保留政策

定期資料備份與可驗證的資料復原對於健康的資料庫管理至關重要。在資料損毀或非預期資料作業等情況中，這些做法都非常重要，但無論是哪種情況，都無法因高可用性而緩解。

Cloud SQL 提供自動備份、備份驗證和時間點復原 (PITR) 功能。預設會加以啟用，而且在含有多個可用區的執行個體中必須使用這些功能。系統每天都會自動備份，預設資料保留政策為七份備份副本和七天的二進位記錄檔 (PITR 所需)。您可以在「進階選項」區段調整資料保留政策。

資料庫標記是連結至 my.cnf 檔案的伺服器設定。這裡列出了可設定的資料庫標記，以及某些無法設定的代管標記。建議您檢查資料庫標記，並在執行個體建立時將其設為適當的值。由於部分資料庫旗標並非動態，因此變更這些旗標會觸發執行個體重新啟動作業。

查看 character_set_server

在 MySQL 適用的 Cloud SQL 執行個體中，v5.6 與 v5.7 的預設 character_set_server 為 utf8，在 v8.0 上則為 utf8mb4。character_set_server 會將 character_set_server、character_set_server、character_set_server 和 character_set_server 設為相同值。如果是 character_set_system，在 v8.0 上預設為 utf8mb3。

如果您要遷移執行個體，且目前的設定使用不同的字元集 (例如 latin1)，請務必在新執行個體上明確設定 character_set_server。

查看 time_zone

時區的預設值為 system_time_zone，也就是世界標準時間。如要使用其他 time_zone，請透過 default_time_zone 設定。這個標記使用兩種格式：時區偏移 (例如 +08:00) 和時區名稱 (例如 America/Los_Angeles)。時區以時區名稱定義後，系統會自動調整為日光節約時間 (如適用)。default_time_zone 標記並非動態，因此必須重新啟動資料庫執行個體才能變更。

啟用慢速查詢記錄

根據預設，slow_query_log 會設為「OFF」。強烈建議您啟用慢速查詢記錄，並將 slow_query_log 設為應用程式適合的門檻。慢速查詢記錄可協助您擷取長時間執行的查詢，以便進行分析及最佳化。此資訊不僅對個別查詢有幫助，也對整體伺服器處理量以及對非預期的工作負載進行回溯分析有幫助。

查看 innodb_buffer_pool_size

對於 InnoDB 效能而言，這是最有效的設定。可在記憶體中緩衝的資料越多，伺服器效能就會越高。同時，全域緩衝區和每個執行緒動態緩衝區都必須保留足夠的記憶體。

在 Cloud SQL 中，innodb_buffer_pool_size 旗標的預設值、允許的下限值與允許的上限值皆取決於執行個體的記憶體，詳情請參閱說明文件。

好的 innodb_buffer_pool_size 不一定要包含所有資料，只需要經常存取的資料。反映緩衝區集區效率的狀態變數為 Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests。Innodb_buffer_pool_read_requests 是邏輯讀取要求的數量，而 Innodb_buffer_pool_read_requests 是緩衝集區不符合的邏輯讀取次數，就必須從磁碟讀取。在理想情況下，資料完全位於緩衝集區中，Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests 的比率將接近零。監控這些變數可瞭解 InnoDB 緩衝區集區效率。如果 innodb_buffer_pool_size 已達到允許的最大值，緩衝集區效率不佳，且應用程式發生查詢效能問題，請考慮將執行個體升級至較高的記憶體容量。

這個變數在 MySQL v5.7 和 v8.0 中會變成動態，而在 v5.6 中，進行變更將需要重新啟動執行個體。

查看 innodb_log_file_size

在 8.0.30 之前，innodb_log_file_size 和 innodb_log_file_size 並非動態，且變更 innodb_log_file_size 需要正常關機作業。在 8.0.30 版，推出 innodb_redo_log_capacity 以取代 innodb_redo_log_capacity 和 innodb_redo_log_capacity。  

MySQL 適用的 Cloud SQL 執行個體的設定方式為 innodb_log_file_size=512 MB，innodb_log_file_size=2 (或 innodb_log_file_size=1 GB)。如此一來，InnoDB 就可以在不同步到磁碟的情況下保留更多緩衝區集區變更，進而提升伺服器效能。大型重做記錄檔的缺點是增加了當機復原時間。視執行個體的高可用性要求和設定而定，這項決策必須在效能和可用性之間取得平衡。

一般來說，我們建議，重做記錄檔容量要足以容納一個小時的寫入活動。衡量的一個方法是全天觀測 Innodb_os_log_written 並確保 Innodb_os_log_written * Innodb_os_log_written 的大小足夠用於尖峰觀測的時間。

查看 innodb_log_buffer_size 

在 MySQL v5.6 和 v5.7 中，innodb_log_buffer_size 並非動態，因此必須重新啟動執行個體才能進行變更。因此，建議您在初始化時設定這個 API。

當 innodb_log_buffer_size 大到可以包含整筆交易時，在交易執行期間不會另外清除磁碟。根據預設，innodb_log_buffer_size 設定為 16MB，通常就夠了。不過，如要瞭解大型交易是否需要更大的緩衝區，請在發出大型交易時監控 Innodb_log_waits 狀態變數。如果 innodb_log_buffer_size 太小且需要等待清除，innodb_log_buffer_size 會增加 1。

隨時調整動態變數

部分與效能相關的資料庫標記為動態，例如 table_open_cache、thread_cache_size。一開始最好先設定適當的大小，但還是建議您建立測量指標，並視需求進行調整。

table_open_cache 用於已開啟資料表的數量。有足夠的快取有助於縮短資料表開啟時間，進而提高查詢效能。狀態變數 Opened_tables 會顯示已開啟的資料表數量。如果 Opened_tables 持續成長，請考慮提高 Opened_tables。

thread_cache_size 用於快取執行緒，以便在用戶端中斷連線後重複使用。如果執行個體需要同時進行大量新連線，請設定更大的大小。從狀態變數 Threads_created 和 Connections 的比率，可看出執行緒快取的效率。偏低的比率較好。

對每個執行緒記憶體標記最好進行較保守的設定

每個執行緒的記憶體緩衝區會影響查詢效能，例如 tmp_table_size、tmp_table_size、tmp_table_size、tmp_table_size 等。這些變數同時涵蓋全域和工作階段範圍。全域範圍會為所有新連線設定每個執行緒的值，而工作階段範圍適用於目前工作階段中的後續查詢。這類設定的記憶體容量較大，有助於提升查詢效能。不過，由於這類變數是動態的，且會為每個執行緒配置一或多個變數，因此可能會導致記憶體不足 (OOM) 的情況。

建議針對全域值使用中度數值，並在特定工作階段保留較大的數字，以受到控管的方式獲得更好的效能。

考慮 performance_schema

在 MySQL 8.0.26 之前，performance_schema 預設為「OFF」，需要重新啟動才能開啟。Performance_schema 可以啟用各種檢測，並提供豐富的資料來分析伺服器作業，但同時也會產生效能和記憶體費用。預設檢測會產生約 5% 的效能下降，而且隨著加入更多檢測，其效能也會持續下降。請以工作負載做為檢測基準，因為記憶體用量可能會成長至 1GB 以上。您可以在 memory_summary_global_by_event_name 資料表中觀察這個記憶體用量。

建立 Cloud SQL 執行個體之後，資料庫中還有一個 ‘root’@’%’ 使用者。您可能需要建立其他資料庫使用者。

限制使用者只能存取所需的作業

請務必將使用者的存取權限制在最低必要限度。

透過 MySQL CLI 建立使用者時，您必須明確授予權限。

透過 Cloud 控制台建立使用者時，該使用者將擁有與 ‘root’@’%’ 使用者相同的權限。在 MySQL 5.6 和 5.7 版中，預設權限包含具備授權選項的所有權限，但 SUPER 和 FILE 權限除外。在 8.0 版中，使用者具備動態權限，雖然 SUPER 和 FILE 權限仍受限，但使用者可以存取更多管理員角色 (例如 APPLICATION_PASSWORD_ADMIN、APPLICATION_PASSWORD_ADMIN、APPLICATION_PASSWORD_ADMIN、APPLICATION_PASSWORD_ADMIN 和 APPLICATION_PASSWORD_ADMIN)。您必須透過 MySQL CLI 撤銷所有不必要的權限。在 8.0 版執行個體中，會啟用 partial_revokes 變數。

考慮將 ‘root’@’%’ 改為特定管理員使用者

‘root’@’%’ 使用者是預設且最熱門的超級使用者，因此常遭駭客鎖定。我們建議您建立與 ‘root’@’%’ 使用者相同的權限組合，然後建立自己的管理員使用者，然後再替換使用者，藉此提升安全性。

監控和追蹤資料庫作業與系統資源的各個層面非常重要。這可讓您檢視及分析執行個體在一段時間內的作業健康狀態，也有助於規劃資源。

• Cloud 控制台總覽頁面會提供核心指標的清單。
• Cloud Monitoring 提供了其他指標。您可以使用針對資料庫執行個體選取的指標，建立資訊主頁。在 Cloud 控制台左上方的導覽選單中，依序選擇「作業」>「Monitoring」即可存取 Cloud Monitoring。
• 使用 Cloud SQL 的查詢洞察，可查詢效能分析。其總覽區段會依據資料庫、使用者或用戶端位址顯示 CPU 負載。CPU 使用率也會細分，以顯示 I/O 等待和鎖定等待時間。也會依查詢摘要列出熱門查詢。每個查詢摘要都會顯示平均執行時間、查詢數量，以及掃描和傳回的平均資料列數。這些指標有助於找出需要最佳化的熱點和查詢。
• 您也可運用自家開發的監控工具和/或第三方工具，補強上述各項工具的不足之處。主要目標是瞭解哪些資料庫作業可能會影響到伺服器和查詢的最佳化與疑難排解。

適當的警示對於伺服器健康狀態至關重要。它們可防止服務中斷，例如記憶體不足 (OOM)，或因 CPU 使用率過高所導致的系統停擺。

如果您使用 Cloud Monitoring，就能建立指標型警示。詳情請參閱說明文件。

如果您使用其他監控工具，請務必設定警示。

如要增加讀取作業，請考慮新增唯讀備用資源。您可以使用 HAProxy、ProxySQL 或其他負載平衡器將讀取作業分散到多個唯讀備用資源中。

Cloud SQL 也支援鏈結複製功能，詳情請參閱串聯式備用資源的說明。

唯讀備用資源使用的 MySQL 版本與主要執行個體相同。建立後，您可以選擇將備用資源升級為主要資源。

高可用性解決方案可以在相同區域的次要可用區中提供資料備援功能。災難發生時，某個區域可能無法使用。在災難復原計畫中，跨區域唯讀備用資源是強大的資源，可以視需要升級為主要執行個體。詳情請參閱說明文件。