從 AWS 遷移至 Google Cloud：從 MySQL 適用的 Amazon RDS 和 Amazon Aurora 遷移至 MySQL 適用的 Cloud SQL

Last reviewed 2024-08-16 UTC

Google Cloud 提供工具、產品、指南和專業服務，協助您從 Amazon Relational Database Service (RDS) 或 Amazon Aurora 遷移至 MySQL 適用的 Cloud SQL。

本文適用對象為雲端和資料庫管理員，他們想規劃、實作及驗證資料庫遷移專案。這份文件也適用於評估遷移機會的決策者，他們想瞭解遷移作業可能的樣貌。

本文件著重於同質資料庫遷移，也就是來源和目標資料庫使用相同資料庫技術的遷移作業。在本遷移指南中，來源是 MySQL 適用的 Amazon RDS 或 Amazon Aurora，而目的地是 MySQL 適用的 Cloud SQL。

本文是從 AWS 遷移至Google Cloud 的多部分系列文章之一，其中包含以下文件：

針對這項遷移至 Google Cloud的作業，建議您按照「遷移至 Google Cloud：開始使用」一文所述的遷移架構進行。

以下是遷移流程圖。

列出四個階段的遷移路徑。

您可以透過一系列的迭代作業，從來源環境遷移至 Google Cloud 。舉例來說，您可以先遷移部分工作負載，再遷移其他工作負載。針對每個個別遷移疊代作業，您都必須遵循一般遷移架構的各個階段：

  1. 評估及探索工作負載和資料。
  2. 規劃並建立 Google Cloud基礎。
  3. 將工作負載和資料遷移至 Google Cloud。
  4. 最佳化調整 Google Cloud 環境。

如要進一步瞭解這個架構的各個階段，請參閱「遷移至 Google Cloud：入門指南」。

如要設計有效的遷移計畫，建議您驗證計畫的每個步驟，並確保您有復原策略。如要驗證遷移計畫，請參閱「遷移至 Google Cloud：驗證遷移計畫的最佳做法」。

評估來源環境

在評估階段，您必須確定將來源環境遷移至 Google Cloud時的需求和依附元件。

評估階段是您能否成功遷移的關鍵。您必須深入瞭解要遷移的工作負載、工作負載的要求和依附元件，以及您目前的環境。此外，您還必須知道要從何踏出第一步，以成功規劃並執行 Google Cloud遷移作業。

評估階段包含下列工作：

  1. 建立工作負載的完整清單。
  2. 根據工作負載的屬性和依附元件將其編目。
  3. 訓練並教導您的團隊使用 Google Cloud。
  4. 在 Google Cloud上建立實驗和概念驗證。
  5. 計算目標環境的總持有成本 (TCO)。
  6. 選擇工作負載的遷移策略。
  7. 選擇遷移工具。
  8. 定義遷移計畫和時程。
  9. 驗證遷移計畫。

資料庫評估階段可協助您選擇目標 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 遷移中心，以及其他專門的資料庫評估工具，例如 migVisor 和資料庫遷移評估工具 (DMA)。

您可以使用 Migration Center 對應用程式和資料庫環境進行完整評估，包括資料庫遷移至 Google Cloud的技術適合性。您會收到每個來源資料庫的大小和設定建議，並為伺服器和資料庫建立總持有成本 (TCO) 報告。

如要進一步瞭解如何使用 Migration Center 評估 AWS 環境，請參閱「從其他雲端服務供應商匯入資料」。

除了移轉中心之外，您還可以使用專用工具 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 防火牆規則和 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 環境，完成遷移作業。

規劃和建構階段包含下列工作：

  1. 建立資源階層。
  2. 設定 Google Cloud的 Identity and Access Management (IAM)。
  3. 設定帳單資訊。
  4. 設定網路連線。
  5. 強化安全性。
  6. 設定記錄、監控和快訊功能。

如要進一步瞭解這些任務，請參閱「遷移至 Google Cloud：規劃並建立基礎」一文。

如果您打算使用資料庫移轉服務進行遷移，請參閱「MySQL 適用的網路方法」，瞭解遷移情境可用的網路設定。

監控和警示

使用 Google Cloud Monitoring，其中包含多項 Google Cloud 產品的預先定義資訊主頁，包括 Cloud SQL 監控資訊主頁。或者，您也可以考慮使用與Google Cloud整合的第三方監控解決方案，例如 Datadog 和 Splunk。詳情請參閱「關於資料庫可觀察性」。

將 Amazon RDS 和 Amazon Aurora for MySQL 執行個體遷移至 MySQL 適用的 Cloud SQL

如要遷移執行個體，請按照下列步驟操作：

  1. 選擇遷移策略：持續複製或定期維護。

  2. 請根據所選策略和需求選擇遷移工具。

  3. 定義每個資料庫遷移作業的遷移計畫和時間表，包括準備和執行工作。

  4. 定義必須完成的準備工作，確保遷移工具能正常運作。

  5. 定義執行作業，包括實作遷移作業的工作活動。

  6. 定義每項執行作業的備用方案。

  7. 執行測試和驗證，這項作業可以在個別的測試環境中完成。

  8. 執行遷移作業。

  9. 執行正式版切換作業。

  10. 清理來源環境並設定目標執行個體。

  11. 進行調整和最佳化。

