在 Compute Engine 上設定 MySQL

Compute Engine 提供多種不同的執行個體類型和儲存空間選項，可用於讀取及寫入 MySQL 資料庫中的資料。為確保資料庫工作負載達到���佳效能和成本，我們建議您使用新一代基礎架構即服務 (IaaS) 產品。

下列設定建議會考量 MySQL 工作負載經常用於讀取量高的系統，例如線上交易處理 (OLTP) 或支援一般網頁應用程式的資料庫。這些設定也考量了常見的設定選項，例如使用 MySQL 8.0 以上版本，以及使用 InnoDB 儲存引擎。對於效能敏感的工作負載，您可能需要調整設定以配合需求。建議您以本指南做為部署作業的起點，然後使用實際工作負載進行測試，驗證設定是否��合您的需求。

選擇虛擬機器 (VM)

針對 MySQL 工作負載，建議您使用最新一代的 C 和 N 機器系列，因為這些系列包含的形狀可與大多數實用的 MySQL 設定搭配使用。如要瞭解這些機器系列，請參閱以下Google Cloud 網誌文章。這些機器系列使用 Titanium，並以最新一代 Intel、AMD 和 Axion 處理器為基礎。

著重於效能

對於效能敏感的工作負載 (例如對業務至關重要的 MySQL 資料庫)，如果您所在區域提供最新的 C4 和 C4A 執行個體，建議您使用這些執行個體。如果您無法存取這些資源，C3 和 C3D 執行個體也能提供類似的成效。

這些執行個體可為運算限制作業提供最低且最穩定的延遲時間，並提供下列實用功能，以便針對以效能為主的作業負載���行最佳化：

  • 透過提前通知控管主機維護事件
  • 控制單核心渦輪加速功能，提高效能一致性
  • Tier_1 網路：提供更高的網路頻寬

如果您使用的是 C4A、C3 或 C3D 執行個體，也可以使用本機固態硬碟 (本機 SSD) 來滿足特定效能需求。

以成本為優先

如果工作負載的主要目標是降低成本，例如流量偏低或中等的 MySQL 資料庫，或是用於測試或開發環境的資料庫，建議您使用最新的 N4 執行個體。這些執行個體會使用 Compute Engine 的下一代動態資源管理功能，在維持穩健效能的同時，盡可能降低總成本，但不會提供 C4、C4A、C3 和 C3D 的強力保��。詳情請參閱「新一代動態資源管理」。

設定 VM 的大小

對於您使用的任何 VM，請務必根據您期望的 MySQL 效能等級，選擇適當的 VM 大小。

如果您希望每秒寫入交易 (TPS) 的效能高，請考量區塊儲存空間。詳情請參閱本頁後續的「設定區塊儲存空間」一節。

如果您希望提升每秒讀取查詢次數 (QPS) 效能，強烈建議您使用 MySQL 的 RAM 緩衝區，以便快取熱門資料並減少磁碟存取次數。如要充分發揮這些優勢，請按照下列步驟操作：

  • 選擇 VM 大小時，請確保工作集 (或資料庫一次處理的資料總量) 可放入緩衝區集區。
  • 調整緩衝區集區的大小，以便使用 VM 上的大部分 RAM。

為盡量降低這種 VM 的大小設定費用，建議您使用 RAM 與虛擬 CPU (vCPU) 比率較高的 VM，以免為未使用的 vCPU 付費。

如要為大多數 MySQL 工作負載取得最佳平衡，請先判斷工作負載的工作集合，然後選擇最適合該工作集合在 RAM 中運作的最小 highmem 執行個體規格。highmem 執行個體配置的每個 vCPU 約有 8 GB 的 RAM。這樣一來，您就能有足夠的記憶體來快取大型工作組，同時保留足夠的 CPU 來處理高查詢負載。

如果工作負載的工作集很大，但查詢率偏低，您可以使用 N4 執行個體，並搭配自訂機器類型和擴充記憶體，進一步提高 RAM 與 vCPU 的比率，進而進一步降低總成本。

設定 VM 的網路頻寬

對於大多數 MySQL 用途，您可以維持執行個體的預設網路頻寬限制。如果這項做法符合您的需求，您就不需要升級至 Tier_1 網路。

設定區塊儲存空間

Google Cloud Hyperdisk 是目前 Compute Engine VM 系列可用的唯一一代耐用區塊儲存空間。我們認為 Hyperdisk Balanced 最適合絕大多數的 MySQL 工作負載。如要進一步瞭解 Hyperdisk，請參閱 Hyperdisk 說明文件。

