移轉階段和考量

8 分鐘

成功的移轉會平衡數個階段的考量。

移轉階段

移轉發生在數個階段。首先，規劃移轉範圍：探索和評估資料庫資源、停機等業務需求，以及移轉失敗的後援計劃。然後，佈建適當的資源，以及設定來源與目標環境之間的連線，以準備移轉。設定移轉方法並備妥資源之後，您通常會想要在預備環境中嘗試執行，以在正式環境移轉前找出問題。最後，執行最終移轉，並驗證持續進度和成功完成。

本課程模組著重於準備 (2) 和最終移轉 (4、5) 階段。

移轉考量

您應該評估應用程式停機的需求、版本相容性、網路和安全性、效能、成本和業務持續性。

應用程式停機時間

您應該首要考量的其中一件事是您的業務案例可以容納多長的停機時間。這個答案會強烈限制您可用的移轉選項。

最好的停機時間是使用者不會注意到的時間。實際上，移轉是複雜的程序，而針對此課程模組中的考量所做的決策，將決定需要的停機時間。其中的取捨包括可用性與移轉成本和風險之間的平衡。考量到將停機時間減少到數分鐘甚至幾秒所涉及的複雜度，請務必測試假設，並判斷可接受多長的移轉停機時間。

離線移轉

使用離線移轉時，您必須關閉應用程式以移動資料庫。這可確保在移轉期間不會有任何資料變更。不過，此方法需要關閉資料庫，才能完成資料匯出。停機時間至少會是傳輸資料所需的時間。離線移轉涉及：

將所有應用程式與來源資料庫中斷連線。
匯出來源資料庫的內容。
將來源資料匯入目標資料庫。
匯入完成後，將應用程式重新連線到目標資料庫。

某些應用程式在低流量期間已排程維護時段。這是執行離線移轉的最佳時間。

增量離線移轉會先移動大量資料，再讓應用程式離線，以減少停機時間。首先，請移轉完整的資料庫備份。然後，將變更移轉至自上一次移轉之後新增的資料庫。當移轉這些新變更所需的時間符合可接受的停機時間時，請讓應用程式離線，以凍結資料並完成移轉。您可能會發現，單一移轉增量足以透過量級減少停機時間，特別是具有多年歷程記錄的資料庫。針對大型和忙碌的資料庫，您可能需要移轉多個增量，以達到可接受的停機時間。

線上移轉

透過線上移轉，您可以在移轉期間，將來源伺服器變更複寫到目標伺服器，然後在複寫完全同步時，切換至目標伺服器，以便大幅減少或甚至消除停機的需求。

有時候會不希望或甚至不能發生停機。在此情況下，無法關閉應用程式來「凍結」資料庫狀態。來源資料庫會在一般作業期間複寫到目標資料庫。當目標完全符合來源時，應用程式會切換至目標資料庫。

線上移轉需要您：

開始將來源資料庫複寫至目標資料庫。
當目標資料庫完成更新時，請暫停應用程式，或藉由啟用唯讀模式，強制寫入失敗，以凍結來源資料庫。
當目標資料庫 100% 更新完變更時，請關閉目標中的複寫。
將所有用戶端重新導向目標資料庫並繼續作業。
關閉舊版來源資料庫。

比較線上和離線移轉

離線移轉需要停機時間，但前述的增量移轉技術可大幅降低停機時間。多個增量可將最終移轉縮減為一天或更少的資料量。 Azure DMS 等自動化服務會藉由執行一系列較小的移轉，將停機時間降到最低。如果網路設定會避免自動化，也可以手動執行增量離線移轉。

線上移轉會協調資料庫團隊和應用程式團隊之間的精密作業。用戶端應用程式必須經過調整，以正常回應寫入失敗，避免在移轉期間遺失資料。用戶端也必須支援連線到新的資料庫伺服器，避免中斷使用者體驗。如果此應用程式工具尚未存在，建置可能相當昂貴。

版本相容性

大部分的應用程式作業都與 MySQL 升級相容。不過，在某些情況下，應用程式元件或資料庫使用方式只能與某些 MySQL 版本搭配使用。

請確認所有應用程式元件是否都與目標資料庫版本相容。請考慮將版本升級與重新定位或重新設定資料庫的移轉分隔開來。例如，如果從內部部署 MySQL 5.7 移轉至執行 MySQL 8.0 的「適用於 MySQL 的 Azure 資料庫」彈性伺服器，請考慮從內部部署移轉至執行 MySQL 5.7 的「適用於 MySQL 的 Azure 資料庫」彈性伺服器，然後從 5.7 升級至 8.0。

網路和安全性

資料庫移轉需要將資料從源資料庫傳輸到目標。方式和速度在很大程度上取決於兩個網路之間的連線。如果您無法從來源建立與目標的即時連線，則必須以另一種方式傳輸實體資料檔案，例如透過中繼工作站或伺服器。在此情況下，請確定您有足夠的磁碟空間，可一路將快照集儲存在每個系統上。

在移轉期間考量安全性需求也很重要。您需要適當的驗證，以及來源和目標資料庫的權限。您可能也想要建立服務帳戶，來執行部分或全部的移轉步驟，然後在完成時移除其存取權。

無論來源資料庫是內部部署還是位於另一個雲端提供者上，網路設定通常不允許外部連線。您必須設定網路以允許與 Azure 連線。

如果來源資料庫是內部部署，而且資料量很大，則透過一般網際網路連線移動數個 TB 的資料可能會非常緩慢。在此案例中，請考慮設定網路與 Azure 之間的 Azure ExpressRoute 連線。

即使您使用 ExpressRoute，其所在的連線可能也會提供其他流量，而且兩者可能會互相干擾。視爭用而定，現有應用程式和移轉流程的效能叫用可能相當重要。

效能

資料庫移轉是調整基礎結構大小來增加容量的絕佳機會。您的資料庫使用量可能受益於增加的 CPU、RAM 或 I/O 資源。

佈建目標伺服器之前，請考量您目前的資料庫使用量。監視 CPU 使用量之類的效能計量，以及預測成長和 SLA，以決定是否應該配置較大的計算大小。您可能反而會發現您的容量已過度分派，降級可節省成本。

成本

當您移轉至 Azure 時，您可以利用透明定價。 Azure 定價計算機可以使用您選取的 SKU 和其他參數 (例如備援和高可用性)，讓您在規劃期間預估移轉後的成本。您也可以使用計算機來通知取捨，例如可用性與成本之間的權衡。

業務持續性

資料庫移轉是檢閱業務持續性計量和目標的好時機。變更備份保留原則或移轉至異地備援備份或高可用性，可能會很適合。請考量您的歷程記錄可用時間，以及 SLA 和中斷復原時間。移轉也會提供從實體資料檔建立新資料庫的實際範例，以通知災害復原計劃。