從 AWS 遷移至 Google Cloud：從 Amazon RDS 和 Amazon Aurora for PostgreSQL 遷移至 Cloud SQL 和 AlloyDB for PostgreSQL

Last reviewed 2024-09-12 UTC

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

本文適用於雲端和資料庫管理員，協助他們規劃、實作及驗證資料庫遷移專案。此外，這份指南也適合評估遷移機會的決策人員，可做為遷移作業的範例。

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

本文是從 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，以及 PostgreSQL 適用的 Cloud SQL 或 PostgreSQL 適用的 AlloyDB，可能沒有類似的功能、執行個體規格或作業。部分功能可能以不同方式實作，或無法使用。差異可能包括基礎架構、儲存空間、驗證和安全性、複製、備份、高可用性、資源容量模型，以及特定資料庫引擎功能整合和擴充功能。資料庫參數設定的預設值也會因資料庫引擎類型、執行個體大小和架構而異。

基準化有助於您進一步瞭解要遷移的工作負載，並定義遷移目標環境的合適架構。收集效能相關資訊有助於估算 Google Cloud 目標環境的效能需求。基準化概念和工具詳見「執行遷移程序的測試和驗證」，但這些概念和工具也適用於建立目錄的階段。

評估工具

如要初步評估目前的基礎架構，建議您使用 Google Cloud 遷移中心，以及 migVisor 和資料庫遷移評估工具 (DMA) 等其他專業資料庫評估工具。

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

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

除了遷移中心，您也可以使用 migVisor 這項專用工具。migVisor 支援各種資料庫引擎，特別適合用於異質遷移。如需 migVisor 的簡介，請參閱「migVisor 總覽」。

migVisor 可以找出可能導致遷移作業預設的構件和不相容的專有資料庫功能，並提供解決方法。migVisor 也能建議目標 Google Cloud 解決方案，包括初始大小和架構。

migVisor 資料庫評估輸出內容會提供下列資訊：

  • 全面探索及分析目前的資料庫部署項目。
  • 詳細的遷移複雜度報告，根據資料庫使用的專屬功能而定。
  • 財務報告，詳細說明遷移後節省的成本、遷移成本和新的營運預算。
  • 分階段遷移計畫，可將資料庫和相關聯的應用程式移至雲端，並盡可能避免造成營運中斷。