Google Cloud Hyperdisk

Hyperdisk Balanced 提供下列功能：

  • 低成本的固態硬碟 (SSD) 延遲
  • 針對需要高效能設定的應用程式提供高效能設定
  • 耐用性高達 99.999%，可防範業界普遍存在的硬體�����和資料������風險
  • 使用 Google 代管或客戶自行管理的加密金鑰，對所有 Hyperdisk 靜態資料進行加密

選取成效等級

使用 Hyperdisk Balanced 時，您可以獨立選取磁碟的儲存空間大小和效能等級，藉此盡量提升資料庫效能，同時只需支付工作負載所需的輸入/輸出 (I/O) 資源費用。如果 MySQL 資料庫的緩衝區集區大於其工作集，則在穩定狀態作業期間，它可以從緩衝區集區提供幾乎所有讀取查詢，而無需使用磁碟。

如要為 Hyperdisk 磁碟區選取效能等級，請考量 MySQL 寫入工作負載，特別強調下列事項：

  • 存取 InnoDB 重做記錄
  • InnoDB 資料檔案和索引的後續更新

在穩定狀態作業之外，資料庫維護事件也可能會導致磁碟效能變差。發生這種情況的頻率通常會隨著資料庫的寫入工作負載而增加，因此在使用重做記錄的異常狀況復原或備份系統透過讀取上次備份後的所有資料庫變更來複製自身的情況下，發生這種情況的可能性會更高。

調整磁碟大小

有三種常見的策略可用來設定磁碟效能限制：

  1. 使用預設設定。每個磁碟至少提供 3,000 個輸入/輸出作業/秒 (IOPS) 和 140 MiBps 的處理量。這項功能足以處理基本 MySQL 工作負載和作業系統 (OS) 啟動磁碟。如果用途超出這個範圍，您可以視需要修改已佈建的 I/O 效能，而無須停止工作負載。
  2. 評估現有用量。如果資料庫已在其他環境中運作，請以一分鐘或更短的時間間隔記錄磁碟 IOPS 和處理量。取得一至兩週的資料後，您便可在樣本集合中納入負載和正常維護事件的波動，從資料集中選取高百分位數值，並加入一點緩衝區，以因應自然成長或意外使用情形。
  3. 預估需求，然後再修改。如果您沒有現有的資料來源，可能需要先預估效能需求，然後在部署後進一步調整。建議您一開始設定比預期需求更高的值，以免工作負載遇到效能瓶頸，然後再根據工作負載降低已配置的效能。

提升磁碟效能

您可以將每個 Hyperdisk Balanced 磁碟的效能提高至最多 160,000 IOPS，總處理量則可達 2,400 MBps。VM 的大小有助於決定 Hyperdisk 的最大效能限制，因此如果您想要獲得極高的 Hyperdisk 效能，可能需要增加 VM 的核心數量。如果您最嚴苛的工作負載需要比單一 Hyperdisk Balanced 磁碟更高的磁碟效能，可以使用下列任一方法將多個 Hyperdisk Balanced 磁碟劃分為區塊：

  • 升級至 Hyperdisk Extreme
  • 使用其他軟體容錯式磁碟陣列 (RAID) 機制，例如 mdadm

擴充 MySQL 資料庫時，您可以動態增加磁碟的容量和效能，且不必停機。這有助於線上分析處理 (OLAP) 類型工作負載的效能，因為���些工作負載會執行無法放入 RAM 且會溢出至磁碟的大型複雜彙整作業。在少數情況下，需要極低儲存空間延遲時間且可容許資料遺失的 MySQL 工作負載，可以將完整的資料集儲存在本機 SSD 上。您也可以使用下列混合式解決方案，改善讀取延遲情形，並限制耐用性的降低：

  • 在 Hyperdisk 和本機 SSD 之間鏡像資料集。
  • 使用磁碟區管理工具，將本機 SSD 設為快取，用於儲存在底層 Hyperdisk 上的資料。

充分利用其他 Hyperdisk 功能

Hyperdisk 也提供下列功能，可增強或簡化內部高可用性和災難復原工作流程：

如要進一步瞭解如何使用 MySQL for Compute Engine 設定這些功能，請參閱本頁後續的「高可用性」一節。

本機 SSD

部分 Compute Engine 機器系列可讓您使用本機 SSD 取代 Hyperdisk。這些並非耐用性儲存空間，但 MySQL 工作負載通常會使用這些空間來儲存暫時性資料表空間。

