Share via

適用於 MySQL 的 Azure 資料庫 - 彈性伺服器的最佳效能最佳做法

  • 發行項

適用於：適用於 MySQL 的 Azure 資料庫 - 單一伺服器適用於 MySQL 的 Azure 資料庫 - 彈性伺服器

重要

適用於 MySQL 的 Azure 資料庫單一伺服器位於淘汰路徑上。 強烈建議您升級至適用於 MySQL 的 Azure 資料庫彈性伺服器。 如需移轉至適用於 MySQL 的 Azure 資料庫彈性伺服器的詳細資訊，請參閱適用於 MySQL 的 Azure 資料庫單一伺服器會發生什麼事？

了解如何在使用適用於 MySQL 的 Azure 資料庫彈性伺服器時取得最佳效能。 當我們將新功能新增至平台時，我們將會繼續精簡本節中的建議。

實體鄰近性

請確定您在相同的區域中部署應用程式和資料庫。 啟動任何效能效能評定執行之前有一快速檢查方式，是使用簡單的 SELECT 1 查詢來判斷用戶端與資料庫之間的網路延遲。

當 Web 應用程式和其相關聯的資料庫等資源在不同的區域中執行時，這些資源之間的通訊可能會增加延遲。 讓應用程式和資料庫位於不同區域中會有另一個可能的影響，與輸出資料傳輸成本有關。

若要在成本最佳化部署中改善應用程式的效能和可靠性，強烈建議讓 Web 應用程式服務和適用於 MySQL 的 Azure 資料庫彈性伺服器資源位於相同的區域和可用性區域。 此共置最適合對延遲敏感的應用程式，而且也會提供最佳的輸送量，因為資源會緊密配對。

加速網路

如果您使用 Azure 虛擬機器、Azure Kubernetes 或應用程式服務，請使用應用程式伺服器的加速網路。 加速網路可以對 VM 啟用單一根目錄 I/O 虛擬化 (SR-IOV)，大幅提升其網路效能。 這個高效能路徑會略過資料路徑的主機，進而減少延遲、抖動和 CPU 使用率，供支援的 VM 類型中最嚴苛的網路工作負載使用。

連線效率

建立新的連線向來是昂貴且耗時的工作。 當應用程式要求資料庫連線時，會優先配置現有的閒置資料庫連線，而不是建立新的連線。 以下是適用於良好連線做法的一些選項：

  • ProxySQL：使用 ProxySQL，可提供內建連線共用，並視需要將工作負載負載平衡至多個讀取複本，並包含應用程式程式碼中的任何變更。

  • Heimdall Data Proxy：或者，您也可以使用 Heimdall Data Proxy，這是廠商中性的專屬 Proxy 解決方案。 該方案支援具有複寫延遲偵測的查詢快取和讀取/寫入分割。 您也可以參考如何使用 Heimdall Proxy 加速 MySQL 效能。

  • 持續性或長時間存留連線：如果您的應用程式通常具有短交易或查詢，且執行時間 < 為 5-10 毫秒，則以持續性連線取代簡短連線。 將簡短連線取代為持續性連線只需要對程式碼進行次要變更，但在許多一般應用程式案例中改善效能方面會有重大影響。 請務必在交易完成時設定逾時或關閉連線。

  • 複本：如果您使用複本，請使用 ProxySQL 來平衡主要伺服器與可讀取次要複本伺服器之間的負載。 了解如何設定對等互連。

連線共用

連線共用是一種機制，可管理資料庫連線的建立和配置，並保護資料庫免於連線激增。 如果您的應用程式在相對短時間內開啟許多連線，且連線存留時間較短，請考慮連線共用。 例如，這些連線類型的發生次數可能會超過每秒數百或數千，而且相較於連線存留期總計，建立和關閉連線所需的時間相當重要。

如果您的應用程式開發架構不支援連線共用，請改用應用程式與資料庫伺服器之間的連線 Proxy，例如 ProxySQL 或 Heimdall Proxy。

處理連線調整

