返回文章列表
玄貓（BlackCat）

雲端MySQL佈署管理與效能最佳化

本文探討在雲端環境中佈署和管理 MySQL 的策略，涵蓋了受管服務（如 AWS Aurora 和 GCP Cloud SQL）和虛擬機器佈署的優缺點，並探討如何選擇合適的硬體規格（CPU、記憶體、網路和磁碟）以最佳化 MySQL 效能。此外，文章也涵蓋了資料函式庫合規性議題，探討了 SOC 2、SOX、PCI

資料函式庫 雲端運算
MySQL AWS GCP 資料函式倉管理 效能調校 雲端佈署

隨著雲端技術的普及，MySQL 的佈署和管理也逐漸轉向雲端。選擇合適的佈署方式，例如 AWS Aurora、GCP Cloud SQL 等受管服務，或是在虛擬機器上自行管理，需要考量團隊的技術能力和業務需求。受管服務簡化了許多操作任務，但可能犧牲部分控制權；虛擬機器佈署則提供了更大的彈性，但需要自行處理維護和最佳化工作。效能調校方面，CPU、記憶體、網路和磁碟 I/O 都是關鍵因素。CPU 使用率應維持在合理範圍，避免過多的上下文切換；記憶體組態需充足，以滿足工作資料集的需求；網路頻寬需足夠，尤其是在跨區域複製和備份時；磁碟型別則需根據 IOPS 和吞吐量需求選擇 SSD 或 HDD。

MySQL 在雲端環境中的佈署與管理

隨著雲端運算技術的成熟，越來越多的企業選擇將其資料函式庫環境遷移到雲端。對於 MySQL 資料函式庫來說，雲端佈署提供了更高的可擴充套件性、靈活性和可靠性。在本章中，我們將探討在雲端環境中佈署 MySQL 的主要選項，包括受管理的 MySQL 服務和根據虛擬機器的佈署方式。

受管理的 MySQL 服務

受管理的 MySQL 服務是雲端供應商提供的一種便利的資料函式庫解決方案，旨在減少團隊在營運 MySQL 時的認知負擔。不同的公有雲供應商對受管理的 MySQL 資料函式庫有不同的實作方式。例如，Amazon Web Services（AWS）提供了多種 Aurora MySQL 的版本。

Aurora MySQL 的特點

Aurora MySQL 是 AWS 提供的一種相容於 MySQL 的關聯式資料函式庫服務，具有高效能、高用性和高安全性。它支援多種 MySQL 功能，如複製、備份和安全功能。

根據虛擬機器的佈署

除了受管理的 MySQL 服務外，開發人員也可以選擇在虛擬機器（VM）上佈署 MySQL。這種方式提供了更大的靈活性，允許開發人員根據自己的需求組態和最佳化資料函式庫環境。

虛擬機器佈署的考量

在虛擬機器上佈署 MySQL 需要考慮多個因素，包括虛擬機器的規格、磁碟型別和維運複雜度。選擇合適的虛擬機器規格和磁碟型別對於確保資料函式庫效能和可靠性至關重要。

選擇虛擬機器規格

選擇虛擬機器規格時，需要考慮 CPU、記憶體和儲存資源的需求。MySQL 資料函式庫需要足夠的 CPU 和記憶體資源來處理查詢請求，同時需要足夠的儲存空間來儲存資料。

磁碟型別的選擇

MySQL 資料函式庫的效能也受到磁碟型別的影響。固態硬碟硬碟（SSD）提供了比傳統硬碟更好的效能，但成本較高。開發人員需要根據自己的效能和預算需求選擇合適的磁碟型別。

ProxySQL 在雲端環境中的應用

ProxySQL 是一種強大的資料函式庫代理工具，可以用於最佳化 MySQL 資料函式庫的效能和可擴充套件性。在雲端環境中，ProxySQL 可以幫助開發人員更好地管理資料函式庫連線、查詢路由和資料分片。

ProxySQL 的主要功能

ProxySQL 提供了多種功能，包括連線池、查詢路由、TLS 支援和結果集快取。這些功能可以幫助開發人員最佳化資料函式庫效能、提高可擴充套件性和增強安全性。

未來趨勢與建議

未來，隨著雲端運算技術的不斷發展，MySQL 在雲端環境中的佈署和管理將變得更加便捷和高效。開發人員需要持續關注新的技術和趨勢，以便更好地最佳化和管理自己的資料函式庫環境。