如要進一步瞭解如何使用本機 SSD 來調整 MySQL 資料庫，請參閱本頁後續的「動態磁碟大小調整」一文。

其他 Compute Engine 功能

您可以使用下列 Compute Engine 功能，協助最佳化 MySQL 部署作業。

Cloud Monitoring

如要監控 VM 的效能和基礎架構服務用量，請使用Google Cloud 控制台。在「VM 執行個體」頁面的「可觀察性」分頁中，您可以監控與效能相關的指標，例如 CPU 和記憶體使用率、網路頻寬，以及執行個體的已配置效能。同樣地，您也可以在「磁碟」頁面的「觀測能力」分頁中，監控磁碟磁碟區的總處理量和 IOPS。

如要自訂所顯示的效能指標，請使用 Cloud Monitoring 建立查詢。您可以選取要查看基礎架構服務的特定成效指標。針對 MySQL 專屬指標，Compute Engine 提供 MySQL 工作負載外掛程式。

設定作業系統的最佳做法

  • 使用適當的檔案系統。Google 著重於為 Linux 的 ext4 和 XFS 檔案系統進行最佳化，但大多數檔案系統都適合與 MySQL 搭配使用。
  • 在基本作業系統設定中關閉透明巨型頁面 (THP)。如要瞭解關閉 THP 的步驟，請參閱 THP 說明文件。
  • 如果您使用的是 Linux，請使用 relatime 和 lazytime 旗標設定檔案系統掛接設定。這可減少在讀取、修改檔案或變更其中繼資料時，更新檔案上 atime、mtime 和 ctime 值所產生的效能額外負擔。

設定 MySQL 的最佳做法

建議您使用下列 MySQL 設定。

  • 使用最新版本的 MySQL。Google 會著重於為 MySQL 8.0 以上版本進行最佳化。

  • 增加緩衝區集區的大小。MySQL 會使用緩衝區來快取記憶體中的資料，進而減少磁碟存取次數，提升讀取效能。根據預設，MySQL 的緩衝區集區大小為 128 MiB，對大多數實際用途而言過小。建議您將 innodb_buffer_pool_size 的大小增加到大於應用程式在資料庫中存取的工作集大小。這通常包含下列步驟：

    1. 在 MySQL 執行個體的執行中副本上，測量或估算工作集的大小。
    2. 選擇虛擬機器 (VM) 大小和形狀，並提供足夠的 RAM 來容納該工作集。
    3. 設定 VM 上的緩衝區集區大小，以便佔用大部分可用的 RAM。

  • 開啟雙寫緩衝區。MySQL 有雙寫緩衝區，可協助防範撕裂寫入，這是一種失敗模式，如果在寫入過程中發生硬體或電源故障，涵蓋磁碟上多個區塊的寫入作業可能只會部分提交。如要享有這項防護功能，請開啟 innodb_doublewrite。

  • 將 innodb_flush_log_at_trx_commit 的值設為 1。這可確保寫入交易在提交時可在磁碟上持久化。

  • 如要降低效能額���負擔，請為 innodb_flush_method 指定值。針對 MySQL 8.0.14 以上版本，請將 innodb_flush_method 的值設為 O_DIRECT_NO_FSYNC，這是最佳做法，但僅適用於這些版本。如果是 8.0.14 以下版本的 MySQL，請將 innodb_flush_method 的值設為 O_DIRECT。

  • 在高可用性複寫情況下，請將主要資料庫執行個體的 sync_binlog 值設為 1。MySQL 會使用二進位記錄檔，將主要資料庫的變更傳送至次要資料庫，確保二進位記錄檔會在交易提交時提交，並在資料庫之間產生盡可能低的複製延遲和復原點目標 (RPO)。

  • 在 C 系列機器系列上使用 MySQL 時，請開啟 innodb_numa_interleave。這可確保 MySQL 的緩衝區可利用非均勻記憶體存取 (NUMA) 政策。

何時關閉雙寫緩衝區

MySQL 的 doublewrite 緩衝區可防止分頁寫入，但會為 MySQL 寫入交易帶來高達 25% 的效能開銷，這可能會影響交易延遲時間。Google Cloud Hyperdisk 也提供破裂寫入保護功能，因此如果您使用 MySQL 直接寫入在 Hyperdisk 上執行的 ext4 檔案系統，可以安全地關閉雙寫緩衝區。

