本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 階段 3：遷移
在您完成遷移規劃並識別遷移策略之後，實際遷移就會發生。在此階段中，目標資料庫經過設計，來源資料會遷移至目標，而資料會經過驗證。
![\[Iterative migration process\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-database-migration/images/iterative-migration-process.png)
這是包含多個轉換、遷移和測試週期的反覆程序。功能和效能測試完成後，您可以切換到新的資料庫。
遷移階段包含下列關鍵步驟，這些步驟會在下列各節中討論：
+ [轉換結構描述](convert-schema.md)
+ [遷移資料](migrate-data.md)
+ [更新應用程式](update-app.md)
+ [測試遷移](test-migration.md)
+ [切換至新資料庫](cut-over.md)
# 轉換結構描述
在資料庫遷移期間，其中一個關鍵任務是將您的結構描述從來源資料庫引擎遷移至目標資料庫引擎。如果您重新託管或轉換，您的資料庫引擎不會變更。這稱為*同質資料庫遷移*，您可以使用原生資料庫工具來遷移結構描述。
不過，如果您正在重新建構應用程式，則結構描述轉換可能需要更多努力。在這種情況下，您將進行*異質資料庫遷移*，其中您的來源和目標資料庫引擎將不同。您目前的資料庫結構描述可能正在使用無法直接轉換為目標資料庫引擎的套件和功能。某些功能可能以不同的名稱提供。因此，轉換結構描述需要充分了解您的來源和目標資料庫引擎。此任務可能具有挑戰性，取決於您目前結構描述的複雜性。
AWS 提供兩種資源來協助您進行結構描述轉換： AWS Schema Conversion Tool (AWS SCT) 和遷移手冊。
## AWS SCT
AWS SCT 是一項免費工具，可協助您將現有資料庫從一個引擎轉換為另一個引擎。 AWS SCT 支援許多來源資料庫，包括 Oracle、Microsoft SQL Server、MySQL、Sybase 和 IBM Db2 LUW。您可以從 Aurora MySQL 和 Aurora PostgreSQL 等目標資料庫進行選擇。
AWS SCT 提供圖形化使用者介面，可直接連線至來源和目標資料庫，以擷取目前的結構描述物件。連線時，您可以產生資料庫遷移評估報告，以取得轉換工作和動作項目的高階摘要。下列畫面圖解顯示資料庫遷移評估報告範例。
![\[Sample database migration assessment report from AWS SCT\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-database-migration/images/sct-assessment-report.png)
透過 AWS SCT ，您可以轉換結構描述並直接將其部署到目標資料庫中，或者您可以取得轉換結構描述的 SQL 檔案。如需詳細資訊，請參閱 AWS 文件中的[使用 AWS Schema Conversion Tool 使用者介面](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_UserInterface.html)。
## 遷移手冊
雖然 會 AWS SCT 轉換許多來源物件，但轉換的某些層面需要手動介入和調整。為了協助處理此任務， AWS 提供遷移手冊，詳細說明兩個資料庫之間的不相容和相似性。如需這些手冊的詳細資訊，請參閱 AWS 網站上的 [AWS Database Migration Service 資源](https://aws.amazon.com/dms/resources/)。
# 遷移資料
當結構描述遷移完成時，您可以將資料從來源資料庫移至目標資料庫。根據您的應用程式可用性需求，您可以執行簡單的擷取任務，以執行來源資料的一次性複製到新的資料庫。或者，您可以使用工具來複製目前的資料，並繼續複寫所有變更，直到您準備好轉換到新的資料庫為止。對於重新託管和轉換遷移，我們建議您使用原生資料庫特定工具來遷移資料。
可協助您進行資料傳輸的工具包括 AWS Database Migration Service (AWS DMS) 和離線遷移工具。下列各節會加以說明。
## AWS DMS
使用 AWS SCT 將結構描述物件從來源資料庫引擎轉換為目標引擎後，您可以使用 AWS DMS 遷移資料。使用 AWS DMS ，您可以在複寫資料時讓來源資料庫保持啟動和執行。您可以執行一次性的資料複本，或使用連續複寫進行複製。當來源和目標資料庫同步時，您可以將資料庫離線，並將操作移至目標資料庫。 AWS DMS 可用於同質資料庫遷移 （例如，從內部部署 Oracle 資料庫遷移至 Amazon RDS for Oracle 資料庫） 以及異質遷移 （例如，從內部部署 Oracle 資料庫遷移至 Amazon RDS for PostgreSQL 資料庫）。如需使用 AWS DMS的詳細資訊，請參閱 [AWS DMS 文件](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html)。
## 離線遷移選項
除了 之外 AWS DMS ，您還可以使用其他選項，從來源資料庫擷取您的資料，並將其載入目標資料庫。當資料遷移活動期間允許應用程式停機時間時，這些選項大多是合適的。這些方法的範例包括：
+ 從載入目標資料庫的來源資料庫擷取逗號分隔值 (CSV)
+ 對於 Oracle 來源資料庫，**ora2pg** 公用程式會將資料複製到 PostgreSQL
+ 自訂擷取、轉換、載入 (ETL) 任務，將資料從來源複製到目標
# 更新應用程式
資料庫遷移幾乎不是純資料庫遷移。您必須查看使用資料庫的應用程式，以確保它與新資料庫如預期般運作。如果您只是重新託管或轉譯相同的資料庫引擎，則變更會很小，但如果您決定移至新的資料庫引擎，變更會更重要。
如果您的應用程式倚賴物件關聯映射 (ORM) 與資料庫互動，則當您遷移到新的資料庫引擎時，不需要太多的變更。不過，如果您的應用程式有自訂資料庫互動或動態建置的 SQL 查詢，則變更可能相當龐大。查詢格式可能會有需要更正的差異，以確保應用程式如預期般運作。
例如，在 Oracle 中，將字串與 串連會`NULL`傳回原始字串。不過，在 PostgreSQL 中，將字串與 串連，並`NULL`傳回 `NULL`。另一個範例是如何處理`NULL`和空字串。在 PostgreSQL 中，`NULL`空字串是兩個不同的項目，而 Oracle 之類的資料庫會以相同的方式處理它們。在 Oracle 中，如果您插入資料欄值設為 `NULL`或空字串的資料列，您可以使用 `where`子句來擷取這兩種類型的值：`where is NULL`。在 PostgreSQL 中，此`where`子句只會傳回一列，其中資料欄值實際上是 NULL；不會傳回字串值空白的資料列。如需這些差異的詳細資訊，請參閱 [AWS Database Migration Service 資源](https://aws.amazon.com/dms/resources/)網頁上列出的遷移手冊。
# 測試遷移
功能和效能測試是資料庫遷移的重要部分。詳細的功能測試將確保您的應用程式使用新的資料庫，沒有任何問題。您應該花時間開發單元測試，以測試應用程式工作流程。
效能測試可確保您的資料庫回應時間在可接受的時間範圍內。您可以識別瓶頸、最佳化和重複效能測試。您可以視需要重複週期，以取得所需的效能結果。
測試可以是手動或自動化。我們建議您使用自動化架構進行測試。在遷移期間，您將需要執行多次測試，因此擁有自動化測試架構有助於加速錯誤修正和最佳化週期。
此測試可以顯示開發階段期間遺漏的問題。例如，任何轉換不正確的查詢都會失敗或傳回不正確的結果，導致功能測試失敗。效能測試可以顯示問題，例如遺失索引導致查詢回應時間變慢。它們也可以根據工作負載或修改查詢，顯示需要資料庫引擎調校的效能問題。
# 剪下
資料庫轉換策略通常與應用程式的停機時間需求緊密結合。您可以用於資料庫切換的策略包括離線遷移、快閃切割遷移、作用中/作用中資料庫組態和增量遷移。下列各節會詳細討論這些內容。
## 離線遷移
如果您在寫入操作期間可以讓應用程式長時間離線，則可以使用 AWS DMS 完全載入任務設定或其中一個離線遷移選項來進行資料遷移。讀取流量可以在此遷移進行時繼續，但必須停止寫入流量。由於所有資料都需要從來源資料庫複製，因此會使用來源資料庫資源，例如 I/O 和 CPU。
在高階，離線遷移涉及以下步驟：
1. 完成結構描述轉換。
1. 開始寫入流量的停機時間。
1. 使用其中一個離線遷移選項來遷移資料。
1. 驗證您的資料。
1. 將您的應用程式指向新的資料庫。
1. 結束應用程式停機時間。
## 快閃記憶體切割遷移
在快閃記憶體切割遷移中，主要目標是將停機時間保持在最低限度。此策略依賴從來源資料庫到目標資料庫的持續資料複寫 (CDC)。資料遷移時，所有讀取/寫入流量將繼續在目前的資料庫上。由於所有資料都需要從來源資料庫複製，因此會使用 I/O 和 CPU 等來源伺服器資源。您應該測試 ，以確保此資料遷移活動不會影響您的應用程式效能 SLAs。
從高層級來看，快閃記憶體切割遷移涉及以下步驟：
1. 完成結構描述轉換。
1. 在 AWS DMS 連續資料複寫模式中設定。
1. 當來源和目標資料庫同步時，請驗證資料。
1. 啟動應用程式停機時間。
1. 推出應用程式的新版本，指向新的資料庫。
1. 結束應用程式停機時間。
## 作用中/作用中資料庫組態
主動/主動資料庫組態涉及設定機制，以在兩個資料庫都用於寫入流量時，讓來源和目標資料庫保持同步。此策略比離線或快閃切割遷移涉及更多工作，但在遷移期間也提供更多彈性。例如，除了在遷移期間經歷最短的停機時間之外，您還可以將生產流量以小型、受控的批次移至新資料庫，而不是執行一次性切換。您可以執行雙寫入操作，以便對兩個資料庫進行變更，或使用 [HVR](https://www.hvr-software.com/product/) 等雙向複寫工具來保持資料庫同步。此策略在設定和維護方面具有更高的複雜性，因此需要更多測試以避免資料一致性問題。
在高階，主動/主動資料庫組態涉及以下步驟：
1. 完成結構描述轉換。
1. 將現有資料從來源資料庫複製到目標資料庫，然後使用雙向複寫工具或從應用程式進行雙寫入，讓兩個資料庫保持同步。
1. 當來源和目標資料庫同步時，請驗證資料。
1. 開始將一部分流量移至新的資料庫。
1. 繼續移動流量，直到所有資料庫流量都移至新的資料庫為止。
## 增量遷移
在增量遷移中，您以較小的部分遷移應用程式，而不是執行一次性的完整切換。根據您目前的應用程式架構或您願意在應用程式中進行的重構，此切換策略可能會有許多變化。
您可以使用[設計模式](https://samirbehara.com/2018/09/10/monolith-to-microservices-using-strangler-pattern/)來新增獨立的微服務，以取代現有單體舊版應用程式的一部分。這些獨立的微服務擁有自己的資料表，而這些資料表不會由應用程式的任何其他部分共用或存取。您可以使用任何其他切換策略，逐一將這些微服務遷移到新的資料庫。遷移的微服務會開始使用新的資料庫進行讀取/寫入流量，而應用程式的所有其他部分則會繼續使用舊資料庫。遷移所有微服務後，您會停用舊版應用程式。此策略會將遷移分為更小、可管理的部分，因此可以降低與一個大型遷移相關聯的風險。
# 遵循 的最佳實務 AWS
除了前面各節討論的遷移活動之外，您應該投入時間，以確保您遵循最佳實務，在 AWS 雲端託管資料庫。請參閱 [AWS 文件](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html)，了解使用關聯式資料庫的最佳實務 AWS。