我們將在下列各節中說明各個階段。

選擇遷移策略

在這個步驟中，您已取得足夠的資訊，可評估並選取下列最適合每個資料庫用途的遷移策略：

  • 定期維護 (也稱為一次性遷移或大爆炸遷移)：如果您可以承受停機時間，這會是理想的做法。這個選項的成本和複雜度相對較低，因為工作負載和服務不需要太多重構。不過，如果遷移作業在完成前失敗，您就必須重新啟動程序，導致停機時間延長。

  • 持續複製 (也稱為線上遷移或涓滴式遷移)：對於任務關鍵資料庫，這個選項可降低資料遺失風險，並將停機時間降到最低。這些工作會拆分成多個區塊，因此如果發生失敗，復原和重複作業所需的時間就會縮短。不過，設定程序較為複雜，需要更多規劃和時間。您還必須額外進行重構，才能連結至資料庫執行個體的應用程式。請考慮下列任一變化版本：

    • 使用「Y (寫入及讀取)」方法，這是一種平行遷移形式，可在遷移期間複製來源和目的地執行個體中的資料。
    • 使用資料存取微服務，可減少 Y (寫入及讀取) 方法所需的重構工作量。

如要進一步瞭解資料遷移策略，請參閱「評估資料遷移方法」。

下圖顯示流程圖，其中列出決定單一資料庫遷移策略時可能會遇到的問題：

流程圖可協助您選擇遷移策略。

上圖的流程圖顯示以下決策點：

  • 您能承受任何服務中斷時間嗎？

    • 如果沒有，請採用持續複製遷移策略。
    • 如果是，請繼續前往下一個決策點。

  • 您是否能承受遷移資料時的轉換空窗期停機時間？轉換期間是指備份資料庫、將備份轉移至 Cloud SQL、還原備份，然後切換應用程式所需的時間。

    • 如果沒有，請採用持續複製遷移策略。
    • 如果是，請採用預定維護遷移策略。

即使資料庫位於相同執行個體，策略也可能有所不同。搭配使用多種策略，就能獲得最佳成效。舉例來說，您可以使用排程維護方法遷移小型和不常使用的資料庫，但對於停機成本高昂的重要業務資料庫，則使用持續複製功能。

通常，當初始來源執行個體和目標執行個體之間的切換完成時，系統就會視為遷移作業已完成。系統會停止任何複製作業 (如果有)，並在目標執行個體上執行所有讀取和寫入作業。在兩個例項同步時切換，可避免資料遺失，並縮短停機時間。

如要進一步瞭解資料遷移策略和部署作業，請參閱「資料庫遷移作業分類」。

如要避免應用程式停機，遷移設定必須更複雜。在設定複雜度和在人流較少的營業時間安排停機時間之間取得平衡。

每種遷移策略都有取捨，且與遷移程序相關的影響。舉例來說，複製程序會對來源執行個體造成額外負載，而您的應用程式可能會受到複製延遲影響。應用程式 (和客戶) 可能必須在應用程式停機期間等待，至少要等到複製延遲時間結束後，才能使用新資料庫。在實際情況中，下列因素可能會導致停機時間增加：

  • 資料庫查詢可能需要幾秒鐘才能完成。在遷移期間，進行中的查詢可能會中止。
  • 如果資料庫很大或有大量緩衝記憶體，快取可能需要一些時間才能填滿。
  • 在來源中停止的應用程式，如果在 Google Cloud中重新啟動，可能會出現輕微的延遲，直到建立與 Google Cloud資料庫執行個體的連線為止。
  • 必須重新導向應用程式的網路路徑。視 DNS 項目的設定方式而定，這可能需要一些時間。更新 DNS 記錄時，請在遷移前降低 TTL。

下列常見做法有助於將停機時間和影響降到最低：

  • 找出停機期間對工作負載影響最小的時間。例如在非一般上班時間、週末或其他預定的維護期間。
  • 找出可在不同階段進行遷移和正式作業切換的工作負載部分。您的應用程式可能含有不同的元件，可在不影響應用程式運作情況的情況下，進行隔離、調整和遷移。例如前端、客戶關係管理模組、後端服務和報表平台。這類模組可能會有自己的資料庫，可在過程中提早或延後排定遷移作業。
  • 如果您可以接受目標資料庫的延遲情形，請考慮逐步遷移。使用增量批次資料移轉，並調整部分工作負載，以便使用目標執行個體上的舊資料。
  • 建議您重構應用程式，以便支援最少的遷移影響。舉例來說，您可以調整應用程式，讓應用程式同時寫入來源和目標資料庫，進而實作應用程式層級的複製作業。

選擇遷移工具

選擇合適的遷移工具，是遷移能否成功的關鍵因素。決定遷移策略後，請查看並決定遷移工具。

我們提供許多工具，每個工具都針對特定遷移用途進行最佳化。用途包括：

  • 遷移策略 (排程維護或持續複製)。
  • 來源和目標資料庫引擎以及引擎版本。
  • 來源執行個體和目標執行個體所在的環境。
  • 資料庫大小。資料庫越大，遷移初始備份所需的時間就越長。
  • 資料庫變更的頻率。
  • 是否可使用代管服務進行遷移。