不過，為確保 Hyperdisk 的破碎寫入保護機制生效，您必須在資料庫和磁碟之間設定檔案系統和其他中介軟體層，以免在磁碟層上引入破碎寫入。下列清單列出可能會在 Hyperdisk 層以上引入破損寫入的設定範例：

  • 在容器中執行 MySQL 例項，例如 Google Kubernetes Engine 或自架 Kubernetes。
  • 將 MySQL 檔案儲存在 XFS 檔案系統中，但在大多數 Linux 核心設定中，該檔案系統不支援足夠大的區塊大小。
  • 將 MySQL 檔案儲存在獨立磁碟備援陣列 (RAID) 設定中，這會導致磁碟分割，例如 Linux 的 mdadm 或 Windows 的 Storage Spaces 和 Storage Spaces Direct。
  • 將 MySQL 檔案儲存在磁碟區管理工具上，例如 Linux 的 Logical Volume Manager (LVM) 或 Windows 的 Storage Spaces 和 Storage Spaces Direct。

  • 將 MySQL 檔案儲存在 Hyperdisk 上，並將本機固態硬碟 (SSD) 設為快取，例如使用 Linux 的 lvmcache、dm-cache 或 bcache，或是 Windows 的儲存空間。

  • 使用巢狀虛擬化在 VM 中執行 MySQL 例項。

雖然您可以設定上述設定，避免引入破碎的寫入作業，但我們不建議您在使用這些設定時關閉雙寫緩衝區，因為驗證特定設定是否安全的難度較高。

(選用) 關閉雙寫緩衝區

如要關閉雙寫緩衝區，請完成下列步驟：

  1. 在 ext4 檔案系統上，您必須啟用 bigalloc 功能，並將檔案系統的叢集大小設為 16 KiB，或 16 KiB 的 2 次方倍數。這可確保 MySQL 的寫入作業不會在發送至 Hyperdisk 前，遭到檔案系統分割成個別的 I/O。如果未提高限制，或使用小於 16KiB 的任何值，就無法防止寫入作業中斷。以下是叢集大小為 16KiB 的範例，這會在建立檔案系統時設定：

    mkfs.ext4 -O bigalloc -C 16384 /dev/<device-name>

  2. 停用 innodb_doublewrite，並將 innodb_flush_method 設為 O_DIRECT 或 O_DIRECT_NO_FSYNC (視您使用的 MySQL 版本而定，如上所述)。

設定高可用性 (HA) 和備份解決方案

強烈建議您為所有關鍵 MySQL 工作負載設定高可用性 (HA) 和備份解決方案，以便加以保護。對於 HA 和備份，以下因素最為重要：

HA 解決方案通常會將 RTO 和 RPO 設為接近零，但只會防範基礎架構故障。備份解決方案的 RTO 和 RPO 時間較長，但可涵蓋更多失敗情境，例如：

  • 意外刪除資料
  • 勒索軟體攻擊
  • 天災

設定高可用性 (HA)

HA 功能會使用儲存空間和運算冗餘功能，確保 MySQL 資料庫在主機故障或停機時，仍能縮短停機時間，讓用戶端應用程式即使在執行個體或區域無法使用時，也能存取資料。

MySQL 允許在下列模式中進行複製：

  • 非同步模式：在非同步模式下，主要資料庫會在本機提交寫入交易後立即確認，因此如果主要資料庫發生中斷，在容錯移轉期間可能會遺失少量最近寫入的資料，因為 RPO 接近零，但實際上並非零。
  • 半同步模式。在半同步模式中，主要節點會等待確認交易，直到可設定數量的複本已確認收到交易為止。由於 RPO 實際上為零，因此在未預期的容錯移轉期間，資料遺失的機率大幅提高。

無論是哪種模式，RTO 都會根據健康檢查執行下列操作的速度而定：

  1. 找出失敗的執行個體。
  2. 觸發容錯移轉。
  3. 使用網域名稱系統 (DNS) 或其他方法識別資料庫伺服器，通知用戶端備援執行個體現在是主要執行個體。

無論採用哪種複製作業模式，您都必須有可複製的容錯移轉執行個體。您可以在下列任一處找到該執行個體：

  • 與主要執行個體位於相同區域
  • 位於主機所在區域內的不同區域
  • 位於主要區域以外的區域