關鍵建議
  1. 選擇合適的佈署方案：根據自己的需求和預算選擇受管理的 MySQL 服務或根據虛擬機器的佈署方式。
  2. 最佳化資料函式庫效能：使用 ProxySQL 等工具最佳化資料函式庫效能和可擴充套件性。
  3. 持續關注新技術：關注新的技術和趨勢，以便更好地最佳化和管理自己的資料函式庫環境。

透過遵循這些建議，開發人員可以在雲端環境中構建高效、可靠的 MySQL 資料函式庫環境，以支援業務的持續增長和發展。

MySQL 在雲端的管理與應用

隨著雲端運算的發展，越來越多的資料函式倉管理服務被提供，像是 Amazon Web Services (AWS) 的 Amazon Aurora、Google Cloud Platform (GCP) 的 Cloud SQL 等。這些服務提供了便捷的資料函式庫設定和管理功能，讓企業和團隊能夠快速啟動和執行。

管理式 MySQL 的優缺點

管理式 MySQL 服務的最大優點是提供了易於存取的資料函式庫設定，無需深入瞭解 MySQL 的具體細節。只需點選幾下或使用 Terraform 即可啟動資料函式庫並進行複製和備份。然而，管理式 MySQL 也有其缺點，例如缺乏可視性和控制權。使用者無法存取作業系統或檔案系統，也無法對流程進行深入的控制。

Amazon Aurora for MySQL

Amazon Aurora 是 AWS 提供的一種 MySQL 相容的託管資料函式庫服務。Aurora 最吸引人的特點是將運算與儲存分離，使得這兩者可以獨立擴充套件。Aurora 管理了許多操作任務，例如快照備份、快速架構變更、稽核日誌記錄和單一區域內的複製。

相容性注意事項

當 Amazon 稱 Aurora 為「MySQL 相容」時，需要確認其相容的 MySQL 主要版本。目前，Aurora 尚未支援 MySQL 8.0，相容性需在應用程式測試中驗證。

Aurora 的不同版本

Aurora 提供了多種版本，包括標準版、Serverless 版、Global Database 和 Multi-Master 版。標準版提供長期的運算例項；Serverless 版則根據工作負載動態調整運算資源；Global Database 支援跨區域的資料可用性；Multi-Master 版允許多個運算節點同時接受寫入。

Aurora 的選擇與權衡

在選擇 Aurora 版本時，需要考慮不同的權衡。例如，無法同時實作多寫入高用性和跨區域次秒級複製。圖 12-1 提供了一個決策樹，幫助您根據需求選擇合適的 Aurora 版本。

其他雲端供應商的 MySQL 服務

除了 AWS 的 Aurora 外，其他雲端供應商如 GCP 也提供了自己的 MySQL 服務。這些服務各有其特點和優勢，需要根據具體需求進行選擇。

內容解密：

本段落主要介紹了雲端 MySQL 管理服務的現狀和特點，並以 Amazon Aurora 為例，詳細闡述了其功能、優缺點和不同版本。同時，也提到了其他雲端供應商的 MySQL 服務。接下來，我們將繼續探討如何在雲端環境中選擇和管理 MySQL 服務。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 雲端MySQL佈署管理與效能最佳化

package "資料庫架構" {
    package "應用層" {
        component [連線池] as pool
        component [ORM 框架] as orm
    }

    package "資料庫引擎" {
        component [查詢解析器] as parser
        component [優化器] as optimizer
        component [執行引擎] as executor
    }

    package "儲存層" {
        database [主資料庫] as master
        database [讀取副本] as replica
        database [快取層] as cache
    }
}

pool --> orm : 管理連線
orm --> parser : SQL 查詢
parser --> optimizer : 解析樹
optimizer --> executor : 執行計畫
executor --> master : 寫入操作
executor --> replica : 讀取操作
cache --> executor : 快取命中

master --> replica : 資料同步

note right of cache
  Redis/Memcached
  減少資料庫負載
end note

@enduml

此圖示說明瞭選擇 Aurora 版本時的考量因素。

在選擇 MySQL 服務時，需要考慮多個因素，包括效能、成本、可用性和擴充套件性等。根據具體需求，選擇合適的雲端供應商和服務版本，才能確保資料函式庫系統的最佳執行狀態。

在雲端環境中選擇適當的MySQL佈署方式

在雲端佈署MySQL資料函式庫時，選擇適當的佈署方式對於確保資料函式庫的效能、可用性和成本效益至關重要。目前，雲端供應商提供了多種MySQL佈署選項，包括受管理的MySQL服務（如AWS Aurora和GCP Cloud SQL）和在虛擬機器（VM）上自行佈署MySQL。

