將 MySQL 內部部署移轉至適用於 MySQL 的 Azure 資料庫：評量

發行項
12/18/2024

評估將 MySQL 資料庫從內部部署環境移轉至適用於 MySQL 的 Azure 資料庫是確保順利且成功轉換的重要第一步。本文會徹底檢查評估階段中涉及的主要因素和考慮。您可以藉由評估您目前的基礎結構、找出潛在挑戰，以及瞭解 Azure 受控資料庫服務的優點，做出明智的決策，以符合組織的目標。無論您的目標是要增強效能、改善延展性或降低營運成本，本指南都為您提供有效規劃和執行移轉策略所需的深入解析。

必要條件

將 MySQL 內部部署移轉至適用於 MySQL 的 Azure 資料庫：代表性使用案例

概觀

在開始移轉 MySQL 工作負載之前，必須執行相當多的盡職調查。這包括分析資料、裝載環境和應用程式工作負載，以驗證 Azure 登陸區域已正確設定，並準備好裝載即將移轉的工作負載。

限制

適用於 MySQL 的 Azure 資料庫是 MySQL 社群版本的完全支援版本，作為平台即服務執行。不過，在進行初始評量時，有一些限制需要熟悉。

最重要的欄位包括：

儲存體引擎僅支援 InnoDB 和 Memory
有限Privilege支援 (DBA、SUPER、DEFINER)
已停用的資料操作陳述式 (SELECT ... INTO OUTFILE、LOAD DATA INFILE)
自動重大資料庫移轉 (5.6 到 5.7、5.7 到 8.0)
使用 MySQL Server 使用者定義函式 (UDF) 時，唯一可行的裝載選項是 Azure 託管 VM，因為 so 或 dll 元件無法上傳至適用於 MySQL 的 Azure 資料庫。

大多數其他項目都是系統管理員應該熟悉的作業層面，作為操作資料工作負載生命週期管理的一部分。本指南會在「移轉後管理」一節中探索其中許多操作層面。

MySQL 版本

MySQL 自 1995 年至今已有豐富的歷史。時至今日，MySQL 已演進為廣泛使用的資料庫管理系統。適用於 MySQL 的 Azure 資料庫從 MySQL 5.6 版開始支援，並持續到 5.7 版和最近的 8.0 版。如需適用於 MySQL 的 Azure 資料庫版本支援的最新資料，請參考支援的適用於 MySQL 的 Azure 資料庫伺服器版本。在 [移轉後管理] 區段中，我們會檢閱如何將升級 (例如 5.7.20 至 5.7.21) 套用至 Azure 中的 MySQL 執行個體。

注意

從 5.x 到 8.0 的版本跳躍，主要是因為 Oracle 收購了 MySQL。若要深入了解 MySQL 歷史，請瀏覽 MySQL Wiki 頁面。

請務必掌握來源 MySQL 版本。使用系統的應用程式可能會使用該版本特定的資料庫物件和功能。將資料庫移轉至較低的版本可能會導致相容性問題和功能遺失。此外，建議您在移轉至較新版本之前，徹底測試資料和應用程式執行個體，因為引進的功能可能會使您的應用程式損壞。

可能會影響移轉路徑和版本的範例：

5.6：用於正確儲存毫秒和全文檢索搜尋的 TIMESTAMP 資料行
5.7：支援原生 JSON 資料類型
8.0：支援 NoSQL 文件存放區、不可部分完成和損毀保護 (crash-safe) 的 DDL 和 JSON 資料表函式

注意

MySQL 5.6 在 2021 年 2 月停止一般支援。 MySQL 工作負載必須移轉至 5.7 版或更新版本的 MySQL。

若要檢查 MySQL 伺服器版本：

SHOW VARIABLES LIKE "%version%";

資料庫儲存引擎

適用於 MySQL 的 Azure 資料庫僅支援 InnoDB 和 Memory 資料庫儲存引擎。其他儲存引擎，例如 MyISAM，必須移轉至支援的儲存引擎。 MyISAM 與 InnoDB 的差異在於操作功能和效能輸出。較高層級的數據表和架構結構通常不會在引擎之間變更，但索引和數據表數據行類型可能會因為記憶體和效能原因而變更。雖然已知 InnoDB 具有較大的資料檔案大小，但這些儲存體詳細資料是由適用於 MySQL 的 Azure 資料庫服務管理。