為確保在區域停機期間仍能維持高可用性，建議您採用下列設定：

  • 將主要和容錯移轉執行個體放在不同的區域，無論這兩個執行個體是否位於同一個地區。
  • 使用非同步複製功能。這是因為如果您使用半同步複寫，將主要執行個體和容錯移轉執行個體放在不同的區域，可能會導致寫入交易提交作業的延遲時間過長。
  • 如果您需要零 RPO，請使用 Hyperdisk 平衡高可用性，這樣就能在相同區域的兩個可用區中同步複製磁碟。詳情請參閱 Google 的 Hyperdisk High Availability 服務提供指南。設定 Hyperdisk 平衡高可用性時，建議您整合有狀態的 Managed Instance Groups，以便診斷執行個體健康問題，並自動執行復原動作。

設定備份和資料復原計畫

備份和資料復原計畫有助於在發生意外資料刪除、勒索軟體攻擊和天災等故障情況時，避免資料遺失。您也可以將這些資料做為冷儲存空間，以符合法規和稽核要求。針對 MySQL，您可以選擇多種備份方法，其中有些方法會在資料庫層級運作，有些則會在儲存空間卷層級運作。在選用方法時，請優先考量 RTO 和 RPO 需求。

在資料庫層級備份

如要進行資料庫層級備份，請考慮使用 MySQL 提供的以下選項：

如要進一步瞭解 MySQL 的資料庫層級備份選項，請參閱 MySQL 說明文件中的「備份與復原」一節。

無論您選擇哪一種方法，都必須有次要儲存系統來複製備份資料。我們建議使用下列工具：

使用 Hyperdisk 在儲存層級建立快照和複本

如要進行儲存空間層級備份，建議您使用 Hyperdisk 產品來擷取 MySQL 資料庫的快照、複本或其他時間點檢視畫面。這個方法的 RPO 取決於您擷取資料庫快照的頻率，而 RTO 則取決於您使用的特定解決方案。

如果您重視快速復原功能，且只需要在區域內提供備份服務，建議您使用 Hyperdisk 的即時快照功能。即時快照會以遞增方式在特定時間點擷取資料，並可透過磁碟複製功能快速���資料還原至新的 Hyperdisk 磁碟區，提供分鐘等級的 RTO。當磁碟的內容遭到覆寫、刪除或毀損，且在本機中與來源磁碟位於相同區域時，您可以使用這些磁碟來復原資料。詳情請參閱「關於即時快照」

針對災難復原情境，資料必須以比原始磁碟更高的冗餘性儲存，並儲存在不同的位置，以確保單一災難不會影響所有資料的複本，因此建議您使用 Hyperdisk 的封存和標準磁碟快照。封存快照和標準磁碟快照會在某個時間點建立磁碟資料的複本，並以無法變更的格式以高冗餘率儲存。建立磁碟的多個快照 (例如使用快照排程) 時，Hyperdisk 只會儲存增量變更。如果您可以容許更高的 RTO，封存快照和標準磁碟快照就很適合，因為從快照儲存空間複製回 VM 儲存空間的資料，可能需要較長的還原時間。詳情請參閱「建立封存和標準磁碟快照」。

Hyperdisk 的即時快照、封存快照和標準快照，在單一磁碟內都具有相容性。也就是說，從快照還原時，MySQL 資料庫必須執行一般 InnoDB 復原步驟，才能將記錄和資料檔案恢復至一致狀態。視 InnoDB 重做記錄的設定而定，這可能會延長 RTO。下列模式可能會讓您更難建立一致的資料庫快照：

  • MySQL 資料庫檔案分散在多個磁區中。
  • 您使用的是 Linux 軟體 RAID 公用程式，例如 mdadm。
  • 您已將 MySQL 設定的儲存位置分隔在不同磁碟的檔案系統中。

如要建立快照，且在快照還原後不需要復原，請完成下列步驟：

  1. 暫時鎖定 MySQL 資料庫的寫入存取權。
  2. 使用 LOCK INSTANCE FOR BACKUP 和 FLUSH TABLES WITH READ LOCK 指令，將所有進行中的緩衝區刷新至磁碟。
  3. 啟動快照作業。

  4. 在多磁碟情況下，在 MySQL 層級刷新後，請在伺服器上執行 sync 和 fsfreeze 指令，將所有進行中的寫入作業刷新至磁碟，並在檔案系統層級暫停新的寫入作業。

擷取資料庫的初始快照後，您就不需要繼續鎖定磁碟，因為 Hyperdisk 可快速擷取時間點檢視畫面，然後以非同步方式處理後續的任何儲存空間複製步驟。如果您需要快照一致性，且想移除對主要資料庫的寫入影響，也可以針對資料庫副本而非主要資料庫執行���份。

後續步驟