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

發行項
12/18/2024

開發完整的測試計劃對於將 MySQL 資料庫從內部部署環境遷移至適用於 MySQL 的 Azure 資料庫非常重要。本文深入探討有效測試計劃的基本元件，確保移轉程式順利且成功。您可以概述關鍵測試策略、找出潛在問題、建立明確的驗證準則，並確保移轉的資料庫在 Azure 環境中以最佳方式執行，以降低風險。無論專注於功能測試、效能測試或安全性測試，本指南都為您提供建立支援無縫移轉的強大測試計劃所需的知識和最佳做法。

必要條件

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

概觀

WWI 已建立一項測試計劃，其中包含一組 IT 和商務工作。若要成功移轉，便須執行所有測試。

測試:

確定移轉的資料庫與內部部署資料表一致 (記錄計數和查詢結果相同)。
確定效能合理 (應與內部部署的執行效能相同)。
確定目標查詢的效能符合所述需求。
確定內部部署與 Azure 網路間的網路連線能力合理。
確定已識別的所有應用程式及使用者皆可連線至移轉的資料執行個體。

WWI 已識別一項週末移轉作業，期間從美國太平洋時間下午 10 點開始，上午 2 點結束。若在目標時間上午 2 點前未完成移轉 (目標 4 小時停機) 並通過所有測試，則會啟動復原程序。系統會記錄問題，以供未來嘗試移轉時參考。所有移轉期間皆已提前，並根據可接受的業務時間表重新排程。

範例查詢

已在來源及目標上執行一系列查詢，以確認資料庫移轉成功。下列查詢和指令碼有助於判斷移轉動作是否已將來源的所有必要資料庫物件移至目標。

資料表資料列

您可使用此查詢，以取得所有資料表和預估的資料列計數：

SELECT SUM(TABLE_ROWS)
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '{SchemaName}';

注意

INFORMATION_SCHEMA 資料表會提供一組跨資料表的預估值。若要讓計量檢視 (如資料表大小) 更精確，請使用 innodb_stats_transient_sample_pages 伺服器參數增加頁面樣本大小。增加此伺服器值可強制分析更多頁面，提供更精確的結果。

針對各資料表執行 count(*) SQL 陳述式，以取得精確的資料列計數。在大型資料表上執行此命令時，可能需要很多時間。下列指令碼會產生一組 SQL 陳述式，可供執行以取得確切計數：

SELECT CONCAT(
    'SELECT "',
    table_name,
    '" AS table_name, COUNT(*) AS exact_row_count FROM `',
    table_schema,
    '`.`',
    table_name,
    '` UNION '
)
FROM INFORMATION_SCHEMA.TABLES
WHERE table_schema = '**my_schema**';

資料表片段

隨應用程式持續使用，資料表可能也會持續增長。在某些情況下，數據可能不會成長，但會透過刪除和更新不斷變更。若是如此，資料庫檔案內可能會有許多片段。 MySQL OPTIMIZE TABLE 陳述式可減少實體儲存空間需求，同時改善 I/O 效率。

您可執行下列命令來最佳化 MySQL 資料表：

optimize table TABLE_NAME

資料庫物件

使用下列查詢，以確保納入所有其他資料庫物件。雖然這些查詢可以計算數據表數據列計數，但可能不會考慮特定資料庫物件的版本。例如，即使預存程式可能存在，也可能在移轉的開始和結束之間變更。建議在移轉期間凍結資料庫物件開發。

使用者

SELECT DISTINCT
        USER
FROM
        mysql.user
WHERE
        user <> '' order by user

索引數

SELECT DISTINCT
        INDEX_NAME
FROM
        information_schema.STATISTICS
WHERE
        TABLE_SCHEMA = '{SchemaName}'

條件約束

SELECT DISTINCT
        CONSTRAINT_NAME
FROM
        information_schema.TABLE_CONSTRAINTS
WHERE
        CONSTRAINT_SCHEMA = '{SchemaName}'

檢視

SELECT
        TABLE_NAME
FROM
        information_schema.VIEWS
WHERE
        TABLE_SCHEMA = '{SchemaName}'

預存程序 (部分機器翻譯)

SELECT
        ROUTINE_NAME
FROM
        information_schema.ROUTINES
WHERE
        ROUTINE_TYPE = 'FUNCTION' and
        ROUTINE_SCHEMA = '{SchemaName}'

函數

SELECT
        ROUTINE_NAME
FROM
        information_schema.ROUTINES
WHERE
        ROUTINE_TYPE = 'PROCEDURE' and
        ROUTINE_SCHEMA = '{SchemaName}'

事件

SELECT
        EVENT_NAME
FROM
        INFORMATION_SCHEMA.EVENTS
WHERE
        EVENT_SCHEMA = '{SchemaName}'

復原策略

上述查詢提供復原決策可使用的物件名稱和計數清單。移轉使用者的第一個物件驗證步驟，即是檢查來源和目標物件計數。物件計數的差異不一定表示需要復原。若進行深入評估，可能會指出差異不大且易於復原。手動移轉幾個失敗的物件可作為解決方案。例如：若所有資料表和資料列皆已移轉，而僅遺漏幾個函數，請補救這些失敗物件並完成移轉。若資料庫相對較小，則可清除適用於 MySQL 的 Azure 資料庫執行個體，並重新開始移轉。大型資料庫可能需要比移轉視窗中可用的時間還多，以判斷遺漏的物件。移轉必須停止並復原。

若要在移轉期間找出遺漏的資料庫物件，則須快速進行。分秒必爭。其中一個作法是將環境物件名稱匯出至檔案，並使用資料比較工具快速找出遺漏的物件。另一個作法則是匯出來源資料庫物件名稱，並將資料匯入目標資料庫環境的暫存資料表。使用已編寫指令碼及測試的 SQL 陳述式來比較資料。資料驗證的速度和正確性對移轉程序至關重要。在移轉期間，請勿仰賴手動方式讀取及驗證一長串資料庫物件清單。人為錯誤的可能性過高。最好是使用工具進行例外狀況管理。

WWI 案例

WWI CIO 收到確認報告，表示所有資料庫物件皆已從內部部署資料庫移轉至適用於 MySQL 的 Azure 資料庫執行個體。移轉開始前，資料庫小組已對資料庫執行上述查詢，並將所有結果儲存至試算表。

來源資料庫結構描述資訊已用於驗證目標移轉物件精確度。

測試計劃檢查清單

測試查詢已編寫指令碼、完成測試，並準備好執行。
了解執行測試查詢所需的時間，並納入記錄的移轉時間表。
具備風險降低和復原策略，以便用於不同的潛在。
具備定義明確的移轉事件時間表。

後續步驟

將 MySQL 內部部署移轉至適用於 MySQL 的 Azure 資料庫：效能基準

共用方式為