Google Cloud 提供工具、產品、指南和專業服務，協助您從 Amazon 關聯式資料庫服務 (RDS) 或 Amazon Aurora 遷移至 MySQL 適用的 Cloud SQL。
本文適用於想要規劃、實作及驗證資料庫遷移專案的雲端和資料庫管理員。此外，也適合正在評估遷移機會，並想瞭解遷移範例的決策者。
本文著重於同質資料庫遷移，也就是來源和目的地資料庫使用相同資料庫技術的遷移作業。在本遷移指南中，來源是 Amazon RDS 或 Amazon Aurora for MySQL，目的地則是 MySQL 適用的 Cloud SQL。
本文件是從 AWS 遷移至Google Cloud 系列文章的一部分，該系列包含下列文件：
- 開始使用
- 從 Amazon EC2 遷移至 Compute Engine
- 從 Amazon S3 遷移至 Cloud Storage
- 從 Amazon EKS 遷移至 GKE
- 從 Amazon RDS 和 Amazon Aurora for MySQL 遷移至 MySQL 適用的 Cloud SQL (本文件)
- 從 Amazon RDS 和 Amazon Aurora for PostgreSQL 遷移至 PostgreSQL 適用的 Cloud SQL 和 AlloyDB for PostgreSQL
- 從 Amazon RDS for SQL Server 遷移至 SQL Server 適用的 Cloud SQL
- 從 AWS Lambda 遷移至 Cloud Run
如要遷移至 Google Cloud，建議您按照「遷移至 Google Cloud：開始使用」一文所述的遷移架構操作。
以下是遷移流程圖。
您可能會透過一系列疊代，從來源環境遷移至 Google Cloud ，例如先遷移部分工作負載，再遷移其他工作負載。針對每個獨立的遷移疊代，您必須遵循一般遷移架構的階段：
- 評估並探索工作負載和資料。
- 在 Google Cloud上規劃及建構基礎。
- 將工作負載和資料遷移至 Google Cloud。
- 將 Google Cloud 環境調整至最佳狀態。
如要進一步瞭解這個架構的各個階段，請參閱「遷移至 Google Cloud：開始使用」。
為設計有效的遷移計畫，建議您驗證計畫的每個步驟，並確保有復原策略。如要驗證遷移計畫，請參閱「遷移至 Google Cloud：驗證遷移計畫的最佳做法」。
評估來源環境
在評估階段，您需要判斷將來源環境遷移至 Google Cloud的需求和依附元件。
評估階段是您能否成功遷移的關鍵。您必須深入瞭解要遷移的工作負載、其需求、依附元件，以及目前的環境。您必須瞭解起點，才能成功規劃及執行 Google Cloud遷移作業。
評估階段包含下列工作：
- 建立工作負載的完整清單。
- 根據工作負載的屬性和依附元件，將工作負載分類。
- 訓練團隊並傳授 Google Cloud相關知識。
- 在 Google Cloud建立實驗和概念驗證。
- 計算目標環境的總持有成本 (TCO)。
- 選擇工作負載的遷移策略。
- 選擇遷移工具。
- 定義遷移計畫和時程。
- 驗證遷移計畫。
資料庫評估階段可協助您選擇目標 Cloud SQL 資料庫執行個體的大小和規格，以符合來源的類似效能需求。請特別留意磁碟大小和處理量、IOPS 和 vCPU 數量。如果目標資料庫執行個體大小不正確，遷移作業可能會遇到困難或失敗。如果大小不正確，可能會導致遷移時間過長、資料庫效能問題、資料庫錯誤和應用程式效能問題。決定 Cloud SQL 執行個體時，請注意磁碟效能取決於磁碟大小和 vCPU 數量。
下列各節會依據「遷移至 Google Cloud：評估及探索工作負載」一文，整合該文件中的資訊。
建立 Amazon RDS 或 Amazon Aurora 執行個體的清單
如要定義遷移範圍，請建立清單並收集 Amazon RDS 或 Amazon Aurora 執行個體的相關資訊。建議您使用專門工具自動執行這項程序，因為手動方法容易出錯，且可能導致錯誤假設。
Amazon RDS 或 Amazon Aurora 與 Cloud SQL 的功能、執行個體規格或作業可能不盡相同。部分功能的實作方式可能不同，或無法使用。差異可能包括基礎架構、儲存空間、驗證和安全性、複製、備份、高可用性、資源容量模型，以及特定資料庫引擎功能整合和擴充功能。視資料庫引擎類型、執行個體大小和架構而定，資料庫參數設定的預設值也可能有所不同。
基準測試可協助您進一步瞭解要遷移的工作負載，並有助於定義遷移目標環境的正確架構。收集效能相關資訊，有助於預估 Google Cloud 目標環境的效能需求。遷移程序的「執行測試和驗證」階段會詳細說明基準測試概念和工具，但這些概念和工具也適用於建立資產清單階段。
評量工具
如要初步評估現有基礎架構，建議您使用 Google Cloud Migration Center，以及 migVisor 和資料庫遷移評估工具 (DMA) 等其他專門的資料庫評估工具。
您可以使用 Migration Center，全面評估應用程式和資料庫環境，包括資料庫遷移至 Google Cloud的技術適用性。您會收到各來源資料庫的大小和設定建議，並建立伺服器和資料庫的總持有成本 (TCO) 報表。
如要進一步瞭解如何使用 Migration Center 評估 AWS 環境，請參閱「從其他雲端服務供應商匯入資料」。
除了 Migration Center，您也可以使用專門工具 migVisor。migVisor 支援多種資料庫引擎，特別適合異質遷移。如需 migVisor 簡介，請參閱「migVisor 總覽」。
migVisor 可找出可能導致遷移失敗的構件和不相容的專屬資料庫功能，並提供解決方法。migVisor 也能建議目標 Google Cloud 解決方案，包括初始大小和架構。
migVisor 資料庫評估輸出內容提供下列資訊：
- 全面探索及分析目前的資料庫部署作業。
- 根據資料庫使用的專屬功能，提供遷移複雜度的詳細報表。
- 財務報告，詳細說明遷移後的成本節省、遷移成本和新的營運預算。
- 分階段遷移計畫，以最不影響業務的方式遷移資料庫和相關聯的應用程式。
如要查看評估輸出內容範例，請參閱「migVisor - 雲端遷移評估工具」。
請注意，migVisor 會暫時提高資料庫伺服器使用率。 一般來說，這項額外負載低於 3%，且可在非尖峰時段執行。
migVisor 評估輸出內容可協助您建立完整的 RDS 執行個體清單。報告內容包含一般屬性 (資料庫引擎版本、CPU 和記憶體大小)，以及資料庫拓撲、備份政策、參數設定和使用中的特殊自訂設定等詳細資料。
如果您偏好使用開放原始碼工具，可以搭配 (或改用) 資料收集器指令碼。這些指令碼可協助您收集詳細資訊 (關於工作負載、功能、資料庫物件和資料庫程式碼)，並建立資料庫清查。此外，指令碼通常會提供詳細的資料庫遷移評估，包括遷移工作量估算。
建議使用 Google 工程師開發的開放原始碼工具 DMA。這項服務可提供完整準確的資料庫評估，包括使用中的功能、資料庫邏輯和資料庫物件 (包括結構定義、資料表、檢視表、函式、觸發條件和預存程序)。
如要使用 DMA，請從 Git 存放區下載資料庫引擎的收集指令碼，並按照操作說明操作。將輸出檔案傳送至 Google Cloud 進行分析。 Google Cloud 會建立並提供資料庫評估讀數，並提供遷移作業的後續步驟。
找出並記錄遷移範圍和可接受的停機時間
在這個階段，您需要記錄會影響遷移策略和工具的重要資訊。現在，您應該能回答下列問題：
- 資料庫是否大於 5 TB？
- 資料庫中是否有大型資料表？是否大於 16 TB？
- 資料庫位於何處 (區域和可用區)，與應用程式的距離為何？
- 資料多久變更一次？
- 您的資料一致性模型為何？
- 目的地資料庫有哪些選項？
- 來源和目的地資料庫的相容性如何？
- 資料是否需要存放在特定實體位置？
- 是否有資料可以壓縮及封存，或是有資料根本不需要遷移？
如要定義遷移範圍，請決定要保留和遷移哪些資料。遷移所有資料庫可能需要耗費大量時間和精力。部分資料可能會保留在來源資料庫備份中。例如，您可能不需要舊的記錄資料表或封存資料。或者，您也可以根據策略和工具，決定在遷移程序完成後再移動資料。
建立資料遷移基準，以便比較及評估結果和影響。這些基準是參考點，代表遷移前後的資料狀態，可協助您做出決策。請務必評估來源環境，以便評估資料遷移是否成功。這類測量包括：
- 資料的大小和結構。
- 資料的完整性和一致性。
- 最重要的業務交易和程序所需時間和成效。
判斷可承受的停機時間。停機時間對業務有何影響？是否有資料庫活動較少的時段，此時受停機時間影響的使用者較少？如果是，這些期間有多長？何時發生？建議您只在寫入作業停機時，仍提供唯讀要求。
評估部署和管理程序
建立清單後，請評估資料庫的作業和部署程序，判斷如何調整這些程序，以利遷移。這些程序是準備及維護正式環境的基礎。
請思考如何完成下列工作：
定義並強制執行執行個體的安全性政策：舉例來說，您可能需要替換 Amazon 安全性群組。您可以使用 Google IAM 角色、虛擬私有雲防火牆規則和 VPC Service Controls，控管 Cloud SQL 執行個體的存取權，並限制虛擬私有雲中的資料。
修補及設定執行個體：您可能需要更新現有的部署工具。例如，您可能在 Amazon 參數群組或 Amazon 選項群組中使用自訂設定。您可能需要調整佈建工具，才能使用 Google Cloud Storage 或 Secret Manager 讀取這類自訂設定清單。
管理監控和快訊基礎架構：Amazon 來源資料庫執行個體的指標類別，可在遷移過程中提供觀測能力。指標類別可能包括 Amazon CloudWatch、Performance Insights、Enhanced Monitoring 和 OS 程序清單。
完成評估
從 Amazon RDS 或 Amazon Aurora 環境建立清查項目後，請按照「遷移至 Google Cloud：評估及探索工作負載」一文所述，完成評估階段的其他活動。
規劃及建立基礎
在規劃和建構階段，您需要佈建及設定基礎架構，以執行下列操作：
- 支援 Google Cloud 環境中的工作負載。
- 連結來源環境和 Google Cloud 環境，完成遷移作業。
規劃和建構階段包含下列工作：
- 建立資源階層。
- 設定 Google Cloud的 Identity and Access Management (IAM)。
- 設定帳單資訊。
- 設定網路連線。
- 強化安全性。
- 設定記錄、監控和警告功能。
如要進一步瞭解各項工作，請參閱「遷移至 Google Cloud：規劃及建構基礎」。
如果您打算使用資料庫遷移服務進行遷移，請參閱「MySQL 網路方法」，瞭解遷移情境可用的網路設定。
監控與快訊
使用 Google Cloud Monitoring，其中包含多項 Google Cloud 產品的預先定義資訊主頁，包括 Cloud SQL 監控資訊主頁。或者，您也可以考慮使用與Google Cloud整合的第三方監控解決方案，例如 Datadog 和 Splunk。詳情請參閱「關於資料庫觀測能力」。
將 Amazon RDS 和 Amazon Aurora for MySQL 執行個體遷移至 MySQL 適用的 Cloud SQL
如要遷移執行個體，請按照下列步驟操作：
選擇遷移策略：持續複製或排定維護。
根據所選策略和需求，選擇遷移工具。
定義各項資料庫遷移作業的遷移計畫和時間表，包括準備和執行工作。
定義必須完成的準備工作，確保遷移工具能正常運作。
定義執行任務，包括實作遷移的工作活動。
為每項執行任務定義備用方案。
執行測試和驗證，這項作業可在獨立的測試環境中完成。
執行遷移作業。
執行正式環境切換作業。
清理來源環境並設定目標執行個體。
執行調整和最佳化。
以下各節將說明各個階段。
選擇遷移策略
在這個步驟中，您已有足夠的資訊，可以評估並選取下列其中一項遷移策略，最適合每個資料庫的用途：
- 排定維護作業 (也稱為一次性遷移或大爆炸遷移)：如果可以接受停機時間，這種方法最適合。這個選項的成本和複雜度相對較低，因為工作負載和服務不需要大幅重構。不過，如果遷移作業在完成前失敗，就必須重新啟動程序，這會延長停機時間。
持續複製 (也稱為線上遷移或涓滴遷移)：對於重要業務資料庫，這個選項可降低資料遺失風險，並幾乎不會造成停機。作業會分成多個區塊，因此如果發生失敗，復原和重複作業所需的時間會較少。不過，設定程序較為複雜，需要更多規劃和時間。此外，您也需要投入額外心力，重構連結至資料庫執行個體的應用程式。請考慮採用下列其中一種變化版本：
- 使用 Y (寫入和讀取) 方法，這是一種平行遷移形式，在遷移期間複製來源和目的地執行個體中的資料。
- 使用資料存取微服務，減少 Y (寫入和讀取) 方法所需的重構工作。
如要進一步瞭解資料遷移策略，請參閱「評估資料遷移方法」。
下圖顯示流程圖，其中包含您在決定單一資料庫的遷移策略時，可能會遇到的範例問題：
上方的流程圖顯示下列決策點：
您是否能承受任何停機時間？
- 如果不是，請採用持續複製遷移策略。
- 如果是，請繼續前往下一個決策點。
在遷移資料時，您是否能承受切換期間造成的停機時間？轉換時間範圍是指備份資料庫、將資料庫轉移至 Cloud SQL、還原資料庫，然後切換應用程式所需的時間。
- 如果不是，請採用持續複製遷移策略。
- 如果是，請採用排定維護遷移策略。
不同資料庫的策略可能有所不同，即使位於同一個執行個體也一樣。混合使用多種策略可獲得最佳成效。舉例來說，您可以透過排定維護作業的方式，遷移小型且不常使用的資料庫，但對於停機成本高昂的重要任務資料庫，則應使用持續複製功能。
一般來說，當初始來源執行個體和目標執行個體之間進行切換時，遷移作業即視為完成。任何複製作業 (如有) 都會停止，所有讀取和寫入作業都會在目標執行個體上完成。在兩個執行個體同步時切換，代表不會遺失資料，且停機時間最短。
如要進一步瞭解資料遷移策略和部署作業，請參閱「資料庫遷移分類」。
盡可能縮短停機時間，並減少遷移相關影響
如要設定遷移作業，確保應用程式不會停機，則需要更複雜的設定。在設定複雜度和停機時間之間取得適當平衡，並將停機時間安排在流量較低的營業時間。
每種遷移策略都有其優缺點，且會對遷移程序造成一些影響。舉例來說，複製程序會對來源執行個體造成額外負載，而應用程式可能會受到複製延遲的影響。應用程式 (和客戶) 可能必須在應用程式停機期間等待，至少要等到複製延遲結束，才能使用新的資料庫。在實際情況中，下列因素可能會增加停機時間：
- 資料庫查詢可能需要幾秒鐘才能完成。遷移時，進行中的查詢可能會遭到取消。
- 如果資料庫很大或緩衝記憶體很大，快取可能需要一些時間才能填滿。
- 在來源中停止並在 Google Cloud中重新啟動的應用程式，可能會在與 Google Cloud資料庫執行個體建立連線前，出現短暫延遲。
- 應用程式的網路路徑必須重新規劃。視 DNS 項目設定方式而定，這項作業可能需要一些時間。更新 DNS 記錄時，請在遷移前縮短存留時間。
以下常見做法有助於盡量縮短停機時間和降低影響：
- 找出停機時間對工作負載影響最小的時間範圍。例如非正常營業時間、週末或其他排定的維護期間。
- 找出工作負載中可在不同階段進行遷移和正式環境切換的部分。應用程式可能包含不同的元件，可以獨立、調整及遷移，而不會造成任何影響。例如前端、CRM 模組、後端服務和報表平台。這類模組可能有自己的資料庫，可安排在程序中較早或較晚的時間遷移。
- 如果目標資料庫可以容許一些延遲，建議您逐步遷移。使用遞增、批次資料移轉，並調整部分工作負載，以便與目標執行個體上的過時資料搭配使用。
- 建議您重構應用程式，盡可能降低遷移作業的影響。例如，調整應用程式，使其同時寫入來源和目標資料庫，進而實作應用程式層級的複製。
選擇遷移工具
遷移作業成功的關鍵在於選擇合適的遷移工具。決定遷移策略後，請查看並決定遷移工具。
市面上有許多工具，各自針對特定遷移用途進行最佳化。用途包括：
- 遷移策略 (排定維護或持續複製)。
- 來源和目標資料庫引擎及引擎版本。
- 來源和目標執行個體所在的環境。
- 資料庫大小。資料庫越大，遷移初始備份所需的時間就越長。
- 資料庫變更頻率。
- 可使用代管服務進行遷移。
為確保遷移和切換作業順利進行，您可以使用應用程式部署模式、基礎架構自動化調度管理和自訂遷移應用程式。不過，代管遷移服務這類專門工具，可協助將資料、應用程式，甚至是整個基礎架構，從一個環境移至另一個環境。這些工作會從來源資料庫擷取資料、將資料安全地傳輸至目標資料庫，並可視需要修改傳輸中的資料。這些功能可封裝複雜的遷移邏輯，並提供遷移監控功能。
代管遷移服務具有下列優點：
盡可能縮短停機時間：服務會盡可能使用資料庫引擎內建的複製功能，並執行副本升級。
確保資料完整性和安全性：資料會安全可靠地從來源資料庫移轉至目的地資料庫。
提供一致的遷移體驗：使用資料庫遷移執行檔，可將不同的遷移技術和模式整合至一致的通用介面，方便您管理及監控。
提供彈性且經過驗證的遷移模式：資料庫遷移不常發生，但卻是重要事件。為避免新手錯誤和現有解決方案的問題，您可以使用經驗豐富的專家提供的工具，而不是建構自訂解決方案。
最佳化成本：相較於為自訂遷移解決方案佈建額外伺服器和資源，代管遷移服務可能更具成本效益。
下一節將根據所選遷移策略，說明建議的遷移工具。
排定維護作業遷移作業的工具
下圖顯示流程圖，其中包含一些問題，可協助您在使用排定維護遷移策略時，選擇單一資料庫的遷移工具：
上方的流程圖顯示下列決策點：
- 您是否偏好代管遷移服務？
- 如果是，建議您使用資料庫遷移服務。
- 如果沒有，建議您使用資料庫引擎內建的備份功能進行遷移。
使用代管遷移服務有一些優點，詳情請參閱本文的「選擇遷移工具」一節。
下列子節說明可用於一次性遷移的工具，以及其限制和最佳做法。
使用資料庫遷移服務進行排定維護遷移
資料庫遷移服務會管理初始同步作業和持續變更資料擷取 (CDC) 複製作業，並提供遷移作業的狀態。
您可以使用資料庫遷移服務建立遷移工作，並加以管理及驗證。建議您使用資料庫遷移服務，因為這項服務支援透過單次遷移工作，將資料庫遷移至 MySQL 適用的 Cloud SQL。如果是大型資料庫，您可以在資料庫遷移服務中使用資料轉儲平行處理。
如要進一步瞭解資料庫遷移架構和資料庫遷移服務，請參閱「使用資料庫遷移服務將資料庫遷移至 MySQL 適用的 Cloud SQL」和「MySQL 遷移擬真度」。
如要進一步瞭解資料庫遷移服務的限制和必要條件，請參閱下列文章：
內建資料庫引擎備份
如果可以接受長時間停機，且來源資料庫相對靜態，則可使用資料庫引擎內建的轉儲和載入 (有時也稱為備份和還原) 功能。
設定和同步處理需要一些心力，尤其是資料庫數量龐大時，但資料庫引擎備份通常很容易取得，而且使用起來很簡單。
資料庫引擎備份有下列一般限制：
- 備份作業容易出錯，尤其是手動執行時。
- 如果備份管理不當，資料就不安全。
- 備份作業缺乏適當的監控功能。
- 如果使用這項工具遷移多個資料庫，則需要投入心力進行擴充。
如果選擇這個方法，請考量下列限制和最佳做法：
- 如果資料庫相對較小 (10 GB 以下)，建議使用 mysqldump。雖然沒有固定限制，但 mysqldump 的理想資料庫大小通常不超過 10 GB。
如果匯入的資料庫大於 10 GB，可能需要採取其他策略，盡量縮短資料庫停機時間。以下列舉幾項策略：
- 匯出子節中的結構定義和資料，不含次要索引鍵。
- 善用時間戳記。如果資料表使用時間戳記資料欄，您可以使用 mysqldump 指令的功能，指定
WHERE子句，依時間戳記資料欄篩選。 - 請考慮其他做法，例如使用 mydumper 和 myloader 工具。
資料庫轉儲和備份通常不含 MySQL 使用者帳戶。準備遷移時，請檢查來源執行個體中的所有使用者帳戶。舉例來說，您可以對每位使用者執行 SHOW GRANTS 指令，檢查現有的權限組合，並查看在 Cloud SQL 中是否有任何限制。此外，Percona 提供的 pt-show-grants 工具也可以列出授權內容。
遷移具有 DEFINER 屬性的資料庫物件時，Cloud SQL 的使用者權限限制可能會影響遷移作業。舉例來說，預存程序可能具有超級權限定義者，以便執行 SQL 指令，例如變更全域變數，但 Cloud SQL 不允許這項操作。在這種情況下，您可能需要重新編寫預存程序程式碼，或在其他遷移步驟中分別遷移預存程序這類非資料表物件。詳情請參閱「匯入及匯出資料的最佳做法」。
如要進一步瞭解限制和最佳做法，請參閱下列資源：
其他排定維護作業遷移方法
使用代管匯入功能設定外部 MySQL 資料庫的複製作業時，系統會先將外部資料庫的資料載入 Cloud SQL 執行個體。這項做法會使用服務，從外部伺服器 (在本例中為 RDS 執行個體) 擷取資料，並直接匯入 Cloud SQL 執行個體。
如果是大型資料庫 (數 TB)，更快速的方法是使用 mydumper 和 myloader 工具，自訂匯入初始載入作業。
您可以考慮將 MySQL 資料庫中的資料表匯出為 CSV 檔案，然後匯入 MySQL 適用的 Cloud SQL。如要從 RDS 執行個體匯出資料，可以使用 AWS Database Migration Service (AWS DMS)，並將 S3 bucket 做為目標。
如需詳細資訊和步驟，請參閱「使用代管匯入功能設定外部資料庫的複製作業」。
持續複製遷移作業的工具
下圖顯示流程圖，其中包含一些問題，可協助您在使用持續複製遷移策略時，選擇單一資料庫的遷移工具：
上方的流程圖顯示下列決策點：
您是否偏好使用代管遷移服務？
如果是，您是否能承受幾秒鐘的寫入停機時間 (取決於資料庫中的資料表數量)？
- 如果是，請使用資料庫遷移服務。
- 如果不是，請瞭解其他遷移方式。
如果沒有，則必須評估是否支援資料庫引擎內建複製功能：
- 如果是，建議使用內建複製功能。
- 如果沒有，建議您瞭解其他遷移方式。
以下各節說明可用於持續遷移作業的工具，以及其限制和最佳做法。
使用資料庫遷移服務進行持續複製遷移
資料庫遷移服務採用持續遷移工作類型，可順暢支援持續遷移。只有連續遷移工作可以升級，這表示複製作業會停止。
如果選擇這項工具，請考量下列限制和最佳做法：
- 遷移期間，請避免執行長時間執行的交易。在這種情況下，如果您不是從 AWS Aurora 遷移，建議從唯讀副本遷移。
- 如需完整的限制清單，請參閱「已知限制」。
資料庫引擎內建複製功能
除了資料庫遷移服務，您也可以使用資料庫引擎內建的複製功能，執行連續遷移作業。
資料庫複製是指將資料從主要資料庫複製並發布到其他資料庫 (稱為副本) 的程序。這項技術旨在提高資料存取性，並改善資料庫系統的容錯能力和可靠性。雖然資料庫遷移並非資料庫複製的主要目的，但仍可做為達成這項目標的工具。資料庫複製通常是持續進行的程序，在主要資料庫中插入、更新或刪除資料時，就會即時進行。這項作業可以一次完成，也可以分批進行。
大多數現代資料庫引擎都會實作不同的資料庫複製方式。其中一種複製方式是複製主要執行個體的預寫記錄或交易記錄，並傳送至副本。這種方法稱為實體或二進位複製。其他複製類型則會發布主要資料庫收到的原始 SQL 陳述式，而非複製檔案系統層級的變更。
Cloud SQL 支援 MySQL 複製功能。不過，這項功能有一些必要條件和限制。
需求條件：
- 確認 Amazon RDS 或 Amazon Aurora 執行個體使用的是 MySQL 5.5、5.6、5.7 或 8.0。
- 確認已啟用二進位記錄。
- 如要加快初始完整轉儲階段，請從 CPU 和記憶體大小的角度，選擇足夠大的機器級別。
- 如要加快 CDC 階段，可以嘗試設定平行複製，並啟用高效能清除。
- 如果 Cloud SQL 副本已啟用內部 IP 位址，由於傳出 IP 位址並非靜態，請設定 Amazon RDS 或 Amazon Aurora 伺服器的防火牆，允許為虛擬私有雲網路的私人服務存取權分配的內部 IP 範圍，而 Cloud SQL 副本會將該網路做為私人網路。詳情請參閱「關於從外部伺服器複製」和「設定私人服務存取權」。
限制：
- 如果資料庫中有單一大型資料表和許多次要索引，初始完整轉儲作業可能需要較長時間。
- 如果外部伺服器包含
DEFINER子句 (檢視表、事件、觸發條件或預存程序)，則視這些陳述式的執行順序而定，複製作業可能會失敗。進一步瞭解 Cloud SQL 中的DEFINER用量和潛在解決方法。 - InnoDB 是 Cloud SQL 唯一支援的資料庫引擎。遷移 MyISAM 可能會導致資料不一致，且需要驗證資料。請參閱「將資料表從 MyISAM 轉換為 InnoDB」。
其他持續複製遷移方法
其他持續複製遷移方法包括：
重構應用程式以執行 Y (寫入和讀取)，或使用資料存取微服務。
- 持續複製作業是由應用程式執行。
- 遷移作業的重點在於重構或開發連結至資料庫執行個體的工具。
- 接著，讀取器應用程式會逐步重構及部署，以使用目標執行個體。
使用 Datastream 複製 MySQL 執行個體的近乎即時變更。
- Datastream 是無伺服器 CDC 和複製服務，可與 Amazon RDS 或 Amazon Aurora 搭配使用，複製及同步處理資料。
- 使用 Datastream 將 MySQL 執行個體的變更複製到 BigQuery 或 Cloud Storage，然後使用 Dataflow 或 Managed Service for Apache Spark 將資料匯入 Cloud SQL 執行個體。
如要進一步瞭解如何使用 Datastream 複製資料，請參閱下列文章：
- 在 Datastream 設定 Amazon RDS for MySQL 資料庫
- 在 Datastream 中設定 Amazon Aurora MySQL 資料庫
- 使用 Datastream 即時串流資料變更
用於持續複製遷移作業的第三方工具
在某些情況下，最好使用一個第三方工具來處理大部分資料庫引擎。例如，您可能偏好使用代管遷移服務，且需要確保目標資料庫一律與來源近乎即時同步，或是在遷移過程中需要更複雜的轉換，例如資料清理、重組和調整。
如果您決定使用第三方工具，請選擇下列其中一項建議，這些建議適用於大多數資料庫引擎。
Striim 是端對端記憶體內平台，可即時收集、篩選、轉換、充實、匯總、分析及傳送資料：
優點：
- 可處理大量資料和複雜的遷移作業。
- 內建 SQL Server 變更資料擷取功能。
- 預先設定的連線範本和無程式碼管道。
- 能夠處理在繁重交易負載下運作的重要大型資料庫。
- 僅傳送一次。
缺點：
- 非開放原始碼。
- 費用可能很高，尤其是遷移時間較長時。
- 資料定義語言 (DDL) 作業傳播有一些限制。詳情請參閱「支援的 DDL 作業」和「結構定義演變注意事項和限制」。
如要進一步瞭解 Striim，請參閱「在 Google Cloud中執行 Striim」。
Debezium 是開放原始碼的分散式 CDC 平台，可將資料變更串流至外部訂閱者：
優點：
- 開放原始碼。
- 強大的社群支援。
- 符合成本效益
- 精細控管資料列、資料表或資料庫。
- 專門用於從資料庫交易記錄即時擷取變更。
缺點：
- 須具備 Kafka 和 ZooKeeper 的相關經驗。
- 至少傳送一次資料變更，這表示您需要處理重複資料。
- 使用 Grafana 和 Prometheus 手動設定監控功能。
- 不支援漸進式批次複製。
如要進一步瞭解 Debezium 遷移作業，請參閱「使用 Debezium 近乎即時複製資料」。
Fivetran 是自動化資料移動平台，可將資料移出雲端資料平台，或在雲端資料平台之間移動。
優點：
- 預先設定的連線範本和無程式碼管道。
- 將來源資料庫的任何結構定義變更，套用至目標資料庫。
- 資料變更僅傳送一次，因此您不需要處理重複項目。
缺點：
- 非開放原始碼。
- 對複雜資料轉換的支援有限。
定義遷移計畫和時程
為確保資料庫遷移和正式環境切換作業順利完成，建議您制定明確、全面的遷移計畫。為盡量降低對業務的影響，建議您列出所有必要工作項目。
定義遷移範圍後，您就能瞭解在資料庫遷移程序之前、期間和之後必須執行的工作。舉例來說，如果您決定不從資料庫遷移特定資料表，可能需要執行遷移前或遷移後工作，才能實作這項篩選。您也必須確保資料庫遷移作業不會影響現有的服務水準協議 (SLA) 和業務連續性計畫。
建議您在遷移規劃說明文件中加入下列文件：
- 技術設計文件 (TDD)
- RACI 矩陣
- 時間軸 (例如 T-Minus 方案)
資料庫遷移是反覆執行的程序，第一次遷移通常比後續遷移慢。一般來說，妥善規劃的遷移作業不會發生問題，但仍可能出現未預期的狀況。建議您一律備妥復原計畫。建議您按照「遷移至 Google Cloud：驗證遷移計畫的最佳做法」中的指引操作。
TDD
TDD 會記錄專案的所有技術決策。請在 TDD 中加入下列內容：
- 業務需求和重要性
- 復原時間目標 (RTO)
- 復原點目標 (RPO)
- 資料庫遷移詳細資料
- 預估遷移作業量
- 遷移驗證建議
RACI 矩陣
部分遷移專案需要 RACI 矩陣，這是一種常見的專案管理文件，用於定義哪些個人或群組負責遷移專案中的工作和交付項目。
時間軸
為每個需要遷移的資料庫準備時間軸。包括所有必須執行的工作任務，以及定義的開始日期和預估結束日期。
建議您為每個遷移環境建立 T-minus 計畫。T-minus 計劃的結構為倒數時間表，列出完成遷移專案所需的所有工作，以及負責團隊和預估時間。
時間軸不僅應考量遷移前的準備工作執行，也應考量資料移轉後進行的驗證、稽核或測試工作。
遷移工作的時間長度通常取決於資料庫大小，但也有其他需要考量的因素，例如商業邏輯複雜度、應用程式用量和團隊可用性。
倒數計畫可能如下所示：
| 日期 | 階段 | 類別 | Tasks | 角色 | T-minus | 狀態 |
|---|---|---|---|---|---|---|
| 2023/11/1 | 遷移前 | 評估 | 建立評估報告 | 探索團隊 | -21 | 完成 |
| 2023/11/7 | 遷移前 | 備妥目標 | 按照設計文件所述，設計目標環境 | 遷移團隊 | -14 | 完成 |
| 2023/11/15 | 遷移前 | 公司治理 | 遷移日期和 T-Minus 核准 | 主管階層 | -6 | 完成 |
| 2023/11/18 | 遷移 | 設定 DMS | 建立連線設定檔 | 雲端遷移工程師 | -3 | 完成 |
| 2023/11/19 | 遷移 | 設定 DMS | 建立及啟動遷移工作 | 雲端遷移工程師 | -2 | 尚未開始 |
| 2023/11/19 | 遷移 | 監控 DMS | 監控 DMS 工作和來源執行個體中的 DDL 變更 | 雲端遷移工程師 | -2 | 尚未開始 |
| 2023/11/21 | 遷移 | 轉換 DMS | 升級 DMS 副本 | 雲端遷移工程師 | 0 | 尚未開始 |
| 2023/11/21 | 遷移 | 遷移驗證 | 資料庫遷移驗證 | 遷移團隊 | 0 | 尚未開始 |
| 2023/11/21 | 遷移 | 應用程式測試 | 執行功能和效能測試 | 遷移團隊 | 0 | 尚未開始 |
| 2023/11/22 | 遷移 | 公司治理 | 遷移驗證：繼續或停止 | 遷移團隊 | 1 | 尚未開始 |
| 2023/11/23 | 遷移後 | 驗證監控功能 | 設定監控作業 | 基礎架構團隊 | 2 | 尚未開始 |
| 2023/11/25 | 遷移後 | 安全性 | 移除 DMS 使用者帳戶 | 安全團隊 | 4 | 尚未開始 |
多項資料庫遷移作業
如果您有多個資料庫需要遷移，遷移計畫應包含所有遷移作業的工作。
建議您先遷移較小、最好是非關鍵任務的資料庫，這種做法可協助您累積知識，並對遷移程序和工具更有信心。您也可以在整體遷移時程的早期階段，偵測程序中的任何缺陷。
如果您有多個資料庫需要遷移，可以同時進行。舉例來說，為了加快遷移程序，您可以選擇同時遷移一組小型、靜態或較不重要的資料庫，如下圖所示。
在圖表所示的範例中，資料庫 1 至 4 是一組同時遷移的小型資料庫。
定義準備工作
準備工作是指您必須完成的所有活動，以符合遷移必要條件。如果沒有完成準備工作，就無法進行遷移，或遷移後的資料庫會處於無法使用的狀態。
準備工作可分為以下幾類：
- Amazon RDS 或 Amazon Aurora 執行個體準備工作和必要條件
- 來源資料庫準備工作和必要條件
- Cloud SQL 設定
- 遷移專屬設定
Amazon RDS 或 Amazon Aurora 執行個體準備工作和必要條件
請考量下列常見的設定和必要條件工作：
- 視遷移路徑而定，您可能需要在 RDS 執行個體上允許遠端連線。如果 RDS 執行個體在虛擬私有雲中設為私人，Amazon 和 Google Cloud之間必須有私人 RFC 1918 連線。
您可能需要設定新的安全性群組，允許在必要通訊埠上進行遠端連線。
- 在 AWS 中，資料庫執行個體的網路存取權預設為關閉。
- 您可以在安全性群組中指定規則，允許從 IP 位址範圍、通訊埠或安全性群組存取。與該安全性群組相關聯的所有資料庫執行個體，都適用相同規則。
請確認您有足夠的可用磁碟空間，可在 Amazon RDS 執行個體執行完整載入作業期間，緩衝處理 WAL 記錄。
為獲得最佳遷移結果，建議從唯讀副本遷移，除非您是從 Amazon Aurora 遷移。此外，建議您在資料庫活動較少的時段開始遷移程序。
MySQL 主機名稱長度上限為 60 個半形字元。Amazon RDS 資料庫主機名稱通常超過 60 個半形字元。如果遷移的資料庫屬於這種情況，請設定 DNS 重新導向，建立
CNAME記錄，將網域名稱與 RDS 資料庫執行個體的網域名稱建立關聯。如果使用內建複製功能，則須設定 Amazon RDS 或 Amazon Aurora 執行個體，以便進行複製。內建複製功能或使用該功能的工具，需要將 MySQL 的二進位記錄設為
ROW。如果使用第三方工具，通常需要先完成設定，才能使用。請參閱第三方工具的說明文件。
如要進一步瞭解執行個體準備作業和必要條件，請參閱「設定 MySQL 複製作業的外部伺服器」。
來源資料庫準備工作和必要條件
- 如果選擇使用資料庫遷移服務，您必須先設定來源資料庫，才能連線。請先檢查遷移工作，再執行。詳情請參閱「設定 MySQL 來源」。
- 視資料庫引擎而定，您可能需要變更特定功能。舉例來說，MySQL 適用的 Cloud SQL 僅支援 InnoDB 資料庫引擎。您必須將 MyISAM 資料表變更為 InnoDB。
- 部分第三方遷移工具會要求所有
LOB資料欄皆可為空值。任何NOT NULL的LOB資料欄都必須在遷移期間移除該限制。 在正式環境中，對來源環境進行基準測量。請考量下列事項：
- 評估資料大小和工作負載效能。重要查詢或交易平均需要多久時間？尖峰時段要等多久？
- 請記錄基準測量結果，以便日後比較，協助您判斷資料庫遷移的擬真度是否令人滿意。決定是否可以切換正式環境工作負載並停用來源環境，或是否仍需要來源環境做為備用。
Cloud SQL 設定
請仔細選擇目標 MySQL 適用的 Cloud SQL 資料庫執行個體大小和規格，以符合來源的類似效能需求。請特別注意磁碟大小和處理量、IOPS 和 vCPU 數量。如果大小不正確，可能會導致遷移時間過長、資料庫效能問題、資料庫錯誤和應用程式效能問題。
建立 Cloud SQL 執行個體前，請務必確認下列屬性和需求，因為這些項目一經設定即無法變更，除非重新建立。
- 請謹慎選擇目標 Cloud SQL 執行個體的專案和區域。Cloud SQL 執行個體無法在 Google Cloud 專案和區域之間遷移，除非進行資料移轉。
- 遷移至 Cloud SQL 上相符的主要版本。舉例來說，如果來源在 Amazon RDS 或 Amazon Aurora 上使用 MySQL 8.0.34，則應遷移至 MySQL 適用的 Cloud SQL 8.0.34 版。
- 如果您使用內建資料庫引擎備份或資料庫遷移服務，請另外複製使用者資訊。Cloud SQL 使用 Google IAM 管理使用者。詳情請參閱「內建資料庫引擎備份」一節中的限制。
- 查看資料庫引擎設定旗標，並比較來源和目標執行個體的值。請務必瞭解這些設定的影響，以及是否需要保持一致。舉例來說，建議您在遷移前對來源資料庫執行
SHOW VARIABLES指令，然後在 Cloud SQL 資料庫上再次執行。視需要更新 Cloud SQL 資料庫的旗標設定，複製來源設定。請注意，Cloud SQL 執行個體不支援所有 MySQL 旗標。
如要進一步瞭解 Cloud SQL 設定，請參閱下列資源：
遷移專屬設定
如要將 SQL dump 檔案匯入 Cloud SQL，可能需要建立 Cloud Storage bucket。這個 bucket 會儲存資料庫轉儲。
如果使用複製功能，請務必確保 Cloud SQL 副本可以存取主要資料庫。您可以透過記錄的連線選項取得這項存取權。
視情境和重要性而定，您可能需要實作備用情境，通常包括反轉複製方向。在這種情況下，您可能需要額外的複製機制，將資料從 Cloud SQL 複製回來源 Amazon 執行個體。
使用大多數第三方工具時，您需要佈建遷移專用資源。舉例來說，如要使用 Striim，您必須透過 Google Cloud Marketplace 開始。接著，如要在 Striim 中設定遷移環境，您可以使用 Flow Designer 建立及變更應用程式，也可以選取預先存在的範本。您也可以使用 Tungsten 查詢語言 (TQL) 程式設計語言編寫應用程式。您可以使用資料驗證資訊主頁，以視覺化方式呈現 Striim 應用程式處理的資料。
遷移作業完成並通過驗證後，您可以停用連結 Amazon 和Google Cloud 環境的資源。
如要瞭解詳情，請參考下列資源：
定義執行工作
執行工作會實際執行遷移作業。工作內容取決於您選擇的遷移工具，詳情請參閱下列各節。
內建資料庫引擎備份
如要執行一次性遷移，請使用 mysqldump 公用程式建立備份，將資料從 Amazon RDS 複製到本機用戶端電腦。如需操作說明，請參閱「將 SQL dump 檔案匯入 MySQL 適用的 Cloud SQL」。
您可以查看 Cloud SQL 執行個體的匯入和匯出作業狀態。
資料庫遷移服務遷移工作
在資料庫遷移服務中定義及設定遷移工作，將資料從來源執行個體遷移至目的地資料庫。遷移工作會透過使用者定義的連線設定檔，連線至來源資料庫執行個體。
測試所有必要條件，確保工作能順利執行。請選擇工作負載可承受短暫停機時間的時段，以便進行遷移和正式環境切換。
在資料庫遷移服務中，遷移作業會先進行初始完整備份和載入，接著從來源資料庫執行個體持續將變更傳送至目的地資料庫執行個體。
資料庫遷移服務需要幾秒鐘的時間，才能在來源 Amazon RDS 或 Amazon Aurora 執行個體的所有資料表上取得讀取鎖定，以便以一致的方式執行初始完整轉儲。為了取得讀取鎖定，可能需要 1 到 49 秒的寫入停機時間。停機時間取決於資料庫中的資料表數量，1 秒對應 100 個資料表，9 秒對應 10, 000 個資料表。
資料庫遷移服務的遷移程序會以升級作業結束。升級資料庫執行個體後，目的地資料庫會與來源資料庫的變更串流中斷連線，然後升級為主要執行個體，成為獨立的目的地執行個體。這種方法有時也稱為正式環境切換。
如要進一步瞭解資料庫遷移服務中的遷移工作，請參閱下列資源：
如需詳細的遷移設定程序，請參閱「使用資料庫遷移服務將資料庫遷移至 MySQL 適用的 Cloud SQL」。在資料庫遷移服務中，遷移作業是透過啟動及執行遷移工作來執行。
資料庫引擎內建複製功能
您可以使用內建的複製功能，將 Amazon RDS 複製到外部 MySQL 適用的 Cloud SQL 執行個體。
如果是 MySQL，您必須先從可儲存在 Cloud Storage bucket 的初始轉儲開始，然後將資料匯入 MySQL 適用的 Cloud SQL。接著，您會啟動複製程序。
監控複製作業，並在適當時間停止寫入來源執行個體。再次檢查複製狀態，確認所有變更都已複製，然後將 MySQL 適用的 Cloud SQL 副本升級為獨立執行個體，完成遷移作業。
如要瞭解如何從 Amazon RDS 或 Amazon Aurora for MySQL 等外部伺服器設定內建複製功能，請參閱「關於從外部伺服器複製」和「設定 Cloud SQL 和外部伺服器以進行複製」的詳細操作說明。
如需更多資訊和指引，請參閱下列資源：
第三方工具
為所選第三方工具定義執行任務。
本節以 Striim 為例，Striim 使用的應用程式會從各種來源取得資料、處理資料，然後將資料傳送至其他應用程式或目標。
您可以使用網頁用戶端以圖形方式建立應用程式，其中包含來源、目標和其他邏輯元件，並組織成一或多個流程。
如要在 Striim 中設定遷移環境，您可以使用流程設計工具功能建立及變更應用程式，也可以從多個預先存在的範本中選取。應用程式也可以使用 TQL 程式設計語言編寫。
您可以使用資料驗證資訊主頁，以視覺化方式呈現 Striim 應用程式處理的資料。
如要快速開始在 Google Cloud中使用 Striim，請參閱「在 Google Cloud中執行 Striim」。如要進一步瞭解 Striim 的基本概念，請參閱「Striim 概念」。請務必參閱最佳做法指南，瞭解如何從初始載入切換至連續複製。
建議您採用下列資料遷移最佳做法：
- 每當計畫步驟開始和結束時，請通知相關團隊。
- 如果任何步驟花費的時間超過預期，請比較經過的時間與每個步驟分配的時間上限。發生這種情況時，請定期向相關團隊提供中間更新。
- 如果時間範圍大於計畫中為每個步驟保留的時間上限，請考慮復原。
- 針對遷移和切換計畫的每個步驟，做出「繼續或停止」的決策。
- 請考慮每個步驟的回復動作或替代方案。
定義備用廣告情境
為每項遷移執行工作定義備用待辦事項，防範遷移過程中可能發生的非預期問題。備用工作通常取決於遷移策略和使用的工具。
備用方案可能需要耗費大量心力。最佳做法是，在測試結果令人滿意之前，不要執行正式環境切換。資料庫遷移和備用方案都應經過適當測試，以免發生嚴重服務中斷。
定義成功標準，並為所有遷移執行工作設定時間。執行遷移模擬測試，有助於收集每項工作的預期時間資訊。舉例來說，如果是排定的維護遷移作業，您可以承受切換期間造成的停機時間。不過，請務必規劃後續行動，以免一次性遷移工作或備份還原作業中途失敗。視預定停機時間已過多久而定，如果遷移工作未在預期時間內完成，您可能需要延後遷移。
備用方案通常是指在執行正式環境切換後，如果目標執行個體出現問題，就復原遷移作業。如果實施備用方案，請務必將其視為完整的資料庫遷移，包括規劃和測試。
如果選擇不採用備用方案，請務必瞭解可能造成的後果。如果沒有備用方案，可能會增加不可預見的工作量，並在遷移過程中造成可避免的中斷。
雖然備用方案是最後手段，且大多數資料庫遷移作業最終都不會使用，但我們仍建議您一律備妥備用策略。
簡易備用廣告
在這個備用策略中，您會將應用程式切換回原始來源資料庫執行個體。如果您在復原時可以承受停機時間，或不需要在新目標系統上提交交易，請採用這項策略。
如果您確實需要目標資料庫上的所有寫入資料，且可以承受一些停機時間，可以考慮停止寫入目標資料庫執行個體、建立內建備份並在來源執行個體上還原，然後將應用程式重新連線至初始來源資料庫執行個體。視工作負載的性質和寫入目標資料庫執行個體的資料量而定，您可以在稍後將其帶入初始來源資料庫系統，特別是當工作負載不依賴任何特定記錄建立時間或任何時間排序限制時。
反向複製
在這項策略中，您會在正式環境切換後，將新目標資料庫上發生的寫入作業複製回初始來源資料庫。這樣一來，原始來源就會與新的目標資料庫保持同步，且寫入作業會在新的目標資料庫執行個體上進行。主要缺點是，您必須先切換至目標資料庫執行個體，才能測試複製串流，因此無法進行端對端測試，且有一小段時間無法復原。
如果可以保留來源執行個體一段時間，並使用持續複製遷移功能，請選擇這個方法。
正向複製
這項策略是反向複製的變體。將新目標資料庫的寫入作業複製到您選擇的第三個資料庫執行個體。您可以將應用程式指向這個第三資料庫，該資料庫會連線至伺服器，並在伺服器無法使用時執行唯讀查詢。您可以視需求使用任何複製機制。這種做法的優點是可以進行完整的端對端測試。
如果您希望隨時有備用資料庫，或必須在正式環境切換後不久捨棄初始來源資料庫，請採用這種方法。
重複寫入
如果您選擇 Y (寫入和讀取) 或資料存取微服務遷移策略，則這項備用方案已設定完成。這項策略較為複雜，因為您需要重構應用程式，或開發人員工具來連線至資料庫執行個體。
應用程式會同時寫入初始來源和目標資料庫執行個體，讓您逐步切換正式環境，直到只使用目標資料庫執行個體為止。如有任何問題，您可以將應用程式重新連線至初始來源，不會造成停機。確認遷移作業順利完成後，即可捨棄初始來源和重複寫入機制。
如果遷移期間不能有停機時間、需要可靠的備用方案，且有時間和資源執行應用程式重構，建議採用這種做法。
執行測試和驗證
這個步驟的目標是測試及驗證下列項目：
- 成功遷移資料庫中的資料。
- 現有應用程式切換至新的目標執行個體後，與這些應用程式整合。
定義關鍵成功因素，這取決於您的遷移作業。以下是主觀因素的例子：
- 要遷移的資料。對於某些工作負載，可能不需要遷移所有資料。您可能不想遷移已匯總、備援、封存或舊的資料。您可能會將這些資料封存至 Cloud Storage bucket 做為備份。
- 可接受的資料遺失百分比。這項做法特別適用於分析工作負載所用的資料，因為遺失部分資料不會影響工作負載的一般趨勢或效能。
- 資料品質和數量條件，可套用至來源環境，並在遷移後與目標環境進行比較。
- 成效條件。在目標環境中，某些業務交易可能會較慢，但處理時間仍在預期範圍內。
來源環境中的儲存空間設定可能不會直接對應至Google Cloud 環境指定目標。例如，具有 IOPS 爆發效能的一般用途 SSD (gp2 和 gp3) 磁碟區或佈建 IOPS SSD 的設定。如要比較並正確調整目標執行個體的大小，請在評估和驗證階段，對來源執行個體進行基準測試。
在基準測試程序中，您會將類似正式環境的作業序列套用至資料庫執行個體。在此期間，您會擷取及處理指標，藉此評估及比較來源和目標系統的相對效能。
如果是傳統的伺服器型設定，請使用尖峰負載期間觀察到的相關測量結果。如果是 Aurora Serverless 等彈性資源容量模型，建議查看歷來指標資料，瞭解擴充需求。
下列工具可用於測試、驗證和資料庫基準測試：
- HammerDB：開放原始碼資料庫基準測試和負載測試工具。這項基準測試支援多個資料庫引擎 (TPROC-C 和 TPROC-H) 的複雜交易和分析工作負載，並符合業界標準。HammerDB 提供詳細說明文件，並擁有廣大的使用者社群。您可以在多個資料庫引擎和儲存空間設定之間共用及比較結果。詳情請參閱「使用 HammerDB 進行 SQL Server 負載測試」和「使用 HammerDB 進行 Amazon RDS SQL Server 效能基準測試」。
- DBT2 基準工具：專為 MySQL 設計的基準測試工具。一組資料庫工作負載套件會模擬擁有倉庫的公司的應用程式，並涉及讀取和寫入交易的混合。如要使用現成的線上交易處理 (OLTP) 負載測試，請使用這項工具。
- DbUnit：開放原始碼單元測試工具，用於測試 Java 中的關聯式資料庫互動。設定和使用方式都很簡單，且支援多種資料庫引擎 (MySQL、PostgreSQL、SQL Server 等)。不過，視資料庫的大小和複雜度而定，測試執行有時可能會很慢。如果簡單易用是重要考量，建議使用這項工具。
- DbFit：開放原始碼資料庫測試架構，支援測試導向的程式碼開發和自動化測試。它使用基本語法建立測試案例，並提供資料導向測試、版本管控和測試結果報告功能。不過，與其他工具相比，這項工具對複雜查詢和交易的支援有限，也沒有大型社群支援或豐富的文件。如果查詢不複雜，且您想執行自動化測試，並將測試與持續整合和推送程序整合，建議使用這項工具。
如要執行端對端測試 (包括測試遷移計畫)，請務必執行遷移模擬測試。模擬測試會執行完整範圍的資料庫遷移作業，不會切換任何正式環境工作負載，並提供下列優點：
- 確保所有物件和設定都已正確遷移。
- 協助您定義及執行遷移測試案例。
- 提供實際遷移所需時間的深入分析，方便您調整時間軸。
- 代表測試、驗證及調整遷移計畫的機會。有時您無法事先規劃所有事項，因此這有助於找出任何缺口。
資料測試可以針對要遷移的一小部分資料庫或整個資料庫執行。視資料庫總數和用於實作遷移作業的工具而定，您可以決定採用風險導向的方法。採用這種方法時，您會對透過相同工具遷移的部分資料庫執行資料驗證，尤其是當這項工具是代管遷移服務時。
如要進行測試，您必須能存取來源和目標資料庫，並執行下列工作：
- 比較來源和目標結構定義。請檢查所有資料表和執行檔是否存在。檢查資料列數量，並在資料庫層級比較資料。
- 執行自訂資料驗證指令碼。
- 測試遷移的資料是否也顯示在已切換為使用目標資料庫的應用程式中 (遷移的資料是透過應用程式讀取)。
- 測試各種用途，在切換的應用程式和目標資料庫之間執行整合測試。這項測試包括透過應用程式讀取及寫入資料至目標資料庫，確保工作負載能完整支援遷移的資料和新建立的資料。
- 測試最常用資料庫查詢的效能，觀察是否因設定錯誤或大小不當而導致效能降低。
理想情況下，所有這些遷移測試情境都應自動化，且可在任何來源系統上重複執行。自動化測試案例套件會根據切換的應用程式進行調整。
如果您使用資料庫遷移服務做為遷移工具，請參閱「驗證遷移作業」。
Data Validation Tool
如要執行資料驗證，建議您使用 Data Validation Tool (DVT)。DVT 是由 Google 支援的開放原始碼 Python CLI 工具，提供自動化且可重複的解決方案，用於驗證不同環境。
DVT 提供自訂的多層級驗證功能，可在資料表、資料欄和資料列層級比較來源和目標資料表，有助於簡化資料驗證程序。您也可以新增驗證規則。
DVT 涵蓋多種 Google Cloud 資料來源，包括 AlloyDB for PostgreSQL、BigQuery、Cloud SQL、Spanner、JSON，以及 Cloud Storage 上的 CSV 檔案。此外，這項服務還能與 Cloud Run functions 和 Cloud Run 整合，用於事件導向的觸發和自動化調度管理。
DVT 支援下列類型的驗證：
- 結構定義層級比較
- 資料欄 (包括「AVG」、「COUNT」、「SUM」、「MIN」、「MAX」、「GROUP BY」和「STRING_AGG」)
- 資料列 (包括欄位比較中的雜湊和完全比對)
- 自訂查詢結果比較
如要進一步瞭解 DVT，請參閱 Git 存放區和使用 Google Cloud的 Data Validation Tool 輕鬆驗證資料。
執行遷移作業
遷移工作包括支援從一個系統轉移到另一個系統的活動。
建議您採用下列資料遷移最佳做法：
- 在計畫步驟開始和結束時，通知相關團隊。
- 如果任何步驟耗費的時間超過預期，請比較經過的時間與該步驟分配的時間上限。發生這種情況時，請定期向相關團隊提供中間更新。
- 如果時間範圍大於計畫中為每個步驟保留的時間上限，請考慮復原。
- 針對遷移和切換計畫的每個步驟，做出「繼續或停止」的決策。
- 請考慮每個步驟的回復動作或替代方案。
按照定義的執行工作執行遷移作業，並參閱所選遷移工具的說明文件。
執行正式環境轉換
高階正式環境切換程序可能會因所選遷移策略而異。如果工作負載可以停機，請先停止寫入來源資料庫，再開始遷移切換。
如果是連續複製遷移作業，您通常會在切換程序中執行下列高階步驟：
- 停止將資料寫入來源資料庫。
- 排空來源。
- 停止複製程序。
- 部署指向新目標資料庫的應用程式。
使用所選遷移工具遷移資料後，請驗證目標資料庫中的資料。您確認來源資料庫和目標資料庫已同步，且目標執行個體中的資料符合您選擇的遷移成功標準。
資料驗證通過條件後，即可執行應用程式層級切換。部署已重構的工作負載，改用新的目標執行個體。您部署的應用程式版本會指向新的目標資料庫執行個體。部署作業可以透過滾動式更新、階段式發布或藍綠部署模式執行。應用程式可能會停機。
請遵循下列最佳做法，順利切換至正式環境：
- 在切換後，監控與目標資料庫搭配運作的應用程式。
- 定義監控時間範圍，判斷是否需要實施備用方案。
- 請注意，如果變更某些資料庫旗標，可能需要重新啟動 Cloud SQL 或 AlloyDB for PostgreSQL 執行個體。
- 請考量復原遷移作業所需的工作量，是否可能大於修正目標環境中出現的問題。
清除來源環境，並設定 Cloud SQL 或 AlloyDB for PostgreSQL 執行個體
完成切換後，即可刪除來源資料庫。建議您在清理來源執行個體前，先執行下列重要動作：
為每個來源資料庫建立最終備份。這些備份會提供來源資料庫的最終狀態。在某些情況下，您也可能需要備份資料，以遵守特定資料法規。
收集來源執行個體的資料庫參數設定。或者，請確認這些項目與您在盤點建構階段收集的項目相符。調整目標執行個體參數，使其與來源執行個體的參數相符。
從來源執行個體收集資料庫統計資料，並與目標執行個體中的統計資料進行比較。如果統計資料不一致，就很難比較來源執行個體和目標執行個體的效能。
在備用方案中，您可能需要將 Cloud SQL 執行個體上的寫入作業複製回原始來源資料庫。設定方式與遷移程序類似，但會反向執行：初始來源資料庫會成為新的目標。
為確保來源執行個體在完全移轉後保持最新狀態，最佳做法是將目標 Cloud SQL 執行個體上執行的寫入作業，複製回來源資料庫。如需復原，您可以復原至舊的來源執行個體，盡可能減少資料遺失。
除了清理來源環境，您還必須為 Cloud SQL 執行個體進行下列重要設定：
- 為主要執行個體設定維護期間，控管中斷性更新的執行時間。
- 請設定執行個體的儲存空間，確保至少有 20% 的可用空間，以便 Cloud SQL 執行任何重要的資料庫維護作業。如要在可用磁碟空間低於 20% 時收到警告，請為磁碟使用率指標建立以指標為基礎的警告政策。
請勿在前一項作業完成前，啟動管理作業。
如要進一步瞭解維護作業和最佳做法，請參閱「Cloud SQL 執行個體維護作業」。
在遷移後最佳化環境
最佳化是遷移作業的最後階段。在這個階段，您會反覆執行最佳化工作，直到目標環境符合最佳化需求。每次疊代的步驟如下：
- 評估目前的環境、團隊和最佳化循環。
- 確立最佳化需求和目標。
- 最佳化環境和團隊。
- 調整最佳化循環。
重複這個流程，直到達成最佳化目標。
如要進一步瞭解如何最佳化 Google Cloud 環境，請參閱「遷移至 Google Cloud：最佳化環境」和「Google Cloud Well-Architected Framework：效能最佳化」。
建立最佳化需求
請查看下列 Google Cloud環境的最佳化需求，並選擇最適合工作負載的選項：
提高資料庫的可靠性和可用性
有了 Cloud SQL，您就能依據復原時間目標 (RTO) 和復原點目標 (RPO) 制定高可用性和災難復原策略。如要提高可靠性和可用性，請考慮下列事項：
- 如果讀取工作負載繁重，請新增唯讀副本，分流主要執行個體的流量。
- 如果是重要任務工作負載，請使用高可用性設定、區域性容錯移轉副本，以及穩健的災難復原設定。
- 對於較不重要的工作負載，自動和隨選備份可能就足夠。
- 為避免意外移除執行個體，請使用執行個體防刪除功能。
- 建議使用 Cloud SQL Enterprise Plus 版本，享有更高的可用性、記錄保留功能，以及幾乎無須停機的預定維護作業。如要進一步瞭解 Cloud SQL Enterprise Plus，請參閱「Cloud SQL 版本簡介」和「幾乎無須停機的預定維護作業」。
如要進一步瞭解如何提高資料庫的可靠性和可用性，請參閱下列文章：
提高資料庫基礎架構的成本效益
為發揮正面的經濟影響力，工作負載必須有效率地使用可用資源和服務。請考慮採用下列選項：
請按照下列步驟，為資料庫提供最低儲存空間容量：
- 如要隨著資料量成長自動擴充儲存空間容量，請啟用自動增加儲存空間功能。不過，請務必設定執行個體，在尖峰工作負載時保留一些緩衝空間。請注意，資料庫工作負載通常會隨著時間增加。
找出可能高估的資源：
- 調整 Cloud SQL 執行個體的大小，可降低基礎架構成本，且不會增加容量管理策略的風險。
- Cloud Monitoring 提供預先定義的資訊主頁，可協助您瞭解許多 Google Cloud元件 (包括 Cloud SQL) 的健康狀態和容量使用率。詳情請參閱「建立及管理自訂資訊主頁」。
找出不需要高可用性或災難復原設定的執行個體，並從基礎架構中移除。
移除不再需要的資料表和物件。您可以將這些資料儲存在完整備份或封存 Cloud Storage bucket 中。
根據用途評估成本效益最佳的儲存空間類型 (SSD 或 HDD)。
- 在多數使用情境下，SSD 是最有效率且符合成本效益的選擇。
- 如果資料集較大 (10 TB 以上)、對延遲不敏感，或不常存取，則 HDD 可能較合適。
- 詳情請參閱「選擇 SSD 或 HDD 儲存空間」。
如果工作負載的資源需求可預測，請購買承諾使用折扣。
使用 Active Assist 取得成本深入分析和建議。
如需更多資訊和選項，請參閱「事半功倍：運用 Active Assist 推出 Cloud SQL 成本最佳化建議」。
提升資料庫基礎架構的效能
與資料庫相關的小型效能問題，往往可能影響整個作業。如要維持及提升 Cloud SQL 執行個體效能，請考慮下列指南：
- 如果資料庫資料表數量過多，可能會影響執行個體效能和可用性，導致執行個體不適用服務水準協議。
確認執行個體的記憶體或 CPU 沒有受到限制。
- 如果是效能密集型工作負載，請確保執行個體至少有 60 GB 的記憶體。
- 如果資料庫插入、更新或刪除作業速度緩慢，請檢查寫入器和資料庫的位置；長距離傳送資料會導致延遲。
使用 Cloud Monitoring 中預先定義的查詢洞察資訊主頁 (或類似的資料庫引擎內建功能)，提升查詢效能。找出最耗費資源的指令，並嘗試進行最佳化。
避免資料庫檔案過大。請以 MB 為單位設定
autogrow，而非百分比，並根據需求適當調整增量。檢查讀取器和資料庫位置。延遲對讀取效能的影響大於寫入效能。
建議您使用 Cloud SQL Enterprise Plus 版本，享有更高的機器設定限制和資料快取。詳情請參閱「Cloud SQL 版本簡介」。
如要進一步瞭解如何提升效能，請參閱「診斷問題」中的「效能」。
提升資料庫觀測能力
診斷及排解連線至資料庫執行個體的應用程式問題，可能相當困難且耗時。因此，必須有一個集中位置，讓所有團隊成員都能查看資料庫和執行個體層級的活動。您可以透過下列方式監控 Cloud SQL 執行個體：
Cloud SQL 會使用內建的記憶體自訂代理程式，收集查詢遙測資料。
- 使用 Cloud Monitoring 收集服務和所用 Google Cloud資源的測量結果。Cloud Monitoring 包含多項 Google Cloud 產品的預先定義資訊主頁，包括 Cloud SQL 監控資訊主頁。
- 您可以建立自訂資訊主頁，協助監控指標及設定警告政策，以便及時收到通知。
- 或者，您也可以考慮使用與 Google Cloud整合的第三方監控解決方案，例如 Datadog 和 Splunk。
Cloud Logging 會收集常見應用程式元件的記錄資料。
Cloud Trace 會收集應用程式的延遲時間資料和已執行的查詢計畫，協助您追蹤要求在應用程式中的傳播方式。
Database Center 提供 AI 輔助的集中式資料庫機群總覽。您可以監控資料庫的健康狀態、可用性設定、資料保護機制、安全性和產業法規遵循。
Cloud SQL 一般最佳做法和操作指南
採用 Cloud SQL 的最佳做法，設定及調整資料庫。
以下列出幾項重要的 Cloud SQL 一般建議：
- 如果執行個體較大，建議您盡可能將其分割成較小的執行個體。
- 設定儲存空間，以便進行重要的資料庫維護作業。請確保至少有 20% 的可用空間，以便 Cloud SQL 執行任何重要的資料庫維護作業。
- 資料庫資料表過多可能會影響資料庫升級時間。理想情況下，每個執行個體的資料表數量應少於 10,000 個。
- 請為執行個體選擇適當的大小，以考量交易 (二進位) 記錄保留，尤其是寫入活動頻繁的執行個體。
為有效處理可能遇到的任何資料庫效能問題，請按照下列指南操作，直到問題解決為止：
向上擴充基礎架構：增加資源 (例如磁碟處理量、vCPU 和 RAM)。視緊急程度、團隊可用性和經驗而定，垂直擴充執行個體可解決大部分效能問題。之後，您可以在測試環境中進一步調查問題的根本原因，並考慮消除問題的選項。
執行及排定資料庫維護作業：索引資料重組、統計資料更新、vacuum analyze，以及重新建立頻繁更新資料表的索引。檢查上次執行這些維護作業的時間 (如有)，特別是針對受影響的物件 (資料表、索引)。確認資料庫活動是否與平常不同。例如最近新增資料欄，或對資料表進行大量更新。
調整及最佳化資料庫：資料庫中的資料表結構是否正確？資料欄是否具有正確的資料類型？資料模型是否適合工作負載類型？調查查詢速度緩慢的原因和執行計畫。查詢是否使用可用的索引？檢查索引掃描、鎖定和其他資源的等待時間。建議您新增索引，支援重要查詢。排除非關鍵索引和外鍵。建議您重寫複雜的查詢和彙整。解決問題所需的時間取決於團隊的經驗和可用性，可能需要數小時到數天。
水平擴展讀取作業：建議您使用唯讀副本。如果垂直擴充無法滿足需求，且資料庫調整和最佳化措施也無法解決問題，請考慮水平擴充。將應用程式的讀取查詢轉送至唯讀副本，可提升資料庫工作負載的整體效能。不過，您可能需要額外調整應用程式，才能連線至唯讀副本。
重新架構資料庫：考慮對資料庫進行分區和建立索引。這項作業需要投入的心力遠多於資料庫調整和最佳化，且可能涉及資料遷移，但可以做為長期修正。有時，資料模型設計不佳可能會導致效能問題，而垂直向上擴充可部分彌補這類問題。不過，適當的資料模型才是長久之計。建議您將資料表分區。如果可以，請封存不再需要的資料。正規化資料庫結構，但請記住，去正規化也能提升效能。
資料庫 sharding：您可以透過資料庫 sharding 水平擴展寫入作業。資料分割是一項複雜的操作，涉及以特定方式重新架構資料庫和應用程式，以及執行資料遷移。您可以使用特定分區條件，將資料庫執行個體分割成多個較小的執行個體。條件可以根據客戶或主旨設定。這個選項可讓您橫向擴充寫入和讀取作業。不過，這會增加資料庫和應用程式工作負載的複雜度。此外，這也可能導致 shard 不平衡 (稱為熱點)，抵銷 sharding 的好處。- 如果是 MySQL 適用的 Cloud SQL，請確認資料表具有主鍵或不重複索引鍵。Cloud SQL 採用資料列式複製功能，最適合用於含有主鍵或不重複索引鍵的資料表。
詳情請參閱 MySQL 適用的 Cloud SQL 一般最佳做法和作業指南。
後續步驟
- 瞭解其他 AWS 到 Google Cloud 遷移作業。
- 瞭解如何比較 AWS 和 Azure 服務與 Google Cloud。
- 瞭解如何取得遷移作業相關協助。
- 參加 Google Skills 訓練課程，瞭解如何遷移至 Google Cloud。
- 如要查看更多參考架構、圖表和最佳做法，請瀏覽 Cloud Architecture Center。
貢獻者
作者：
- Alex Cârciu | 解決方案架構師
- Marco Ferrari | 雲端解決方案架構師
其他貢獻者：
- Derek Downey | 開發人員關係工程師
- Paweł Krentowski | 技術文件撰稿者
- Matthew Smith | 策略雲端工程師
- Somdyuti Paul | 資料管理專家
- Zach Seils | 網路專員