本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 剪下
資料庫轉換策略通常與應用程式的停機時間需求緊密結合。您可以用於資料庫切換的策略包括離線遷移、快閃切割遷移、作用中/作用中資料庫組態和增量遷移。下列各節會詳細討論這些內容。
## 離線遷移
如果您在寫入操作期間可以讓應用程式長時間離線，則可以使用 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/)來新增獨立的微服務，以取代現有單體舊版應用程式的一部分。這些獨立的微服務擁有自己的資料表，而這些資料表不會由應用程式的任何其他部分共用或存取。您可以使用任何其他切換策略，逐一將這些微服務遷移到新的資料庫。遷移的微服務會開始使用新的資料庫進行讀取/寫入流量，而應用程式的所有其他部分則會繼續使用舊資料庫。遷移所有微服務後，您會停用舊版應用程式。此策略會將遷移分為更小、可管理的部分，因此可以降低與一個大型遷移相關聯的風險。