調整 Web 應用程式以符合變動需求的常見方法，是新增和移除應用程式伺服器。 每個應用程式伺服器都可以搭配資料庫使用連接集區。 此方法會導致資料庫伺服器上的連線總數隨著應用程式伺服器數目而增長。 例如，如果資料庫伺服器有 10 部應用程式伺服器，且每個伺服器都設定為 100 個資料庫連線，則會提供 1000 個資料庫連線。 如果應用程式工作負載因使用者活動較高或尖峰時間而調整，且新增額外的 50 部應用程式伺服器，則資料庫連線總計為 6000。 一般而言，在應用程式伺服器建立連線之後，這些連線大部分都會閒置。 由於閒置連線會耗用保持開啟的資源 (記憶體和 CPU)，因此資料庫延展性可能會受到影響。

其他潛在挑戰涉及處理資料庫伺服器的連線總數。 這是由連線到資料庫伺服器的應用程式伺服器數目所決定，每個伺服器都會建立自己的一組連線。 在這些案例中，請考慮調整應用程式伺服器上的連線集區。 嘗試將每個集區中的連線數目減少為可接受的最低數目，以確保資料庫伺服器端的連線數不會膨脹。 請將此視為短期補救措施，用於對抗應用程式伺服器調整的影響，而不是解決應用程式成長的永久解決方案。

作為長期解決方案，請在資料庫伺服器與應用程式伺服器之間引進 Proxy，例如 ProxySQL 或 Heimdall Proxy。 這會有所幫助，因為 Proxy 能夠：

  • 建立具有固定連線數目的資料庫伺服器連線。
  • 接受應用程式連線，並作為潛在連線風暴的緩衝區。

Proxy 可以提供其他功能，例如查詢快取、連線緩衝、查詢重寫/路由和負載平衡。 為了提升延展性，請考慮使用多個 Proxy 執行個體。

適合容錯和更快速復原的連線處理

在設計應用程式和環境以進行容錯和更快速的復原時，請考慮在資料庫環境中，您可能會遇到連線中斷或硬體失敗。 也請記住操作動作的需求，例如調整執行個體大小、修補和執行手動容錯移轉。

例如，假設您的資料庫伺服器在一分鐘內完成容錯移轉，但您的應用程式因為 DNS TTL 在應用程式端過長而關閉數分鐘。 在這些情況下，只要減少 TTL 值就能提供更快速的復原，或整合應用程式與資料庫伺服器之間的連線 Proxy 以便處理這類失敗。

資料分割

當您的生產工作負載使用非常大型的資料表時，資料分割是改善資料庫效能並簡化維護的絕佳方法。 資料分割可讓您更輕鬆地管理大型資料表，此方法可讓您新增和卸載分割區，以有效管理大型資料表。 資料分割也可以協助調整引擎，方法是降低每個資料表或每個索引的內部鎖定等內部結構競爭 (例如，考慮 InnoDB 中的 btr_search_latch in InnoDB)。

例如，藉由新增五個分割區，您基本上會將具有大量活動的資料表分成五個更有效率的較小資料表。 這主要有助於主要作業是資料表上主鍵查閱的情況，因此查詢可以利用「資料分割剪除」。 但是，資料分割也可以協助進行表格掃描。

請注意，雖然資料分割有其優點，但也有一些限制，例如不支援資料分割資料表中的外部索引鍵、缺少查詢快取等。如需這些限制的完整清單，請參閱 MySQL 參考手冊中的資料分割限制事項一章。

隔離讀取和寫入

大部分的應用程式主要都是從資料庫讀取，只有一小部分互動涉及寫入。 針對連接集區計算的主資料庫作用中連線數目，可能包含讀取流量。 盡可能卸載多個查詢來讀取複本，並節省對主要可寫入執行個體的存取權，這樣可增加應用程式伺服器執行的整體資料庫活動量，而不會增加主資料庫上的負載。 如果您尚未存取讀取複本以至少執行較長的查詢 (例如報表)，您應該考慮立即將報告或分析移至讀取複本。

較大規模的使用讀取複本可能需要更仔細考慮，因為複本會因複寫的非同步本質而稍微落後於主要複本。 盡可能尋找多個應用程式的區域，這些區域只需次要的程式碼變更，就能從複本讀取提供服務。 您也應該在有關快取的較高層級套用此方法 - 提供更多唯讀或緩慢變更來自專用快取層的內容，例如 Azure Cache for Redis。

寫入調整和分區化