受管理的MySQL服務

受管理的MySQL服務，如AWS Aurora和GCP Cloud SQL，提供了方便的MySQL佈署和管理體驗。這些服務管理了許多操作任務，如高用性支援、資料加密和升級維護。

GCP Cloud SQL

GCP Cloud SQL是Google Cloud的受管理MySQL服務。與AWS Aurora類別似，Cloud SQL執行的是社群版MySQL伺服器，但為了支援多租戶和受管理的功能，一些功能被停用了。例如：

  • SUPER許可權被停用。
  • 載入外掛被停用。
  • 一些客戶端工具，如mysqldump和mysqlimport，被停用。

儘管如此，Cloud SQL仍然提供了許多有用的功能，如：

  • 原生高用性支援，容錯移轉透過組態選項自動化。
  • 資料靜態加密。
  • 使用多種方法靈活管理的升級。

選擇受管理的MySQL服務的考量

選擇受管理的MySQL服務時，需要考慮到這些服務的限制和優點。雖然它們提供了方便的管理和維護體驗，但也可能限制了對MySQL的某些自定義組態。

在虛擬機器上佈署MySQL

在虛擬機器上佈署MySQL提供了對資料函式庫環境的完全控制。這種方式允許根據具體需求進行自定義組態和最佳化。

虛擬機器的優勢

在虛擬機器上佈署MySQL的優勢包括：

  • 對MySQL的完全控制，可以根據需求進行組態和最佳化。
  • 可以設定跨區域的副本，用於災難還原。
  • 可以根據工作負載最佳化備份策略。

選擇虛擬機器的考量

選擇虛擬機器佈署MySQL時，需要考慮到CPU、記憶體和網路資源的組態。雲端供應商提供了多種虛擬機器型別，可以根據工作負載的需求進行選擇。

選擇適當的虛擬機器型別

選擇適當的虛擬機器型別需要考慮到工作負載的需求。以下是一些選擇虛擬機器型別時需要考慮的因素：

CPU資源

在選擇虛擬機器型別時，需要考慮到CPU資源的需求。可以使用以下公式估計所需的vCPU數量：（核心數量 × 95%總CPU使用率）× 2。

記憶體資源

記憶體資源對於MySQL的效能至關重要。需要根據工作負載的需求選擇適當的記憶體組態。

網路資源

網路資源對於MySQL的效能和可用性至關重要。需要根據工作負載的需求選擇適當的網路組態。

在雲端選擇適合的硬體規格以最佳化MySQL效能

在雲端環境中佈署MySQL時，選擇適當的硬體規格是確保資料函式庫效能的關鍵。我們將探討如何根據CPU、記憶體、網路效能和磁碟型別等因素進行最佳化。

CPU使用率與上下文切換

隨著CPU使用率或核心數量的增加，上下文切換（context switching）的次數也會增加。上下文切換是指CPU在不同任務之間切換的過程。過高的CPU使用率（接近100%）會導致大量的上下文切換，從而浪費大量時間，並最終導致查詢延遲增加。我們建議將典型的CPU使用率控制在50%，峰值不超過65%–70%。如果持續超過70%，則需要考慮增加更多的CPU核心。

此外，CPU的晶片家族（chip family）也是一個重要的考量因素。對於高流量Web應用程式，選擇最新一代的CPU晶片可以提供更好的效能。而對於後端資料處理任務，較舊但稍微慢一些的CPU晶片可能就足夠，這樣可以節省成本。

記憶體組態

正如第1章和第4章所討論的，RAM對MySQL效能有著巨大的影響。選擇適合您工作資料集的機器規格時，應偏向於選擇記憶體較多的組態，而不是不足。

網路效能

除了CPU和記憶體之外，網路效能也是選擇機器型別時的重要考量。確保所選的機器型別不會限制應用程式的網路效能。例如，如果有批次處理任務需要讀取大量資料，則可能需要選擇具有更高網路頻寬的機器型別，以避免網路頻寬耗盡。

值得注意的是，雲端區域（zone）和區域（region）之間的網路輸出通常會產生額外的費用。在設定複本（replica）時，這可能會帶來驚喜，但我們仍然認為為了冗餘目的而將複本放置在不同的區域是重要的。

選擇正確的磁碟型別