為確保無縫遷移和切換，您可以使用應用程式部署模式、基礎架構協調作業，以及自訂遷移應用程式。不過，專門的工具 (稱為受管理的遷移服務) 可協助您將資料、應用程式，甚至整個基礎架構從一個環境移至另一個環境。這些作業會從來源資料庫執行資料擷取作業，並將資料安全地傳輸至目標資料庫，並可選擇在傳輸期間修改資料。這些功能可封裝遷移作業的複雜邏輯，並提供遷移監控功能。

代管遷移服務具備下列優勢：

  • 將停機時間減至最低：服務會在可用時使用資料庫引擎內建的複寫功能，並執行副本升級作業。

  • 確保資料完整性和安全性：從來源安全可靠地將資料傳輸至目的地資料庫。

  • 提供一致的遷移體驗：您可以使用資料庫遷移可執行檔，將不同的遷移技術和模式整合為一致的通用介面，並進行管理和監控。

  • 提供可靠且經過驗證的遷移模型：資料庫遷移是重要的事件，但發生的頻率不高。為了避免初學者犯錯，以及現有解決方案的問題，您可以使用經驗豐富的專家提供的工具，而非自行建構解決方案。

  • 降低成本：相較於為自訂遷移解決方案配置額外的伺服器和資源，代管遷移服務更具成本效益。

接下來幾節將說明遷移工具建議，這取決於所選的遷移策略。

排定維護遷移作業的工具

下圖為流程圖，其中包含可協助您選擇單一資料庫遷移工具的問題，適用於使用排程維護遷移策略的情況：

流程圖可協助您選擇用於排定維護遷移作業的工具。

上圖的流程圖顯示以下決策點：

  • 您是否偏好代管遷移服務？
    • 如果是，建議您使用資料庫移轉服務。
    • 如果沒有，建議您使用資料庫引擎內建的備份來進行遷移。

使用代管遷移服務可享有許多優勢，詳情請參閱本文的「選擇遷移工具」一節。

以下各節將說明可用於一次性遷移作業的工具，以及這些工具的限制和最佳做法。

使用資料庫移轉服務進行預定維護作業的遷移作業