隨著時間經過，應用程式會演進，以及新增功能。 為了方便或一般做法，資料表會新增至主資料庫。 若要處理資料庫上不斷成長的流量負載，請識別可輕鬆移至個別資料庫的應用程式區域，並考慮水平分區化或垂直分割資料庫。

水平分區化資料庫的運作方式，是在不同的資料庫中建立應用程式架構的多個複本，並根據客戶識別碼、地理位置或某些其他個別客戶或租用戶屬性來隔離客戶和所有相關聯的資料。 這適用於 SaaS 或 B2C 應用程式，其中個別客戶很小，且應用程式的負載來自數百萬個客戶的匯總使用量。 不過，B2B 應用程式客戶的大小不同，而個別大型客戶可能會影響特定分區的流量負載。

以功能分區化資料庫來垂直分割負載 - 將個別的應用程式網域 (或微服務) 移至自己的資料庫。 這會從主資料庫散發負載，以分隔個別服務資料庫。 簡單範例包括記錄資料表或月台組態資訊，這些資訊不需要與大量載入的訂單資料表位於相同資料庫中。 更複雜的範例包括將客戶和帳戶網域從訂單或履行網域中斷。 在某些情況下，可能需要變更應用程式，例如修改電子郵件或背景工作佇列，使其以獨立方式進行，而不需要依賴聯結回到客戶或訂單資料表。 將現有的資料表和資料移至新的主資料庫，可以透過適用於 MySQL 的 Azure 資料庫彈性伺服器讀取複本，將應用程式的複本和指標部分升級至新建立可寫入資料庫來執行。 新建立的資料庫必須限制連線集區的存取、微調查詢，以及使用自己的複本散佈負載，就像原始的主要複本一樣。

資料匯入組態

  • 您可以在啟動資料匯入作業之前，暫時將執行個體調整為較高的 SKU 大小，然後在匯入成功時將其相應減少。
  • 您可以使用 AZURE 資料移轉服務 (DMS) 進行線上或離線移轉，以最短停機時間匯入您的資料。

適用於 MySQL 的 Azure 資料庫彈性伺服器記憶體建議

適用於 MySQL 的 Azure 資料庫彈性伺服器效能最佳做法，是配置足夠的 RAM，讓您的工作集幾乎完全位於記憶體中。

使用 InnoDB 緩衝集區準備

適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體重新啟動之後，系統會載入位於儲存體中的資料頁，由於需查詢資料表，這會導致第一次執行查詢時增加延遲和效能變慢。 對於延遲敏感性工作負載而言，這可能無法接受。

使用 InnoDB 緩衝集區暖化，可藉由重載在重新啟動前緩衝集區中的磁碟頁面來存取對應的資料列，藉此得以縮短準備期間，而無須等待 DML 或 SELECT 作業。

您可以藉由設定 InnoDB 緩衝集區伺服器參數，來減少重新啟動適用於 MySQL 的 Azure 資料庫彈性伺服器執行個體之後的準備期間。 InnoDB 會在伺服器關機時儲存每個緩衝集區最近使用的頁面百分比，並在伺服器啟動時還原這些頁面。

也請務必注意，改善的效能需要花費伺服器較長的啟動時間。 啟用此參數時，伺服器啟動和重新啟動時間應該會根據伺服器上佈建的 IOPS 而增加。

建議您測試並監視重新啟動時間，以確保啟動/重新啟動效能可以接受，因為伺服器在該時間無法使用。 不建議在佈建的 IOPS 少於 1000 (或換句話說，佈建的儲存體小於 335 GB) 時使用此參數。

若要在伺服器關機時儲存緩衝集區的狀態，請將伺服器參數 innodb_buffer_pool_dump_at_shutdown 設定為 ON。 同樣地，請將伺服器參數 innodb_buffer_pool_load_at_startup 設定為 ON，以在伺服器啟動時還原緩衝集區狀態。 您可以降低和微調伺服器參數 innodb_buffer_pool_dump_pct 的值，來控制對啟動/重新啟動時間的影響。 根據預設，此參數設定為 25。

注意

InnoDB 緩衝集區準備參數僅在最多 16 TB 儲存體的一般用途儲存體伺服器中受支援。 如需詳細資訊，請參閱適用於 MySQL 的 Azure 資料庫彈性伺服器儲存體選項。

下一步