從 MyISAM 遷移至 InnoDB

MyISAM 資料庫和數據表必須轉換成 InnoDB 資料表。轉換之後，應用程式需要經過相容性和效能的測試。在大部分情況下，測試需要重新建立資料表，並透過 DDL 陳述式變更目標儲存引擎。這項變更不太可能在移轉期間執行，而是會發生在 Azure 目標的結構描述建立期間。如需詳細資訊，請檢閱 MySQL 網站上的轉換資料表開發人員文件。

若要尋找有用的資料表資訊，請使用此查詢：

    SELECT
        tab.table_schema,
        tab.table_name,
        tab.engine as engine_type,
        tab.auto_increment,
        tab.table_rows,
        tab.create_time,
        tab.update_time,
        tco.constraint_type
    FROM information_schema.tables tab
    LEFT JOIN information_schema.table_constraints tco
        ON (tab.table_schema = tco.table_schema
            AND tab.table_name = tco.table_name
            )
    WHERE
        tab.table_schema NOT IN ('mysql', 'information_schema', 'performance_
schema', 'sys')
        AND tab.table_type = 'BASE TABLE';

注意

針對多個資料庫的INFORMATION_SCHEMA執行查詢可能會影響效能。請在低使用量期間執行。

若要將資料表從 MyISAM 轉換至 InnoDB，請執行下列命令：

ALTER TABLE {table\_name} ENGINE=InnoDB;

注意

此轉換方法會導致資料表鎖定，而且所有應用程式都需等待作業完成。資料表鎖定會讓資料庫在一小段時間內離線。

或者，您也可以建立相同結構但使用不同儲存引擎的資料表。建立之後，將資料列複製到新的資料表：

INSERT INTO {table\_name} SELECT * FROM {myisam\_table} ORDER BY {primary\_key\_columns}

注意

若要讓這個方法成功，您必須刪除原始資料表，然後重新命名新的資料表。此工作會造成短暫的停機時間。

資料庫資料和物件

資料是資料庫移轉的一個元件。資料庫支援的物件必須移轉並驗證，以確保應用程式能夠穩定地執行。

以下是您應該在移轉前後清查的項目清單：

資料表 (結構描述)
主索引鍵、外部索引鍵
索引數
函式
程序
觸發程序
檢視

使用者定義函式

MySQL 接受使用呼叫外部程式碼的函式。不幸的是，使用使用者定義函式（UDF）搭配外部程式代碼的數據工作負載無法遷移至適用於 MySQL 的 Azure 資料庫。這是因為必要的 MySQL 函式支援，因此或 dll 程式代碼無法上傳至 Azure 伺服器。

執行下列查詢來尋找可能安裝的任何 UDF：

SELECT * FROM mysql.func;

來源系統

移轉準備的工作量可能會根據來源系統及其位置而有所不同。除了資料庫物件，也請考慮如何將資料從來源系統擷取至目標系統。當來源和目標之間存在防火牆和其他網路元件時，移轉資料可能會變得困難。

此外，透過網際網路移動資料的速度，可能會比使用專用循環移動至 Azure 慢。因此，移動龐大 GB、TB 和 PB 的資料時，請考慮在來源網路與 Azure 網路之間設置 ExpressRoute 連線。

如果 ExpressRoute 已經存在，則可能是其他應用程式正在使用該連線。透過現有路由執行移轉可能會對網路輸送量造成壓力，而且可能會對移轉以及其他使用網路的應用程式造成顯著的效能影響。

最後，您必須評估磁碟空間。匯出大型資料庫時，請考慮資料的大小。確定工具執行所在的系統，以及最終匯出位置有足夠的磁碟空間來執行匯出作業。

雲端提供者

從 Amazon Web Services （AWS）等雲端服務提供者移轉資料庫可能需要額外的網路設定步驟，才能存取雲端裝載的 MySQL 實例。數據遷移服務等移轉工具需要從IP範圍外部存取，否則可能會遭到封鎖。

內部部署

如同雲端提供者，如果 MySQL 資料工作負載位於防火牆或其他網路安全性層級後方，則必須在內部部署執行個體與適用於 MySQL 的 Azure 資料庫之間建立路徑。

工具

許多工具和方法都可用來評估 MySQL 資料工作負載和環境。每個工具都會提供一組不同的評量和移轉特性和功能。在本指南中，我們會瀏覽最常用來評估 MySQL 資料工作負載的工具。

Azure 移轉

雖然 Azure Migrate 不支援直接移轉 MySQL 資料庫工作負載，但如果系統管理員不確定哪些使用者和應用程式正在取用資料，無論是裝載於虛擬電腦還是硬體式機器上，都可以使用此工具。相依性分析可以透過在裝載 MySQL 工作負載的電腦上安裝和執行監視代理程式完成。代理程式會收集一段期間內的資訊，例如一個月。您可以分析相依性資料，找出與資料庫的未知連線。連線資料可協助識別需要傳送擱置移轉通知的應用程式擁有者。

除了應用程式和使用者連線資料的相依性分析之外，Azure Migrate 也可以用來分析 Hyper-V、VMWare 或實體伺服器，以提供資料庫工作負載的使用量模式，以協助建議適當的目標環境。

適用於 Linux 的 Telgraf

Linux 工作負載可以利用 Microsoft Monitoring Agent (MMA) 來收集虛擬和實體機器上的資料。此外，請考慮使用 Telegraf 代理程式及其廣泛的外掛程式來收集效能計量。

服務層

掌握評估資訊 (CPU、記憶體、儲存體等)，移轉使用者的下一個選擇是決定要使用適用於 MySQL 的 Azure 資料庫的哪個定價層。

目前有三個服務層級：

基本：需要輕量運計算和 I/O 效能的工作負載。
一般用途：適用大多數的企業工作負載，需要透過可擴縮的 I/O 輸送量，平衡計算與記憶體。
記憶體最佳化：適用於需要記憶體內效能，以便能更快處理交易及更快並行處理的高效能資料庫工作負載。

服務層級決策可能會受到資料工作負載的 RTO 和 RPO 需求影響。當資料工作負載需要超過 4 TB 的儲存體時，將需要額外的步驟。檢閱並選取最多支援 16 TB 的儲存體區域。

一般而言，決策制定會優先考慮儲存體和 IOPS，或每秒輸入/輸出作業的需求。因此，目標系統需要一律具備與來源系統中相等容量的儲存體。此外，由於 IOPS 配置為 3/GB，因此請務必讓 IOPS 符合最終儲存體大小。

因素	層
基本	開發電腦不需要具有小於 1 TB 記憶體的高效能。
一般用途	IOPS 的需求超過基本層提供的配置，但儲存體需求低於 16 TB，且記憶體需求低於 4 GB。
記憶體最佳化	資料工作負載需要高記憶體或高快取以及緩衝區相關伺服器設定，例如高並行 innodb_buffer_pool_instances、大型 BLOB 大小、具有許多複寫複本的系統。

成本

在評估整個 WWI MySQL 資料工作負載之後，WWI 判斷這些作業至少需要 4 個虛擬核心和 20 GB 的記憶體，以及至少 100 GB 的儲存空間，且 IOP 容量為 450 IOPS。由於 450 IOPS 需求，因此必須配置至少 150 GB 的儲存體，因為適用於 MySQL 的 Azure 資料庫 IOP 配置方法。此外，他們至少需要 100% 的已佈建伺服器儲存體作為備份儲存體和一個讀取複本。工作負載的預期輸出不會超過 5 GB。

使用適用於 MySQL 的 Azure 資料庫定價計算機，WWI 就能夠判斷適用於 MySQL 的 Azure 資料庫執行個體的成本。自 2020 年 9 月起，WWI 會議資料庫會顯示擁有權總成本 (TCO) 的下列表格。

資源	描述	數量	成本
計算 (一般用途)	4 個 vCores，20 GB	1 @ $0.351 美金/小時	$3074.76 美金/年
Storage	5 GB	12 x 150 @ $0.115 美金	$207 美金/年
Backup	最多 100% 的已佈建儲存體	最多 100% 的已佈建的伺服器儲存體不需要額外費用	$0.00 美金/年
讀取複本	1 秒區域複本	計算 + 儲存體	$3281.76/年
Network	< 5GB/月輸出	免費
總數			$6563.52/年

在檢閱初始成本之後，WWI 的 CIO 確認他們在 Azure 上已超過三年的時間。他們決定使用 3 年保留執行個體來節省額外的 ~$4000 美金/年。

資源	描述	數量	成本
計算 (一般用途)	4 個 V 核心	1 @ $0.1375 美金/小時	$1204.5 美金/年
Storage	5 GB	12 x 150 @ $0.115 美金	$207 美金/年
Backup	最多 100% 的已佈建儲存體	最多 100% 的已佈建的伺服器儲存體不需要額外費用	$0.00 美金/年
Network	< 5GB/月輸出	免費
讀取複本	1 秒區域複本	計算 + 儲存體	$1411.5 美金/年
總數			$2,823 / yr

如上表所示，備份、網路輸出和任何讀取複本都必須列入擁有權總成本 (TCO) 考量中。隨著新增更多資料庫，隨之產生的儲存體和網路流量是唯一要考慮的額外成本因素。

注意

上述估計值不包含應用層的任何 ExpressRoute、Azure 應用成事閘道、Azure Load Balancer 或 App Service 成本。

上述定價可能會隨時變更，且會依區域而有所不同。

應用程式影響

移至適用於 MySQL 的 Azure 資料庫時，轉換成安全通訊端層 (SSL) 型通訊可能是應用程式最重要的變更之一。 SSL 預設會在適用於 MySQL 的 Azure 資料庫中啟用，而且內部部署應用程式和數據工作負載可能未設定為使用 SSL 連線到 MySQL。啟用時，SSL 使用量會增加一些額外的處理額外負荷，而且應該受到監視。

注意

雖然預設會啟用 SSL，但您可以選擇將其停用。

請遵循在您的應用程式中設定 SSL 連線能力，以安全地連線至適用於 MySQL 的 Azure 資料庫中的活動，以重新設定應用程式以支援此增強式驗證路徑。

最後，修改應用程式連接字串中的伺服器名稱，或切換 DNS 以指向新的適用於 MySQL 的 Azure 資料庫伺服器。

WWI 案例

WWI 會藉由收集其 MySQL 資料資產的相關資訊來開始評估，如下表所示。

名稱	來源	資料庫引擎	大小	IOPS	版本	負責人	停機
WwwDB	AWS (PaaS)	InnoDB	1 GB	150	5.7	行銷部門	1 小時
BlogDB	AWS (PaaS)	InnoDB	1 GB	100	5.7	行銷部門	4 小時
ConferenceDB	內部部署	InnoDB	5 GB	50	5.5	銷售部門	4 小時
CustomerDB	內部部署	InnoDB	10 GB	75	5.5	銷售部門	2 小時
SalesDB	內部部署	InnoDB	20 GB	75	5.5	銷售部門	1 小時

連絡每個資料庫擁有者以決定可接受的停機時間。選取的規劃和移轉方法是取決於可接受的資料庫停機時間。

在第一個階段中，WWI 僅著重於 ConferenceDB 資料庫。小組需要移轉體驗，以協助繼續進行資料工作負載移轉。之所以選擇 ConferenceDB 資料庫是因為其具有簡單資料庫結構，而且可接受很長的停機時間。移轉資料庫之後，小組著重於將應用程式移轉至安全的 Azure 登陸區域。

評估檢查清單

測試工作負載可在目標系統上成功執行。
確認正確的網路元件已準備好進行移轉。
了解資料工作負載資源需求。
評估總成本。
了解停機時間需求。
準備好進行應用程式變更。

後續步驟

將 MySQL 內部部署移轉至適用於 MySQL 的 Azure 資料庫：規劃

共用方式為