如要查看評估輸出內容範例，請參閱「migVisor - Cloud migration assessment tool」(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 for PostgreSQL 執行個體的存取權，並將資料限制在 VPC 內。

  • 修補及設定執行個體。您可能需要更新現有的部署工具。舉例來說，您可能會在 Amazon 參數群組或 Amazon 選項群組中使用自訂設定。您可能需要調整佈建工具，才能使用 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身分與存取權管理 (IAM)。
  3. 設定帳單資訊。
  4. 設定網路連線。
  5. 強化安全性。
  6. 設定記錄、監控和快訊功能。

如要進一步瞭解各項工作，請參閱「遷移至 Google Cloud：規劃及建構基礎」。

如要使用資料庫移轉服務進行遷移，請參閱「PostgreSQL 適用的 Cloud SQL 網路方法」，瞭解遷移情境適用的網路設定。

監控與快訊

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

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

如要遷移執行個體，請執行下列步驟：

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

  2. 根據所選策略和需求，選擇合適的遷移工具。

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

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

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

  6. 為每個執行工作定義備援情境。

  7. 執行測試和驗證，這項作業可以在獨立的暫存環境中進行。

  8. 執行遷移作業。

  9. 執行正式環境轉換。

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

  11. 進行調整和最佳化。

以下各節將說明每個階段。

選擇遷移策略

在這個步驟中，您已掌握足夠資訊，可以評估並選取下列其中一種遷移策略，為每個資料庫選擇最適合的策略：

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

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

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

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

下圖顯示的流程圖，是根據您在決定單一資料庫的遷移策略時，可能會遇到的問題而繪製：

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

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

  • 您是否能承受任何停機時間？

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

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

    • 如果不是，請採用持續複製遷移策略。
    • 如果是，請採用排定維護時間的遷移策略。

即使資料庫位於相同執行個體，策略也可能有所不同。混合使用多種策略可獲得最佳成效。舉例來說，您可以透過排定的維護作業遷移小型且不常使用的資料庫，但對於停機成本高昂的重要資料庫，則應使用持續複製功能。

通常，當初始來源執行個體和目標執行個體之間發生切換時，遷移作業即視為完成。系統會停止所有複製作業 (如有)，並在目標執行個體上執行所有讀寫作業。如果兩個執行個體都已同步，切換時就不會遺失資料，停機時間也會縮到最短。

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

如要設定遷移作業，確保應用程式不會停機，需要較為複雜的設定。在設定複雜度與停機時間之間取得適當平衡，並在業務量較少的時段安排停機。

每種遷移策略都有其優缺點，且都會對遷移程序造成影響。舉例來說，複製程序會對來源執行個體造成額外負載，而應用程式可能會受到複製延遲的影響。應用程式 (和客戶) 可能必須等待應用程式停機，至少要等到複製延遲結束，才能使用新的資料庫。實務上，下列因素可能會增加停機時間：

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

下列常見做法有助於盡量縮短停機時間並降低影響：

  • 找出停機對工作負載影響最小的時間段。例如在正常工作時間外、週末或排定的其他維護期間。
  • 找出工作負載中可在不同階段進行遷移和生產轉換的部分。您的應用程式可能含有不同的元件，這些元件可以獨立出來、調整及遷移，不會造成任何影響。例如前端、CRM 模組、後端服務和報表平台。這類模組可能有自己的資料庫，可排定在程序中較早或較晚的時間遷移。
  • 如果目標資料庫可以容許一些延遲，請考慮逐步遷移。使用增量批次資料移轉，並調整部分工作負載，以處理目標執行個體上的過時資料。
  • 請考慮重構應用程式，以盡量減少遷移作業的影響。舉例來說，您可以調整應用程式，同時寫入來源和目標資料庫，進而實作應用程式層級的複製作業。

選擇遷移工具

選擇合適的遷移工具，是遷移作業能否成功的關鍵。決定遷移策略後，請審查並決定要使用的遷移工具。

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

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

為確保遷移和轉換作業順利進行，您可以運用應用程式部署模式、基礎架構協調和自訂遷移應用程式。不過，您可以運用稱為代管遷移服務的專用工具，簡化資料、應用程式，甚至是整個基礎架構從一個環境遷移至另一個環境的程序。這些作業會從來源資料庫擷取資料、安全地將資料傳輸至目標資料庫，並可選擇在傳輸期間修改資料。這些功能封裝了複雜的遷移邏輯，並提供遷移監控功能。

代管遷移服務具有下列優點：

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

  • 確保資料完整性和安全性：資料會安全且可靠地從來源資料庫移轉至目的地資料庫。

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

  • 提供經過驗證的彈性遷移模型：資料庫遷移不常發生，但卻是重要事件。為避免新手常犯的錯誤，以及現有解決方案的問題，建議您使用經驗豐富的專家提供的工具，而非自行建構自訂解決方案。

  • 節省成本：相較於為自訂遷移解決方案佈建額外伺服器和資源，代管遷移服務的成本效益更高。

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

排定維護遷移作業的工具

以下小節說明可用於一次性遷移的工具，以及各項工具的限制和最佳做法。

如要將資料一次性遷移至 PostgreSQL 適用的 Cloud SQL 或 AlloyDB for PostgreSQL，建議您使用資料庫引擎備份功能，從來源執行個體匯出資料，然後將資料匯入目標執行個體。資料庫遷移服務不支援一次性遷移工作。

內建資料庫引擎備份

如果可以接受長時間停機，且來源資料庫相對靜態，您可以使用資料庫引擎的內建傾印和載入功能 (有時也稱為備份和還原)。

設定和同步作業需要花費一些心力，尤其是資料庫數量龐大時，但資料庫引擎備份通常隨時可用，且使用方式簡單明瞭。這個方法適用於任何資料庫大小，而且通常比其他大型執行個體的工具更有效。

資料庫引擎備份有下列一般限制：

  • 備份作業容易出錯，尤其是手動備份時。
  • 如果快照管理不當，資料可能會不安全。
  • 備份缺少適當的監控功能。
  • 遷移大量資料庫時，備份作業需要費力擴充。

您可以透過 PostgreSQL 內建的備份公用程式 pg_dump 和 pg_dumpall，遷移 PostgreSQL 適用的 Cloud SQL 和 PostgreSQL 適用的 AlloyDB。不過，pg_dump 和 pg_dumapall 公用程式有下列一般限制：

  • 如要遷移大小不超過 500 GB 的資料庫，請使用內建備份公用程式。傾印及還原大型資料庫可能需要很長時間，且可能需要大量磁碟空間和記憶體。
  • pg_dump 公用程式不會納入使用者和角色。如要遷移這些使用者帳戶和角色，可以使用 pg_dumpall 公用程式。
  • Cloud Storage 支援的單一物件大小上限為 5 TB。如果資料庫大於 5 TB，匯出至 Cloud Storage 的作業就會失敗。在這種情況下，您必須將匯出檔案分割為較小的區段。

如果您選擇使用這些公用程式，請注意下列限制和最佳做法：

  • 壓縮資料可降低費用並縮短傳輸時間。搭配 pg_dump 指令使用 --jobs 選項，即可同時執行指定數量的傾印工作。
  • 使用 pg_dump 指令搭配 -z 選項，指定要使用的壓縮層級。這個選項可接受的值介於 0 到 9 之間。預設值為第 6 級壓縮。值越高，傾印檔案的大小就越小，但可能會導致用戶端主機的資源耗用量偏高。如果用戶端主機有足夠的資源，較高的壓縮層級可以進一步縮減傾印檔案大小。
  • 建立 SQL 傾印檔案時使用正確標記。
  • 驗證匯入的資料庫。在還原程序期間，監控公用程式的輸出內容，查看是否有任何錯誤訊息。pg_restore在還原程序期間，檢查 PostgreSQL 記錄是否有任何警告或錯誤。執行基本查詢和資料表計數，驗證資料庫完整性。

如要進一步瞭解限制和最佳做法，請參閱下列資源：

排程維護遷移作業的其他方法

使用內建備份公用程式以外的方法，或許能更靈活地控制排定的維護遷移作業。這些方法可讓您在遷移資料時，對資料執行轉換、檢查或其他作業。您可以將多個執行個體或資料庫整併為單一執行個體或資料庫。整合執行個體有助於降低營運成本，並解決擴充性問題。

其中一種備份公用程式替代方案是使用純文字檔案匯出及匯入資料。如要進一步瞭解平面檔案匯入作業，請參閱「使用 CSV 檔案匯出及匯入 Cloud SQL for PostgreSQL 資料」。

另一個替代方案是使用代管匯入功能，設定從外部 PostgreSQL 資料庫的複製作業。使用代管匯入功能時，系統會先將外部資料庫的資料載入 PostgreSQL 適用的 Cloud SQL 執行個體。這項初始載入作業會使用服務從外部伺服器 (RDS 或 Aurora 執行個體) 擷取資料，並直接匯入 PostgreSQL 適用的 Cloud SQL 執行個體。詳情請參閱「使用代管匯入功能來設定從外部資料庫的複製作業」。

您也可以將來源 PostgreSQL 資料庫中的資料表匯出為 CSV 或 SQL 檔案，然後進行一次性資料移轉。然後將 CSV 或 SQL 檔案匯入 PostgreSQL 適用的 Cloud SQL 或 PostgreSQL 適用的 AlloyDB。如要匯出來源執行個體的資料，可以使用 PostgreSQL 的 aws_s3 擴充功能。或者，您也可以使用 Amazon 資料庫移轉服務，並以 S3 值區做為目標。如要進一步瞭解這種做法，請參閱下列資源：

您也可以手動將資料匯入 AlloyDB for PostgreSQL 執行個體。支援的格式如下：

  • CSV：每個 CSV 格式的檔案都包含資料庫中一個資料表的內容。您可以使用 psql 指令列程式，將資料載入 CSV 檔案。詳情請參閱「匯入 CSV 檔案」。
  • DMP：這個檔案格式包含整個 PostgreSQL 資料庫的封存檔。您可以使用 pg_restore 公用程式，從這個檔案匯入資料。 詳情請參閱「匯入 DMP 檔案」。
  • SQL：這個檔案格式包含 PostgreSQL 資料庫的文字重建內容。這個檔案中的資料會使用 psql 指令列處理。詳情請參閱「匯入 SQL 檔案」。

持續複製遷移作業工具

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

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

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

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

    • 如果是，您是否能接受在複製步驟進行時，寫入作業停機幾秒鐘？

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

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

      • 如果是，建議使用內建的複製功能。
      • 如果沒有，建議您考慮其他遷移選項。

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

資料庫移轉服務，適用於持續複製移轉

資料庫遷移服務提供特定工作類型，適用於持續遷移。 這些連續遷移工作支援高保真度遷移至 PostgreSQL 適用的 Cloud SQL，以及 PostgreSQL 適用的 AlloyDB。

使用資料庫移轉服務遷移至 PostgreSQL 適用的 Cloud SQL 或 PostgreSQL 適用的 AlloyDB 時，每個目標執行個體都有相關的先決條件和限制：

資料庫引擎內建複製功能

資料庫引擎內建的複製功能是資料庫移轉服務的替代方案，可進行持續遷移。

資料庫複寫是指將資料從主要資料庫複製並分配到其他資料庫 (稱為副本) 的程序。這項功能旨在提高資料存取能力，並提升資料庫系統的容錯能力和可靠性。雖然資料庫複製作業的主要用途並非資料庫遷移，但仍可做為達成此目標的工具。資料庫複製通常是持續進行的程序，當主要資料庫中插入、更新或刪除資料時，系統會即時執行這項程序。資料庫複製作業可以一次完成，也可以分批進行。

大多數現代資料庫引擎都會實作不同的資料庫複製方式。其中一種複製方式是將主要執行個體的預先寫入記錄或交易記錄複製並傳送至備用資源。這種做法稱為實體或二進位複製。其他複製類型會發布主要資料庫收到的原始 SQL 陳述式，而不是複製檔案系統層級的變更。這類複製類型稱為邏輯複製。PostgreSQL 也有第三方擴充功能 (例如 pglogical)，可實作依據預寫記錄 (WAL) 的邏輯複製。

Cloud SQL 支援 PostgreSQL 的複製功能。不過，這項功能有一些先決條件和限制。

以下是 PostgreSQL 適用的 Cloud SQL 的限制和先決條件：

  • 支援的 Amazon 版本如下：

    • Amazon RDS 9.6.10 以上版本、10.5 以上版本、11.1 以上版本、 12、13、14
    • Amazon Aurora 10.11 以上版本、11.6 以上版本、12.4 以上版本和 13.3 以上版本

  • 外部伺服器的防火牆必須設定為允許虛擬私有雲網路的私人服務存取權所分配的內部 IP 範圍。PostgreSQL 適用的 Cloud SQL 副本資料庫會使用虛擬私有雲網路做為私人網路。

  • 來源資料庫的防火牆必須設為允許整個內部 IP 範圍，該範圍已分配給 VPC 網路的私人服務連線。PostgreSQL 適用的 Cloud SQL 目的地執行個體會在 IpConfiguration 設定的 privateNetwork 欄位中使用這個虛擬私有雲網路。

  • 在 PostgreSQL 適用的 Cloud SQL 執行個體上安裝 pglogical 擴充功能時，請務必將 enable_pglogical 旗標設為 on (例如 cloudsql.enable_pglogical=on)。

  • 請確認 shared_preload_libraries 參數包含來源執行個體上的 pglogical 擴充功能 (例如 shared_preload_libraries=pg_stat_statements,pglogical)。將 rds.logical_replication 參數設為 1。這項設定會在邏輯層級啟用預先寫入記錄。

    這些變更需要重新啟動主要執行個體後才會生效。

如要進一步瞭解如何使用 PostgreSQL 適用的 Cloud SQL 進行複製，請參閱 PostgreSQL 複製部分中的外部伺服器檢查清單，以及 Cloud SQL 官方說明文件中的「設定 PostgreSQL 的邏輯複製和解碼功能」。

PostgreSQL 適用的 AlloyDB 支援透過 pglogical 擴充功能進行複寫。如要啟用 pglogical 擴充功能以進行複製，可以使用 CREATE EXTENSION 指令。使用該指令前，您必須先在要使用擴充功能的 AlloyDB for PostgreSQL 執行個體中，將資料庫標記 alloydb.enable_pglogical 和 alloydb.logical_decoding 設為 on。設定這些旗標需要重新啟動執行個體。

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

您可以使用 Datastream，近乎即時地複製來源 PostgreSQL 執行個體的變更。Datastream 會使用變更資料擷取 (CDC) 和複製功能，複製及同步處理資料。然後，您可以使用 Datastream 從 Amazon RDS 和 Amazon Aurora 持續複製資料。您可以使用 Datastream，將 PostgreSQL 執行個體的變更複製到 BigQuery 或 Cloud Storage。接著，您可以使用 Dataflow Flex 範本或 Dataproc，透過 Dataflow 將複製的資料匯入 PostgreSQL 適用的 Cloud SQL 和 PostgreSQL 適用的 AlloyDB 執行個體。

如要進一步瞭解如何使用 Datastream 和 Dataflow，請參閱下列資源：

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

在某些情況下，最好使用一個第三方工具來處理大多數資料庫引擎。舉例來說，如果您偏好使用受管理遷移服務，且需要確保目標資料庫一律與來源近乎即時同步，或是需要在遷移過程中進行更複雜的轉換 (例如資料清理、重組和調整)，就可能需要使用這種服務。

如果您決定使用第三方工具，請選擇下列建議，這些工具適用於大多數資料庫引擎。

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 計畫會以倒數時間表的形式呈現，列出完成遷移專案所需的所有工作，以及負責的群組和預估時間。

時間表不僅要包含遷移前準備工作，也要納入資料轉移後進行的驗證、稽核或測試工作。

遷移作業的持續時間通常取決於資料庫大小，但也要考慮其他方面，例如商業邏輯複雜度、應用程式使用情形和團隊可用性。

T-Minus 計畫可能如下所示：

日期 階段 類別 Tasks 角色 倒數 狀態
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 日 遷移 Cutover DMS 升級 DMS 副本 雲端遷移工程師 0 尚未開始
2023 年 11 月 21 日 遷移 遷移驗證 資料庫遷移驗證 遷移團隊 0 尚未開始
2023 年 11 月 21 日 遷移 應用程式測試 執行功能和效能測試 遷移團隊 0 尚未開始
2023/11/22 遷移 公司管理 遷移驗證 GO 或 NO GO 遷移團隊 1 尚未開始
2023/11/23 遷移後 驗證監控功能 設定監控作業 基礎架構團隊 2 尚未開始
2023/11/25 遷移後 安全性 移除 DMS 使用者帳戶 安全團隊 4 尚未開始

多個資料庫遷移作業

如果您有多個資料庫要遷移，遷移計畫應包含所有遷移作業的任務。

建議您先遷移較小的資料庫 (最好是與任務無關的資料庫)，這個方法有助於您在遷移程序和工具方面建立知識和信心。您也可以在整體遷移時間表的早期階段，偵測程序中的任何瑕疵。

如果要遷移多個資料庫，時間軸可以平行化。 舉例來說，如要加快遷移程序，您可以選擇同時遷移一組小型、靜態或較不重要的資料庫，如下圖所示。

平行處理資料庫遷移工作。

如圖所示，資料庫 1 到 4 是一組小型資料庫，會同時遷移。

定義準備工作

準備工作是指您必須完成的所有活動，以滿足遷移作業的先決條件。如果沒有完成準備工作，遷移作業就無法進行，或遷移後的資料庫會處於無法使用的狀態。

準備工作可分為下列類別：

  • Amazon RDS 或 Amazon Aurora 執行個體的準備工作和必要條件
  • 準備來源資料庫和必要條件
  • 設定 PostgreSQL 適用的 Cloud SQL 和 PostgreSQL 適用的 AlloyDB 執行個體
  • 遷移作業專屬設定

準備 Amazon RDS 或 Amazon Aurora 執行個體，並符合必要條件

請參考下列常見的設定和必要工作：

  • 視遷移路徑而定，您可能需要在 RDS 執行個體上允許遠端連線。如果 RDS 執行個體在 VPC 中設為私有，Amazon 和 Google Cloud之間必須存在私有 RFC 1918 連線。

  • 您可能需要設定新的安全性群組，允許在必要通訊埠上建立遠端連線，並將安全性群組套用至 Amazon RDS 或 Amazon Aurora 執行個體：

    • 根據預設，AWS 會為資料庫執行個體關閉網路存取權。
    • 您可以在安全性群組中指定規則，允許來自 IP 位址範圍、通訊埠或安全性群組的存取要求。與該安全性群組相關聯的所有資料庫執行個體，都適用相同規則。

  • 如果您是從 Amazon RDS 遷移，請確保有足夠的可用磁碟空間，可在 Amazon RDS 執行個體上執行完整載入作業期間，緩衝處理預先寫入記錄。

  • 如要持續複製 (透過 CDC 串流變更)，您必須使用完整的 RDS 執行個體，而非唯讀副本。

  • 如果您使用內建複製功能，則須為 PostgreSQL 設定 Amazon RDS 或 Amazon Aurora 執行個體複製功能。內建複製功能或使用內建複製功能的工具，需要 PostgreSQL 的邏輯複製功能。

  • 如果您使用第三方工具，通常需要預先設定和配置，才能使用該工具。請參閱第三方工具的說明文件。

如要進一步瞭解執行個體準備作業和先決條件，請參閱「為 PostgreSQL 設定外部伺服器以進行複製」。

準備來源資料庫和必要條件

  • 如果您選擇使用資料庫移轉服務，請先設定來源資料庫，再連線至該資料庫。詳情請參閱「設定 PostgreSQL 來源」和「設定 PostgreSQL 來源至 PostgreSQL 適用的 AlloyDB」。

  • 如果資料表沒有主鍵，資料庫移轉服務在遷移初始備份後，只會在 CDC 階段將 INSERT 陳述式遷移至目標資料庫。系統不會遷移這些資料表的 DELETE 和 UPDATE 陳述式。

  • 請注意，資料庫遷移服務無法複製大型物件，因為 PostgreSQL 中的邏輯解碼設施不支援解碼大型物件的變更。

  • 如果您選擇使用內建複製功能，請注意，就資料定義語言 (DDL) 指令、序列和大型物件而言，邏輯複製功能有某些限制。如要為資料表啟用 CDC，且資料表會經過大量更新，則必須存在或新增主鍵。

  • 部分第三方遷移工具會要求所有大型物件資料欄都可為空值。遷移期間，任何 NOT NULL 的大型物件資料欄都必須移除該限制。

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

    • 評估資料大小和工作負載效能。重要查詢或交易平均需要多少時間？尖峰時段的等待時間有多長？
    • 記錄基準測量結果，以供日後比較，協助您判斷資料庫遷移的準確度是否令人滿意。決定是否可以切換實際工作負載並停用來源環境，或是否仍需保留來源環境以供備援。

設定 PostgreSQL 適用的 Cloud SQL 和 PostgreSQL 適用的 AlloyDB 執行個體

如要讓目標執行個體達到與來源執行個體相似的效能等級，請選擇與來源執行個體相符的目標 PostgreSQL 資料庫執行個體大小和規格。請特別注意磁碟大小和總處理量、每秒輸入/輸出作業數 (IOPS) 和虛擬 CPU (vCPU) 數量。如果大小設定不正確，可能會導致遷移時間過長、資料庫效能問題、資料庫錯誤和應用程式效能問題。決定要使用 PostgreSQL 適用的 Cloud SQL 或 PostgreSQL 適用的 AlloyDB 執行個體時，請注意磁碟效能取決於磁碟大小和 vCPU 數量。

建立 PostgreSQL 適用的 Cloud SQL 和 PostgreSQL 適用的 AlloyDB 執行個體前，請務必確認下列屬性和需求。如要變更這些屬性和需求，您必須重新建立執行個體。

  • 請仔細選擇目標 Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL 執行個體的專案和區域。執行個體無法在專案和區域之間遷移，必須先轉移資料。 Google Cloud

  • 遷移至 PostgreSQL 適用的 Cloud SQL 和 PostgreSQL 適用的 AlloyDB，並使用相符的主要版本。舉例來說，如果您在 Amazon RDS 或 Amazon Aurora 上使用 PostgreSQL 14.x，就應該遷移至 PostgreSQL 14.x 適用的 Cloud SQL 或 AlloyDB。

  • 如果您使用內建資料庫引擎備份或資料庫移轉服務，請另外複製使用者資訊。詳情請參閱「資料庫引擎專屬備份」一節的限制。

  • 查看資料庫引擎專用的設定標記，並比較來源和目標執行個體的值。請務必瞭解這些設定的影響，以及是否需要相同。舉例來說，使用 PostgreSQL 時，建議您比較來源資料庫中 pg_settings 表格的值，以及 Cloud SQL 和 AlloyDB for PostgreSQL 執行個體中的值。視需要在目標資料庫執行個體上更新標記設定，以複製來源設定。

  • 視工作負載的性質而定，您可能需要啟用特定擴充功能來支援資料庫。如果工作負載需要這些擴充功能，請查看支援的 PostgreSQL 擴充功能，以及如何在 Cloud SQL 和 PostgreSQL 適用的 AlloyDB 中啟用這些擴充功能。

如要進一步瞭解 PostgreSQL 適用的 Cloud SQL 設定，請參閱執行個體設定選項、資料庫引擎專屬標記和支援的擴充功能。

如要進一步瞭解如何設定 PostgreSQL 適用的 AlloyDB，請參閱「支援的資料庫旗標」和「支援的擴充功能」。

遷移作業專屬設定

如果可以接受停機，您可以將 SQL 傾印檔案匯入 PostgreSQL 適用的 Cloud SQL 和 AlloyDB。在這種情況下，您可能需要建立 Cloud Storage 值區來儲存資料庫傾印。

如果您使用複製功能，請務必確保 Cloud SQL 和 PostgreSQL 適用的 AlloyDB 副本可存取主要 (來源) 資料庫。如要取得這項存取權，請使用文件中說明的連線選項。

視用途和重要性而定，您可能需要實作備援情境，通常包括反轉複製方向。在這種情況下，您可能需要額外的複製機制，將目標 Cloud SQL 和 AlloyDB for PostgreSQL 複製回來源 Amazon 執行個體。

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

如果您要遷移至 PostgreSQL 適用的 AlloyDB，可以考慮使用 PostgreSQL 適用的 Cloud SQL 執行個體，做為可能的備援情境目的地。使用 pglogical 擴充功能，設定該 Cloud SQL 執行個體的邏輯複寫。

詳情請參閱下列資源：

定義執行工作

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

內建資料庫引擎備份

使用 pg_dump 公用程式建立備份。如要進一步瞭解如何使用這項公用程式匯入及匯出資料，請參閱下列資源：

資料庫遷移服務遷移工作

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

測試所有必要條件，確保工作能順利執行。選擇工作負載可容許短暫停機的時間，以便進行遷移和正式環境轉換。

在資料庫移轉服務中，遷移作業會先傾印並還原初始結構定義，但不包含索引和限制，接著再複製資料。資料複製完成後，系統會還原索引和限制。最後，系統會開始從來源到目的地資料庫執行個體，持續複製變更。

資料庫移轉服務會使用 pglogical 擴充功能，將資料從來源資料庫執行個體複製到目標資料庫執行個體。在遷移作業開始時，這項擴充功能會要求在來源 Amazon RDS 或 Amazon Aurora 執行個體中的所有資料表上，設定短期專屬鎖定，藉此設定複製作業。因此，建議您在資料庫最不忙碌時開始遷移，並在傾印和複製階段避免對來源執行陳述式，因為 DDL 陳述式不會複製。如果必須執行 DDL 作業，請使用「pglogical」函式在來源執行個體上執行 DDL 陳述式，或在初始傾印階段完成後，手動在遷移目標執行個體上執行相同的 DDL 陳述式。

使用資料庫移轉服務進行遷移時，最後一個步驟是升級作業。升級資料庫執行個體會中斷目的地資料庫與來源資料庫異動流程的連線，然後將現在獨立的目的地執行個體升級為主要執行個體。這種做法也稱為「正式環境切換」。

如需完整的遷移設定程序，請參閱 PostgreSQL 和 PostgreSQL 至 PostgreSQL 適用的 AlloyDB 的快速入門指南。

資料庫引擎內建複製功能

Cloud SQL 支援兩種邏輯複製類型：PostgreSQL 的內建邏輯複製，以及透過 pglogical 擴充功能的邏輯複製。如果是 AlloyDB for PostgreSQL，建議使用 pglogical 擴充功能進行複製。每種邏輯複寫類型都有自己的功能和限制。

內建邏輯複寫功能具有下列特色和限制：

  • 這項功能適用於 PostgreSQL 10 以上版本。
  • 所有變更和資料欄都會複製。出版品是在表格層級定義。
  • 資料只會從基本資料表複製到基本資料表。
  • 不會執行序列複製作業。
  • 如果許多資料表都沒有主鍵，建議使用這種複製類型。設定內建的 PostgreSQL 邏輯複製功能。如果資料表沒有主鍵，請套用 REPLICA IDENTITY FULL 表單，讓內建的複製功能使用整列做為唯一 ID，而非主鍵。

pglogical 邏輯複寫具有下列功能和限制：

  • 這項功能適用於所有 PostgreSQL 版本，並提供跨版本支援。
  • 來源提供資料列篩選功能。
  • 不會複製 UNLOGGED 和 TEMPORARY 資料表。
  • 資料表必須有主鍵或不重複的鍵，才能擷取 UPDATE 和 DELETE 變更。
  • 可進行序列複製。
  • 複製作業可能會延遲。
  • 如果有多個發布者，或是複製的資料與本機變更之間有衝突，這項服務會偵測到衝突，並提供可設定的解決方式。

如要瞭解如何從外部伺服器 (例如 Amazon RDS 或 Amazon Aurora for PostgreSQL) 設定內建的 PostgreSQL 邏輯複製功能，請參閱下列資源：

第三方工具

為您選擇的第三方工具定義任何執行工作。

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

您可以使用一或多個流程，在自訂應用程式中整理這些遷移程序。如要編寫自訂應用程式的程式碼，您可以選擇使用圖形程式設計工具，或是 Tungsten Query Language (TQL) 程式設計語言。

如要進一步瞭解如何使用 Striim，請參閱下列資源：

如果您決定使用 Striim 遷移資料，請參閱下列指南，瞭解如何使用 Striim 將資料遷移至 Google Cloud：

定義備用情境

為每項遷移執行作業定義備援動作項目，以防遷移過程中發生無法預料的問題。備援工作通常取決於所用的遷移策略和工具。

備援可能需要大量心力。最佳做法是等到測試結果令人滿意後，再執行正式環境轉換。應妥善測試資料庫遷移和備援情境，避免嚴重中斷。

定義成功標準，並為所有遷移作業執行工作設定時間限制。進行遷移作業的模擬測試，有助於收集各項工作預計所需時間的資訊。舉例來說，如果是定期維護遷移作業，您可承受轉換空窗期造成的停機時間。不過，如果一次性移轉工作或備份還原作業中途失敗，請務必規劃後續動作。如果遷移作業未在預期時間內完成，您可能必須延後遷移作業，具體情況取決於計畫停機時間已過多久。

通常是指在執行正式環境轉換後，如果目標執行個體發生問題，則回溯遷移作業。如果您實作備援計畫，請務必將其視為完整的資料庫遷移作業，包括規劃和測試。

如果選擇不制定備案，請務必瞭解可能造成的後果。如果沒有備援計畫，可能會增加意想不到的工作量，並導致遷移程序中發生可避免的中斷。

雖然回溯是最後手段，而且大多數資料庫遷移作業都不會用到，但我們建議您一律制定回溯策略。

簡單備援

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

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

反向複製

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

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

轉送複製

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

如果您想隨時享有備援服務，或是必須在正式上線後不久捨棄初始來源資料庫，請採用這個方法。

重複寫入

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

您的應用程式會同時寫入初始來源和目標資料庫執行個體，因此您可以逐步完成正式環境轉換，直到只使用目標資料庫執行個體為止。如有任何問題，您可以將應用程式重新連線至初始來源，不會發生停機情形。如果遷移作業順利完成，即可捨棄初始來源和重複的寫入機制。

如果必須確保遷移作業不會停機、有可靠的備援機制，且您有時間和資源重構應用程式，建議採用這種做法。

進行測試和驗證

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

  • 資料庫中的資料已成功遷移。
  • 切換為使用新的目標執行個體後，與現有應用程式整合。

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

  • 要遷移的資料。對於某些工作負載，您可能不需要遷移所有資料。您可能不想遷移已匯總、多餘、封存或舊的資料。您可能會將該資料封存到 Cloud Storage bucket 中做為備份。
  • 可接受的資料遺失百分比。這項功能特別適用於用於分析工作負載的資料，因為遺失部分資料不會影響工作負載的一般趨勢或效能。
  • 資料品質和數量條件，您可以套用至來源環境，並在遷移後與目標環境比較。
  • 成效條件。部分業務交易在目標環境中可能會較慢，但處理時間仍在定義的預期範圍內。

來源環境中的儲存空間設定可能無法直接對應至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： 開放原始碼資料庫測試架構，支援測試導向的程式碼開發和自動測試。它使用基本語法建立測試案例，並提供資料驅動測試、版本控管和測試結果報告等功能。不過，相較於其他工具，支援複雜查詢和交易的程度有限，且沒有大型社群支援或詳盡的文件。如果查詢不複雜，且您想執行自動化測試並將其整合至持續整合和交付程序，建議使用這項工具。

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

  • 確保所有物件和設定都已正確遷移。
  • 協助您定義及執行遷移測試案例。
  • 提供實際遷移所需時間的深入分析，方便您校準時程。
  • 這是測試、驗證及調整遷移計畫的機會。 有時無法預先規劃所有事項，因此這項功能可協助您找出任何缺漏。

您可以對一小組或整組要遷移的資料庫執行資料測試。您可以根據資料庫總數和用於實作遷移的工具，決定採用以風險為依據的方法。使用這種方法時，您會對透過相同工具遷移的部分資料庫執行資料驗證，尤其是當該工具是受管理遷移服務時。

如要進行測試，您應有權存取來源和目標資料庫，並執行下列工作：

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

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

如果您使用資料庫遷移服務做為遷移工具，請參閱「驗證遷移作業」主題的 PostgreSQL 或 PostgreSQL to AlloyDB for PostgreSQL 版本。

資料驗證工具

如要執行資料驗證，建議使用資料驗證工具 (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的資料驗證工具輕鬆驗證資料」。

執行遷移作業

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

資料遷移時，建議您採取下列最佳做法：

  • 每當計畫步驟開始和完成時，請通知相關團隊。
  • 如果任何步驟耗費的時間超出預期，請比較經過的時間與該步驟的時限。發生這種情況時，請定期向相關團隊提供最新進度。
  • 如果時間範圍大於計畫中每個步驟保留的時間上限，請考慮回溯。
  • 針對遷移和轉換計畫的每個步驟，做出「繼續或停止」的決定。
  • 請考慮每個步驟的回復動作或替代情境。

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

執行正式環境轉換

高階正式環境轉換程序可能會因您選擇的遷移策略而異。如果工作負載可以停機，遷移轉換作業就會開始停止寫入來源資料庫。

如果是持續複製遷移作業，您通常會在轉換程序中執行下列高階步驟：

  • 停止將資料寫入來源資料庫。
  • 排空來源。
  • 停止複製程序。
  • 部署指向新目標資料庫的應用程式。

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

資料驗證通過您的條件後，即可執行應用程式層級的轉換作業。部署已重構的工作負載，使用新的目標執行個體。您部署的應用程式版本會指向新的目標資料庫執行個體。您可以透過滾動式更新、階段推出或藍綠部署模式執行部署作業。應用程式可能會短暫停止運作。

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

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

清除來源環境，並設定 Cloud SQL 或 PostgreSQL 適用的 AlloyDB 執行個體

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

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

  • 收集來源執行個體的資料庫參數設定。 或者，確認這些資料與您在清查階段收集的資料相符。調整目標執行個體參數，使其與來源執行個體參數相符。

  • 從來源執行個體收集資料庫統計資料，並與目標執行個體中的資料進行比較。如果統計資料差異很大，就難以比較來源執行個體和目標執行個體的效能。

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

為確保來源執行個體在轉換後保持最新狀態，建議將目標 Cloud SQL 執行個體上執行的寫入作業複製回來源資料庫。如要復原，您可以還原舊的來源執行個體，資料遺失量極少。

或者，您也可以使用其他執行個體，並將變更複製到該執行個體。舉例來說，如果 PostgreSQL 適用的 AlloyDB 是遷移目的地，請考慮設定複製作業至 PostgreSQL 適用的 Cloud SQL 執行個體，以備不時之需。

除了清除來源環境外，您還必須為 PostgreSQL 適用的 Cloud SQL 執行個體完成下列重要設定：

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

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

如要進一步瞭解 PostgreSQL 適用的 Cloud SQL 和 PostgreSQL 適用的 AlloyDB 執行個體的維護作業和最佳做法，請參閱下列資源：

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

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

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

  1. 評估目前的環境、團隊和最佳化迴圈。
  2. 建立最佳化需求和目標。
  3. 將環境和團隊調整至最佳狀態。
  4. 調整最佳化迴圈。

重複這個程序，直到達成最佳化目標為止。

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

確立最佳化需求

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

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

您可以透過 Cloud SQL 實作高可用性和災難復原策略，以符合復原時間目標 (RTO) 和復原點目標 (RPO)。如要提高可靠性和可用性，請考慮下列事項：

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

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

提升資料庫基礎架構效能

資料庫相關的效能問題雖然不大，但往往會影響整體運作。如要維持及提升 Cloud SQL 執行個體效能，請參考下列指南：

  • 如果資料庫資料表數量過多，可能會影響執行個體的效能和可用性，並導致執行個體喪失服務水準協議保障。

  • 確認執行個體的記憶體或 CPU 沒有受到限制。

    • 如果是需要大量資源的工作負載，請確保執行個體至少有 60 GB 的記憶體。
    • 針對較慢的資料庫插入、更新或刪除作業，請檢查寫入者與資料庫的位置；長距離傳送資料會導致延遲發生。

  • 使用 Cloud Monitoring 中預先定義的查詢深入分析資訊主頁 (或類似的資料庫引擎內建功能)，提升查詢效能。找出最昂貴的指令，並嘗試進行最佳化。

  • 避免資料庫檔案變得過大。請以 MB 為單位設定 autogrow，而非百分比，並根據需求使用適當的增量。

  • 檢查讀取器和資料庫位置。延遲對讀取效能的影響大於寫入效能。

從 Amazon RDS 和 Aurora for PostgreSQL 遷移至 PostgreSQL 適用的 Cloud SQL 時，請參考下列指南：

  • 使用快取功能提升讀取效能。從「pg_stat_database」檢視畫面檢查各種統計資料。舉例來說，blks_hit / (blks_hit + blks_read) 比率應大於 99%。如果這個比率未超過 99%，請考慮增加執行個體的 RAM 大小。詳情請參閱 PostgreSQL 統計資料收集器。
  • 回收空間並避免索引效能不佳。視資料變更頻率而定，您可以設定排程，在 PostgreSQL 適用的 Cloud SQL 上執行 VACUUM 指令。
  • 使用 Cloud SQL Enterprise Plus 版本，提高機器設定限制和資料快取。如要進一步瞭解 Cloud SQL Enterprise Plus，請參閱 Cloud SQL 版本簡介。
  • 改用 PostgreSQL 適用的 AlloyDB。切換後，您就能享有完整的 PostgreSQL 相容性、更優異的交易處理能力，以及處理資料庫支援的快速交易分析工作負載。您也可以使用索引建議工具功能，取得新索引的建議。

如要進一步瞭解如何提升 PostgreSQL 適用的 Cloud SQL 資料庫基礎架構效能，請參閱 PostgreSQL。

從 Amazon RDS 和 Aurora for PostgreSQL 遷移至 AlloyDB for PostgreSQL 時，請參考下列指南，提升 AlloyDB for PostgreSQL 資料庫執行個體的效能：

提升資料庫觀測能力

診斷及排解連線至資料庫執行個體的應用程式問題，可能既耗時又充滿挑戰。因此，集中管理所有資料庫和執行個體層級的活動，讓所有團隊成員都能掌握最新動態，就顯得至關重要。您可以透過下列方式監控 Cloud SQL 執行個體：

  • Cloud SQL 會使用內建記憶體自訂代理程式，收集查詢遙測資料。

    • 使用 Cloud Monitoring 收集服務和使用資源的計量結果。 Google CloudCloud Monitoring 為多項 Google Cloud 產品提供預先定義的資訊主頁，包括 Cloud SQL 監控資訊主頁。
    • 您可以建立自訂資訊主頁來監控指標，並設定快訊政策，以便及時收到通知。
    • 或者，您也可以考慮使用與 Google Cloud整合的第三方監控解決方案，例如 Datadog 和 Splunk。

  • Cloud Logging 會收集常見應用程式元件的記錄資料。

  • Cloud Trace 會收集應用程式的延遲資料和執行的查詢計畫，協助您追蹤要求在應用程式中的傳播情形。

  • Database Center 可集中顯示整個資料庫機群的運作情況，並提供 AI 輔助功能。您可以監控資料庫的健康狀態、可用性設定、資料保護機制、安全性和產業法規遵循情形。

如要進一步瞭解如何提升資料庫基礎架構的可觀測性，請參閱下列說明文件章節：

Cloud SQL 和 PostgreSQL 適用的 AlloyDB 一般最佳做法與作業指南

套用 Cloud SQL 最佳做法，設定及調整資料庫。

以下列出幾項重要的 Cloud SQL 一般建議：

  • 如果執行個體很大，建議您盡可能將其分割為較小的執行個體。
  • 設定儲存空間，以因應重要的資料庫維護作業。請確保至少有 20% 的可用空間，以因應 Cloud SQL 可能執行的任何重要資料庫維護作業。
  • 資料庫資料表過多，會影響資料庫升級時間。 理想情況下，每個執行個體的資料表數量應少於 10,000 個。
  • 請為執行個體選擇適當大小，以考量交易 (二進位) 記錄保留時間，尤其是寫入活動頻繁的執行個體。

為有效處理您可能遇到的任何資料庫效能問題，請在問題解決前遵循下列指南：

擴充基礎架構：增加資源 (例如磁碟輸送量、vCPU 和 RAM)。視緊急程度和團隊的可用性與經驗而定，垂直擴充執行個體可解決大部分效能問題。之後，您可以在測試環境中進一步調查問題的根本原因，並考慮採取哪些措施來解決問題。

執行及排定資料庫維護作業：索引重整、統計資料更新、真空分析，以及重新建立大量更新資料表的索引。檢查上次執行這些維護作業的時間，特別是受影響的物件 (資料表、索引)。瞭解資料庫活動是否出現異常變化。例如最近新增資料欄，或資料表有大量更新。

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

向外擴充讀取作業：請考慮使用唯讀備用資源。如果垂直擴充無法滿足需求，且資料庫調整和最佳化措施沒有幫助，請考慮水平擴充。將應用程式的讀取查詢作業導向讀取副本，可提升資料庫工作負載的整體效能。不過，您可能需要額外費心，才能變更應用程式以連線至唯讀副本。

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

資料庫分片：您可以透過資料庫分片擴充寫入作業。 分片是一項複雜的作業，需要以特定方式重新架構資料庫和應用程式，並執行資料遷移。您可以使用特定分割條件，將資料庫執行個體分割成多個較小的執行個體。條件可以是顧客或主題。這個選項可讓您水平擴充寫入和讀取作業。不過，這會增加資料庫和應用程式工作負載的複雜度。也可能導致分片不平衡 (稱為熱點)，抵銷分片的好處。

如果是 PostgreSQL 適用的 Cloud SQL 和 PostgreSQL 適用的 AlloyDB，請考慮下列最佳做法：

  • 如要卸載主要執行個體的流量，請新增唯讀備用資源。您也可以使用 HAProxy 等負載平衡器來管理流往副本的流量。不過，請避免使用過多副本，因為這會阻礙 VACUUM 作業。如要進一步瞭解如何使用 HAProxy，請參閱 HAProxy 官方網站。
  • 增加系統記憶體和 maintenance_work_mem 參數，即可最佳化 VACUUM 作業。增加系統記憶體表示每次疊代可批次處理更多元組。
  • 由於較大的索引會耗費大量時間進行索引掃描，請將 INDEX_CLEANUP 參數設為 OFF，以便快速清除及凍結資料表資料。
  • 使用 AlloyDB for PostgreSQL 時，請使用 AlloyDB for PostgreSQL 系統洞察資訊主控台和稽核記錄。PostgreSQL 適用的 AlloyDB 系統深入分析資訊主頁會顯示您使用的資源指標，方便您監控這些指標。詳情請參閱「PostgreSQL 適用的 AlloyDB」說明文件中的「監控執行個體」主題。

詳情請參閱下列資源：

後續步驟

貢獻者

作者：

其他貢獻者：Somdyuti Paul | 資料管理專家