儘管機器型別通常是動態的，但選擇資料儲存的磁碟型別可能是最複雜的決定。一旦選擇了磁碟型別並開始使用它來儲存資料，切換到另一種磁碟型別就會變得困難。通常，需要掛載第二個磁碟並複製資料。雖然不是不可能糾正，但肯定比簡單地重新啟動以新增更多CPU更為複雜。

磁碟連線方式

第一個需要做出的決定是選擇本地連線磁碟還是網路連線磁碟。本地連線磁碟具有提供極高效能和一致吞吐量的優點，但也容易發生資料遺失。這是因為它們被視為僅用於暫時性資料的磁碟。如果執行虛擬機器的硬體當機，您可能會遺失本地磁碟上的所有資料。同樣，在某些情況下，即使關閉例項也可能意味著當您再次啟動時，您位於不同的主機機器上，且磁碟為空。本地連線磁碟通常沒有任何複製或RAID支援。主機級別的磁碟故障可能會導致您遺失資料。如果選擇此路徑，我們強烈建議考慮使用軟體RAID至少以最小化資料遺失的風險。

相比之下，網路連線磁碟則提供了冗餘和可靠性，而非效能。這並不是說網路連線磁碟的效能不好——只是不如本地連線磁碟那樣高效能。您的網路連線磁碟可能會經歷停頓，而本地連線磁碟則可能不會。您通常也可以在本地實作更高的吞吐量和IOPS數字。

程式碼示例：RAID 組態

# 示例：使用mdadm建立RAID 10
sudo mdadm --create --verbose /dev/md0 --level=10 --raid-devices=4 /dev/sd[b-e]

內容解密：

  1. 使用mdadm工具建立RAID 10組態。
  2. --create選項用於建立新的RAID陣列。
  3. --verbose選項提供詳細輸出，有助於除錯。
  4. /dev/md0是新建立的RAID裝置名稱。
  5. --level=10指定RAID級別為10，提供平衡的效能和冗餘。
  6. --raid-devices=4指定參與RAID陣列的裝置數量。
  7. /dev/sd[b-e]列出參與RAID的物理裝置。

雲端供應商在您使用網路連線磁碟時提供便捷的備份或快照工具。假設您已組態ACID相容的設定 6 並且您的備份解決方案設計正確，這些工具對MySQL使用來說運作良好。您可以隨時擷取磁碟快照，並透過正常的當機還原來還原它，而不會有任何問題。

您還可以使用磁碟快照技術極快地建立複本，即使是在數TB大小的磁碟上也是如此。透過這樣做，您可以最小化複本需要追趕的複製延遲，以便使其可用。

請注意，如果您使用本地連線磁碟而不是網路連線磁碟，您需要自行解決如何使用LVM或第三方工具（如XtraBackup）備份您的資料。有關備份的更詳細討論，請參閱第10章。

最後需要注意的是，雲端供應商不提供像硬體RAID卡上常見的寫入快取（電池或快閃記憶體支援）。

MySQL在雲端運算中的儲存選擇與最佳實踐

在雲端環境中佈署MySQL時，選擇適當的儲存解決方案至關重要。固態硬碟硬碟（SSD）與傳統硬碟（HDD）的選擇不僅影響效能，也會對成本產生重大影響。

SSD vs HDD：為何選擇SSD

絕大多數情況下，建議使用SSD來儲存MySQL資料。SSD的讀寫速度遠超HDD，能夠顯著提升資料函式庫效能。尤其是在處理高IOPS（每秒輸入/輸出操作次數）需求的應用時，SSD是不可或缺的。若預算有限，可以考慮使用HDD作為啟動磁碟，但對於儲存MySQL資料的磁碟區，強烈建議使用SSD。在實際測試中，SSD啟動速度比HDD快2到3倍，這對於需要快速重啟的場景（如斷電或系統重啟）尤為重要。

IOPS與吞吐量的考量

在選擇磁碟時，瞭解IOPS和吞吐量需求是關鍵。對於現有的工作負載，應收集歷史資料使用情況以做出明智的選擇。若是新佈署的資料函式庫，則需評估應用的I/O密集程度。即使是簡單的讀寫比例分析也能提供有價值的參考。若無法準確評估，可選擇效能與成本之間的平衡點，並預留未來調整的空間。

在虛擬機器上執行MySQL的額外建議

若選擇在虛擬機器（VM）上自行管理MySQL，將涉及更多維運工作，如磁碟大小調整、備份等。以下是一些實用的建議：

處理主機重啟