資料庫移轉服務會管理初始同步處理和持續變更資料擷取 (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 值區做為目標。

如需詳細資訊和步驟，請參閱「使用代管匯入功能來設定從外部資料庫的複製作業」。

持續複製遷移工具

下圖顯示流程圖，其中包含可協助您選擇單一資料庫遷移工具的問題，適用於使用持續複製遷移策略的情況：

流程圖可協助您選擇用於持續複製遷移作業的工具。

上圖的流程圖顯示以下決策點：

  • 您是否偏好使用代管遷移服務？

    • 如果是的話，您可以接受寫入作業的停機時間為幾秒嗎？這取決於資料庫中的資料表數量。

      • 如果是，請使用資料庫移轉服務。
      • 如果沒有，請探索其他遷移選項。

    • 如果沒有，您必須評估資料庫引擎是否支援內建複寫功能：

      • 如果是的話，建議您使用內建複寫功能。
      • 如果不是，建議您嘗試其他遷移選項。

以下各節將說明可用於持續遷移的工具，以及這些工具的限制和最佳做法。

資料庫移轉服務：持續複製遷移

資料庫遷移服務會使用持續遷移工作類型，為持續遷移作業提供流暢支援。只有持續遷移工作可以升級，這會通知系統停止複製。

如果您選擇使用這項工具，請考量下列限制和最佳做法：

  • 避免在遷移期間執行長時間的交易。在這種情況下，如果您不是從 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 伺服器的防火牆，允許為 Cloud SQL 複本用於私人網路的虛擬私人雲端網路，分配內部 IP 範圍。詳情請參閱「從外部伺服器複製資料」和「設定私人服務存取權」。

限制：

  • 如果資料庫中只有單一大型資料表和許多次要索引，初始完整傾印作業可能會耗費較長的時間。
  • 如果外部伺服器包含 DEFINER 子句 (檢視畫面、事件、觸發事件或儲存程序)，則視執行這些陳述式的順序而定，複製作業可能會失敗。進一步瞭解 DEFINER 在 Cloud SQL 中的用途和可能的解決方法。
  • InnoDB 是 Cloud SQL 唯一支援的資料庫引擎。遷移 MyISAM 可能會導致資料不一致，並需要進行資料驗證。請參閱「將資料表從 MyISAM 轉換為 InnoDB」。

持續複製遷移作業的其他方法

其他持續複製遷移方法包括：

  • 重構應用程式，以執行 Y (寫入及讀取) 或使用資料存取微服務。

    • 您的應用程式會執行持續複製作業。
    • 遷移作業的重點是重構或開發可連線至資料庫執行個體的工具。
    • 接著，讀取器應用程式會逐步重構並部署，以便使用目標執行個體。

  • 使用 Datastream，近乎即時複製 MySQL 執行個體的變更。

    • Datastream 是一項無伺服器 CDC 和複製服務，可搭配 Amazon RDS 或 Amazon Aurora 使用，用於複製及同步處理資料。
    • 使用 Datastream 將 MySQL 執行個體的變更複製到 BigQuery 或 Cloud Storage，然後使用 Dataflow 或 Dataproc 將資料帶入 Cloud SQL 執行個體。

如要進一步瞭解如何使用 Datastream 進行複製，請參閱以下文章：

用於持續複製遷移作業的第三方工具

在某些情況下，針對多數資料庫引擎，使用單一第三方工具可能會比較好。例如，如果您偏好使用受管理的遷移服務，且需要確保目標資料庫隨時與來源進行近乎即時的同步，或是需要在遷移過程中進行更複雜的轉換作業，例如資料清理、重構和調整，就可能會遇到這種情況。

如果您決定使用第三方工具，請選擇下列任一推薦工具，適用於大多數資料庫引擎。

Striim 是端對端的記憶體內平台，可即時收集、篩選、轉換、強化、匯總、分析及提交資料：

  • 優點：

    • 可處理大量資料和複雜的遷移作業。
    • SQL Server 內建變更資料擷取功能。
    • 預先設定的連線範本和無程式碼管道。
    • 能夠處理在大量交易負載下運作的關鍵任務大型資料庫。
    • 僅傳送一次。

  • 缺點：

如要進一步瞭解 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 執行個體已設為在 VPC 中為私人，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 欄皆可為空值。任何 LOB 欄如果是 NOT NULL，在遷移期間就必須移除該限制。

  • 在實際工作環境中，對來源環境進行基準測量。請考量下列事項：

    • 評估資料大小和工作負載效能。重要查詢或交易的平均處理時間為何？在尖峰時段的時間長度為何？
    • 記錄基準測量值以便日後比較，協助您判斷資料庫遷移的準確度是否令人滿意。決定是否要切換正式工作負載並停用來源環境，或是仍需要做為備援用途。

Cloud SQL 設定

請仔細選擇目標 Cloud SQL for MySQL 資料庫執行個體的大小和規格，以便與來源相符，滿足類似的效能需求。請特別留意磁碟大小和總處理量、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 傾印檔案匯入 Cloud SQL，可能需要建立 Cloud Storage 值區。這個儲存格會儲存資料庫傾印。

如果您使用複製功能，請務必確保 Cloud SQL 備用資源可存取主要資料庫。您可以透過已記錄的連線選項取得這項存取權。

視情境和重要性而定，您可能需要實作備用方案情境，通常包括反轉複製方向。在這種情況下，您可能需要額外的複寫機制，將 Cloud SQL 資料回傳至來源 Amazon 執行個體。

對於大多數第三方工具，您需要設定遷移專屬資源。舉例來說，如要使用 Striim，您必須先透過 Google Cloud Marketplace 開始。接著，您可以使用流程設計工具建立及變更應用程式，或是選取現有的範本，在 Striim 中設定遷移環境。您也可以使用 Tungsten 查詢語言 (TQL) 程式設計語言編寫應用程式。您可以使用資料驗證資訊主頁，以視覺化方式呈現 Striim 應用程式處理的資料。

遷移完成並經過驗證後，您可以停用連結 Amazon 和Google Cloud 環境的資源。

如要瞭解詳情，請參考下列資源：

定義執行工作

執行工作會實作遷移作業本身。工作量取決於您選擇的遷移工具，如以下各節所述。

內建資料庫引擎備份

如要執行一次性遷移作業，請使用 mysqldump 公用程式建立備份，將資料從 Amazon RDS 複製到本機用戶端電腦。如需操作說明，請參閱「將 SQL 傾印檔案匯入 Cloud SQL for MySQL」。

您可以查看 Cloud SQL 執行個體的匯入和匯出作業狀態。

資料庫遷移服務遷移工作

在資料庫移轉服務中定義及設定遷移工作，以便將資料從來源執行個體遷移至目的地資料庫。遷移工作會透過使用者定義的連線設定檔連線至來源資料庫執行個體。

測試所有必要條件，確保工作能順利執行。請選擇工作負載可承受遷移和正式版切換作業的短暫服務中斷時間。

在資料庫移轉服務中，遷移作業會從初始完整備份和載入作業開始，接著從來源持續將變更傳送至目的地資料庫執行個體。

資料庫遷移服務需要幾秒鐘的時間，才能取得來源 Amazon RDS 或 Amazon Aurora 執行個體中所有資料表的讀取鎖定，以便以一致的方式執行初始完整傾印作業。為了達到讀取鎖定，可能需要 1 到 49 秒的寫入停機時間。停機時間取決於資料庫中的資料表數量，1 秒對應 100 個資料表，9 秒對應 10000 個資料表。

使用資料庫移轉服務的遷移程序會在升級作業結束後結束。升級資料庫執行個體後，目的地資料庫就會與來源資料庫的變更流程中斷連，而現在獨立的目的地執行個體會升級為主要執行個體。這種做法有時也稱為正式環境切換。

如要進一步瞭解資料庫遷移服務中的遷移工作，請參閱下列文章：

如需遷移設定程序的詳細資訊，請參閱「使用資料庫移轉服務將資料庫遷移至 MySQL 適用的 Cloud SQL」。在資料庫移轉服務中，您可以透過啟動及執行遷移工作來執行遷移作業。

資料庫引擎內建複製功能

您可以使用內建的複寫功能，將資料從 Amazon RDS 複製到外部的 MySQL 適用 Cloud SQL 執行個體。

針對 MySQL，您必須先從可儲存在 Cloud Storage 值區中的初始轉儲作業開始，然後將資料匯入 MySQL 適用的 Cloud SQL。然後啟動複製程序。

監控複製作業，並在適當時間停止來源執行個體的寫入作業。再次檢查複製狀態，確認所有變更都已複製，然後將 Cloud SQL for MySQL 備用資源推送至獨立執行個體，完成遷移作業。

如需有關如何從外部伺服器 (例如 Amazon RDS 或 Amazon Aurora for MySQL) 設定內建備份的詳細操作說明，請參閱「從外部伺服器複製資料」和「設定 Cloud SQL 和外部伺服器以進行備份」。

如需更多資訊和指南，請參閱以下內容：

第三方工具

為所選第三方工具定義任何執行作業。

本節將以 Striim 為例說明。Striim 會使用從各種來源擷取資料、處理資料，然後將資料傳送至其他應用程式或目標的應用程式。

您可以使用網頁用戶端以圖形方式建立應用程式，這些應用程式包含來源、目標和其他邏輯元件，並且會整理成一個或多個流程。

如要在 Striim 中設定遷移環境，您可以使用 Flow Designer 功能建立及變更應用程式，也可以從多個現有範本中選取。您也可以使用 TQL 程式設計語言編寫應用程式。

您可以使用資料驗證資訊主頁，以圖像方式呈現 Striim 應用程式處理的資料。

如要快速開始在 Google Cloud中使用 Striim，請參閱「在 Google Cloud中執行 Striim」。如要進一步瞭解 Striim 的基本概念，請參閱「Striim 概念」。請務必參閱從初始載入切換為持續複寫的最佳做法指南。

請考慮採用下列資料移轉最佳做法：

  • 每當各個企劃步驟開始和結束時，請通知相關團隊。
  • 如果任何步驟的執行時間比預期長，請將經過的時間與為每個步驟分配的最大時間進行比較。發生這種情況時，請定期向相關團隊發布中繼更新。
  • 如果時間跨距超過計畫中每個步驟預留的時間上限，請考慮回溯。
  • 針對遷移和切換計畫的每個步驟做出「執行或不執行」的決定。
  • 請考慮每個步驟的復原動作或替代方案。

定義備用方案

為每項遷移執行作業定義備用動作項目，以防範遷移過程中可能發生的意外問題。備用工作通常取決於所使用的遷移策略和工具。

備用方案可能需要大量心力。最佳做法是，在測試結果令人滿意之前，不要執行正式版切換作業。您應妥善測試資料庫遷移和備用方案，以免發生嚴重服務中斷。

定義成功標準，並為所有遷移執行工作設定時間限制。進行遷移模擬作業有助於收集各項工作預估時間的相關資訊。舉例來說，如果是定期維護遷移作業，您可以承受轉換空窗期所代表的停機時間。不過，如果一次性遷移工作或備份還原作業在執行過程中失敗，請務必規劃後續行動。視所經過的預定停機時間長短而定，如果遷移工作未在預期時間內完成，您可能必須延後遷移作業。

備用方案通常是指在執行正式版切換後，如果目標執行個體出現問題，則回復遷移作業。如果您要實作備用計畫，請務必將其視為完整資料庫遷移作業，包括規劃和測試。

如果您選擇不採用備用方案，請務必瞭解可能的後果。沒有備用計畫可能會增加意外的努力，並導致遷移程序中發生不必要的中斷。

雖然備用方案是萬不得已的做法，而且大多數資料庫遷移作業不會使用備用方案，但我們建議您一律採用備用方案策略。

簡易備用

在這個備用策略中，您會將應用程式切換回原始來源資料庫例項。如果您可以接受在備援時發生停機情形，或是不需要在新的目標系統上提交交易，請採用這項策略。

如果您確實需要目標資料庫上的所有寫入資料，且可以接受部分停機時間，建議您考慮停止寫入目標資料庫執行個體，並在來源執行個體上執行內建備份和還原作業，然後將應用程式重新連結至初始來源資料庫執行個體。視工作負載的性質和目標資料庫執行個體上所寫入的資料量而定，您可以稍後將資料帶入初始來源資料庫系統，尤其是在工作負載不依賴任何特定記錄建立時間或任何時間排序限制的情況下。

反向複製作業

在這個策略中，您會在實際工作環境切換回最初的來源資料庫後，複製新目標資料庫上的寫入作業。這樣一來，您就能讓原始來源與新的目標資料庫保持同步，並在新的目標資料庫執行個體上進行寫入作業。主要缺點是，您必須先切換至目標資料庫執行個體，才能測試複製串流，因此無法進行端對端測試，且沒有備援機制。

如果您可以保留來源執行個體一段時間，並使用持續複製遷移功能進行遷移，請選擇這種方法。

前向複製

這項策略是反向複製的變化版本。您可以將新目標資料庫的寫入作業複製到所選的第三方資料庫執行個體。您可以將應用程式指向這個第三個資料庫，讓應用程式連線至伺服器，並在伺服器無法使用時執行唯讀查詢。您可以視需求使用任何複製機制。這種方法的好處是可以進行完整的端對端測試。

如要隨時使用備用方案，或是在正式版切換後不久就必須捨棄初始來源資料庫，請採用這種做法。

重複寫入

如果您選擇 Y (寫入及讀取) 或資料存取微服務遷移策略，系統就會設定這個備用方案。這項策略較為複雜，因為您需要重構應用程式或開發可連結至資料庫執行個體的工具。

應用程式會同時寫入初始來源和目標資料庫例項，讓您逐步執行正式版切換作業，直到只使用目標資料庫例項為止。如果發生任何問題，您可以將應用程式重新連線至初始來源，而不會造成任何停機時間。如果您認為遷移作業已完成且沒有任何問題，可以捨棄初始來源和重複寫入機制。

如果您必須確保沒有遷移停機時間、有可靠的備用方案，且有時間和資源執行應用程式重構，建議您採用這種方法。

進行測試和驗證

本步驟的目標是測試及驗證下列項目：

  • 資料庫中的資料已成功遷移。
  • 在現有應用程式切換為使用新的目標例項後，與這些應用程式整合。

定義關鍵成功因素，這取決於您的遷移作業。以下是主觀因素的範例：

  • 要遷移哪些資料。對於某些工作負載，您可能不需要遷移所有資料。您可能不想遷移已匯總、備份、封存或過時的資料。您可以將這些資料存檔在 Cloud Storage 值區中，做為備份。
  • 可接受的資料遺失百分比。這項做法特別適用於用於數據分析工作負載的資料，因為在這種情況下，部分資料遺失不會影響工作負載的整體趨勢或效能。
  • 資料品質和數量標準，您可以套用至來源環境，並在遷移後與目標環境進行比較。
  • 成效條件。部分商務交易在目標環境中可能會變慢，但處理時間仍在預期範圍內。

來源環境中的儲存空間設定可能無法直接對應至Google Cloud 環境目標。舉例來說，一般用途 SSD (gp2 和 gp3) 磁碟區的設定，可搭配 IOPS 爆發效能或已配置 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：開放原始碼資料庫測試架構，支援以測試為導向的程式碼開發和自動化測試。它使用基本語法建立測試案例，並提供資料導向測試、版本控制和測試結果回報功能。不過，與其他工具相比，它對複雜查詢和交易的支援有限，且沒有廣泛的社群支援或詳細的說明文件。如果查詢不複雜，且您想執行自動化測試並將其整合至持續整合和提交程序，建議您使用這項工具。

如要執行端對端測試 (包括遷移計畫的測試)，請務必執行遷移模擬演練。模擬執行可在不切換任何正式工作負載的情況下，執行全範圍資料庫遷移作業，並提供下列優點：

  • 可讓您確保所有物件和設定都已正確遷移。
  • 協助您定義及執行遷移測試案例。
  • 提供實際遷移作業所需時間的洞察資料，方便您調整時程。
  • 代表測試、驗證及調整遷移計畫的機會。有時您無法事先規劃所有內容，因此這項功能有助於找出任何缺口。

您可以對要遷移的少數資料庫或整個資料庫執行資料測試。視資料庫總數和用於實施遷移作業的工具而定，您可以決定採用以風險為準的做法。使用這種方法時，您會針對透過相同工具遷移的資料庫子集執行資料驗證，尤其是當這項工具是受管理的遷移服務時。

為了進行測試，您必須同時存取來源和目標資料庫，並執行下列工作：

  • 比較來源和目標結構定義。檢查是否存在所有資料表和可執行檔。檢查資料列數並比較資料庫層級的資料。
  • 執行自訂資料驗證指令碼。
  • 測試遷移的資料是否也能在已切換為使用目標資料庫的應用程式中顯示 (遷移的資料會透過應用程式讀取)。
  • 測試各種用途，以便在切換的應用程式和目標資料庫之間執行整合測試。這項測試包括透過應用程式讀取資料，並將資料寫入目標資料庫，以便工作負載能同時支援已遷移的資料和新建資料。
  • 測試最常使用的資料庫查詢效能，觀察是否因設定錯誤或大小不正確而導致效能降低。

理想情況下，所有遷移測試情境都會自動化，且可在任何來源系統上重複執行。自動化測試案例套件會調整，以便針對已切換的應用程式執行。

如果您使用資料庫移轉服務做為遷移工具，請參閱「驗證遷移作業」。

資料驗證工具

如要驗證資料，建議您使用資料驗證工具 (DVT)。DVT 是 Google 支援的開放原始碼 Python CLI 工具，可提供自動化且可重複執行的解決方案，在不同環境中進行驗證。

DVT 可提供自訂的多層級驗證函式，在資料表、資料欄和資料列層級比較來源和目標資料表，協助簡化資料驗證程序。您也可以新增驗證規則。

DVT 涵蓋許多 Google Cloud 資料來源，包括 PostgreSQL 適用的 AlloyDB、BigQuery、Cloud SQL、Spanner、JSON 和 Cloud Storage 上的 CSV 檔案。也可以與 Cloud Run 函式和 Cloud Run 整合，以便根據事件觸發和調度。

DVT 支援下列驗證類型：

  • 結構定義層級比較
  • 資料欄 (包括「AVG」、「COUNT」、「SUM」、「MIN」、「MAX」、「GROUP BY」和「STRING_AGG」)
  • 資料列 (包括欄位比較中的雜湊和完全比對)
  • 自訂查詢結果比較

如要進一步瞭解 DVT，請參閱 Git 存放區和「使用 Google Cloud的資料驗證工具，輕鬆完成資料驗證」一文。

執行遷移作業

遷移工作包括支援從一個系統轉移到另一個系統的活動。

請考慮採用下列資料移轉最佳做法：

  • 每當計畫步驟開始和結束時，請通知相關團隊。
  • 如果任何步驟的執行時間比預期長，請將經過的時間與該步驟的時間上限進行比較。發生這種情況時，請定期向相關團隊發布中繼更新。
  • 如果時間跨距超過計畫中每個步驟預留的時間上限，請考慮回溯。
  • 針對遷移和切換計畫的每個步驟做出「執行或不執行」的決定。
  • 請考慮每個步驟的復原動作或替代方案。

按照定義的執行工作執行遷移作業，並參閱所選遷移工具的說明文件。

執行正式版切換作業

實際的正式版切換程序可能會因所選遷移策略而異。如果您可以讓工作負載暫時停止運作，請先停止寫入來源資料庫，然後開始遷移作業。

對於持續複製遷移作業，您通常會在切換程序中執行下列高階步驟：

  • 停止將資料寫入來源資料庫。
  • 耗盡來源。
  • 停止複製作業。
  • 部署指向新目標資料庫的應用程式。

使用所選遷移工具遷移資料後，您可以驗證目標資料庫中的資料。您確認來源資料庫和目標資料庫已同步，且目標執行個體中的資料符合所選遷移成功標準。

資料驗證通過您的條件後，您就可以執行應用程式層級的轉換作業。部署已重構的工作負載，以便使用新的目標執行個體。您會部署指向新目標資料庫執行個體的應用程式版本。部署作業可以透過滾動式更新、階段性發布，或使用藍綠部署模式執行。應用程式可能會發生部分服務中斷的情況。

請遵循實際工作環境切換的最佳做法：

  • 在切換後，監控與目標資料庫搭配運作的應用程式。
  • 定義監控時間範圍，以便評估是否需要導入備用方案。
  • 請注意，如果您變更某些資料庫旗標，Cloud SQL 或 AlloyDB for PostgreSQL 執行個體可能需要重新啟動。
  • 請考量回溯遷移的作業量，可能會比修正目標環境中出現的問題還要大。

清理來源環境，並設定 Cloud SQL 或 AlloyDB for PostgreSQL 執行個體

切換完成後，您可以刪除來源資料庫。建議您在清理來源執行個體前，執行下列重要動作：

  • 為每個來源資料庫建立最終備份。這些備份可提供來源資料庫的最終狀態。在某些情況下，備份資料也可能需要遵守某些資料法規。

  • 收集來源執行個體的資料庫參數設定。或者，請檢查這些資料是否與您在建立商品目錄階段收集到的資料相符。調整目標例項參數，使其與來源例項的參數相符。

  • 從來源執行個體收集資料庫統計資料，並與目標執行個體中的資料進行比較。如果統計資料不一致，就很難比較來源例項和目標例項的成效。

在備援情況下，您可能需要將 Cloud SQL 執行個體上的寫入作業複製回原始來源資料庫。設定方式與遷移程序類似，但會以相反方向執行：初始來源資料庫會成為新的目標。

為了在切換後讓來源執行個體保持最新狀態，建議您將在目標 Cloud SQL 執行個體上執行的寫入作業複製回來源資料庫。如果需要回溯，您可以回復至舊的來源執行個體，盡量減少資料損失。

除了來源環境清理作業之外，您還必須為 Cloud SQL 執行個體設定下列重要設定：

  • 設定主要執行個體的維護期間，以便控制發生中斷型更新的時間。
  • 請在執行個體上設定儲存空間，確保至少有 20% 的可用空間，以便 Cloud SQL 執行任何重要的資料庫維護作業。如要接收可用磁碟空間低於 20% 的警報，請為磁碟使用率指標建立以指標為基礎的警報政策。

前一項作業完成之前，請勿開始進行管理作業。

如要進一步瞭解維護作業和最佳做法，請參閱「Cloud SQL 執行個體維護作業」。

遷移後將環境調整至最佳狀態

最佳化是遷移作業的最後階段。在這個階段，您會重複執行最佳化工作，直到目標環境符合您的最佳化需求為止。每個疊代步驟如下：

  1. 評估目前的環境、團隊和最佳化循環。
  2. 建立最佳化需求和目標。
  3. 改善環境和團隊。
  4. 調整最佳化循環。

您可以重複執行這個程序，直到達成最佳化目標為止。

如要進一步瞭解如何最佳化 Google Cloud 環境，請參閱「遷移至 Google Cloud：最佳化環境」和「Google Cloud 架構良好的架構：效能最佳化」。

建立最佳化要求

請查看下列環境的最佳化需求，並選擇最符合工作負載需求的項目： Google Cloud

提高資料庫的可靠性和可用性

您可以使用 Cloud SQL 實施高可用性和災難復原策略，並依據復原時間目標 (RTO) 和復原點目標 (RPO) 進行調整。如要提高可靠性和可用性，請考慮下列事項：

  • 如果是需要讀取大量資料的工作負載，請新增唯讀備用資源，以分擔主要執行個體的流量。
  • 針對任務關鍵工作負載，請使用高可用性設定、區域容錯移轉複本，以及完善的災難復原設定。
  • 對於較不重要的工作負載，自動及隨選備份就足夠了。
  • 如要避免意外移除執行個體，請使用執行個體刪除保護功能。
  • 建議您使用 Cloud SQL Enterprise Plus 版本，享有更高可用性、記錄保留時間和幾乎無停機時間的預定維護服務。如要進一步瞭解 Cloud SQL Enterprise Plus，請參閱「Cloud SQL 版本簡介」和「幾乎不停機的預定維護作業」。

如要進一步瞭解如何提高資料庫的可靠性和可用性，請參閱下列文章：

提高資料庫基礎架構的成本效益

為了發揮正面的經濟效益，工作負載必須有效運用可用的資源和服務。請考慮採用下列選項：

  • 請按照下列步驟，為資料庫提供必要的最低儲存空間容量：

    • 如要隨著資料量成長自動調整儲存空間容量，請啟用自動增加儲存空間功能。不過，請務必將執行個體設定為在尖峰工作負載時保留一些緩衝空間。請注意，資料庫工作負載通常會隨著時間增加。

  • 找出可能高估的資源：

    • 調整 Cloud SQL 執行個體的大小，可以降低基礎架構成本，且不會對容量管理策略增加額外風險。
    • Cloud Monitoring 提供預先定義的資訊主頁，可協助您瞭解許多元件 (包括 Cloud SQL) 的健康狀態和容量利用率。 Google Cloud詳情請參閱「建立及管理自訂資訊主頁」。

  • 找出不需要高可用性或災難復原設定的執行個體，並從基礎架構中移除。

  • 移除不再需要的資料表和物件。您可以將這些檔案儲存在完整備份或 Cloud Storage 封存值區中。

  • 根據用途評估最具成本效益的儲存空間類型 (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)。視緊急程度和團隊可用資源和經驗而定，垂直擴充執行個體可以解決大部分的效能問題。之後，您可以在測試環境中進一步調查問題的根本原因，並考慮如何解決問題。

執行及排程資料庫維護作業：索引去碎片化、統計資料更新、真空分析，以及重新為經常更新的資料表建立索引。請確認上次執行這些維護作業的時間，尤其是針對受影響的物件 (表格、索引)。找出是否有任何異常的資料庫活動。例如最近新增資料欄或資料表有大量更新。

調整及最佳化資料庫：資料庫中的表格是否有正確的結構？資料欄是否使用正確的資料類型？您的資料模型是否適合工作負載類型？請調查查詢速度緩慢的情況，以及查詢執行計畫。這些查詢是否使用了可用的索引？檢查索引掃描、鎖定和等待其他資源。建議您新增索引，以支援重要的查詢。移除非必要的索引和外來鍵。建議您重寫複雜的查詢和彙整。解決問題所需的時間取決於團隊的經驗和可用性，可能需要數小時到數天不等。

擴充讀取作業：考慮使用唯讀備用資源。如果垂直調度無法滿足需求，且資料庫調整和最佳化措施也無法解決問題，請考慮水平調度。將應用程式的讀取查詢重新導向至讀取備援資料庫，可改善資料庫工作負載的整體效能。不過，您可能需要額外調整應用程式，才能連線至讀取/寫入複本。

資料庫重構架構：考慮為資料庫建立分割區和索引。這項作業需要比資料庫調整和最佳化更費心力，且可能涉及資料遷移，但可以是長期的修正方式。有時，資料模型設計不佳可能會導致效能問題，這類問題可透過垂直向上擴充來部分補救。不過，採用適當的資料模型是長期解決問題的方法。建議您分割資料表。盡可能封存不再需要的資料。請將資料庫結構正規化，但請注意，非正規化也能提升效能。

資料庫區塊：您可以透過資料庫區塊來擴大寫入作業。資料分割是一項複雜的作業，需要以特定方式重新架構資料庫和應用程式，並執行資料遷移作業。您可以使用特定的分區準則，將資料庫執行個體分割成多個較小的執行個體。條件可以是顧客或主題。這個選項可讓您水平調整寫入和讀取作業。不過，這會增加資料庫和應用程式工作負載的複雜度。這也可能導致不平衡的分片 (稱為熱點)，而這會抵銷分片帶來的好處。- 針對 MySQL 適用的 Cloud SQL，請確認資料表具有主索引鍵或不重複的索引鍵。Cloud SQL 使用列式複製，搭配具有主索引鍵或不重複索引鍵的資料表時，運作效果最佳。

詳情請參閱 Cloud SQL for MySQL 的一般最佳做法和操作指南。

後續步驟

貢獻者

作者：

其他貢獻者：