虛擬機器的底層硬體故障可能導致VM意外終止。雖然無法完全避免這種情況，但可以採取一些措施來減輕影響：

  • 使用SSD作為啟動磁碟，以加快重啟速度，通常能在5分鐘內還原。
  • 暫時抑制因主機宕機觸發的警示，以避免不必要的幹擾。
  • 考慮在重啟時動態關閉read_only標誌，以允許寫入繼續。
  • 自動傳送通知至相關團隊，以減少溝通成本。

分離作業系統與MySQL資料

無論是使用本地連線還是網路連線的儲存，都建議將作業系統與MySQL資料分開存放。這樣做的好處包括：

  • 磁碟快照僅包含MySQL資料，不會攙雜作業系統資訊。
  • 在使用網路連線磁碟時，可以輕鬆地將磁碟掛載到其他機器上。
  • 便於在不影響資料的情況下升級或替換作業系統。

備份二進位日誌

將二進位日誌傳送到物件儲存桶，並設定生命週期規則自動清理過期的日誌檔案。同時，務必加強對儲存桶的安全控制，防止未授權存取。

自動擴充套件磁碟

對於網路連線的磁碟，可以設定自動擴充套件功能，以避免因磁碟空間不足而導致的中斷。透過API呼叫，可以在磁碟使用率達到預設閾值時自動擴充套件。然而，這也帶來了一些風險，如無限制擴充套件導致的高昂成本，或是在擴充套件過程中對效能的短暫影響。

資料函式庫合規性與 MySQL 的角色

在企業營運中，資料函式庫工程團隊扮演著至關重要的角色，不僅需確保資料函式庫的效能與正常運作時間，更需滿足多項法規遵循需求。隨著業務增長，各種法規要求將陸續浮現，部分法規適用於所有資料，而部分則僅限特定範圍。

合規性的定義

治理、風險管理和合規性（GRC）是一套指導企業如何評估和優先處理資產風險的原則、流程和法律規範。早期新創公司通常無需面對太多合規性需求，但隨著業務擴充套件，將逐漸遇到多項法規要求。

常見的合規性法規

  1. SOC 2（Service Organization Controls Type 2）
    SOC 2 是一套針對服務組織的合規性控制措施，涵蓋安全性、可用性、處理完整性、保密性和隱私保護等導向。資料函式庫工程師需建立完善的資料函式庫變更管理、備份與還原程式，以及存取控制機制。

  2. 沙賓-奧克斯利法案（SOX）
    該法案要求公開上市公司遵循相關規定，以保護投資者利益。對於工程團隊，SOX 法規要求證明只有授權人員能夠存取影響營收的資料，並且所有變更均有紀錄且合理。

  3. PCI DSS（Payment Card Industry Data Security Standard）
    PCI DSS 是針對處理信用卡資料的金融機構設定的標準，旨在保護持卡人資料不被洩露或用於詐欺交易。資料函式庫工程師需在架構設計中確保信用卡資料的獨立管理與存取控制。

  4. HIPAA（Health Insurance Portability and Accountability Act）
    HIPAA 規範了醫療資料的隱私保護，適用於處理電子個人健康資訊（ePHI）的醫療機構與相關業者。資料函式庫工程師需實施 ePHI 的存取控制、加密以及活動日誌記錄。

  5. FedRAMP（Federal Risk and Authorization Management Program）
    FedRAMP 是美國聯邦政府針對雲端服務提供商的認證計劃，要求業者符合一系列安全標準，包括組態管理、存取控制和稽核機制。

  6. GDPR（General Data Protection Regulation）
    GDPR 是歐盟於 2016 年推出的個人資料保護法規，要求資料處理者無論位於何處，均須遵循對歐盟公民個人資料的管理規範，例如取得同意、限制存取以及提供「被遺忘權」。

合規性設計考量

為了滿足上述法規要求，資料函式庫工程師需在系統設計初期即納入合規性考量，包括但不限於：

  • 存取控制：嚴格限制資料存取許可權，避免未授權存取。
  • 變更管理：建立完善的變更紀錄與審核機制。
  • 日誌記錄：完整記錄所有敏感資料的存取與變更行為。
  • 資料加密：對敏感資料進行加密處理，保護資料安全。
  • 角色分離：根據不同業務需求，實施角色分離機制，避免許可權過度集中。

資料主權的新挑戰

隨著全球化業務的發展，資料主權已成為新的關注焦點。企業需面對不同國家或地區的資料儲存與處理規範，在滿足當地法規的同時，也需確保資料的安全與合規性。