移轉考量事項

  • 24 分鐘

在內部部署中執行的商務系統可以具有與在相同環境中運作之其他服務結合的架構。 請務必了解您想要遷移的系統，以及您的組織目前使用的其他應用程式和服務之間的關聯性。

在您的技術新創公司中，供應商資料庫是用來確保元件一律有庫存，並可在製造過程中即時送達以供使用。 庫存控制器會使用行動裝置，在託運物抵達時更新此資料庫，而買方會使用網站來監視庫存量，並找出最佳的訂購時間。 管理員會使用一套業務關鍵報表來監視流程並提升效率。 您想要確保所有使用者都不會受到移轉至 Azure 的負面影響。

在此，您將了解如何規劃和執行將資料庫順暢地移轉至雲端。

調查相依性

在較複雜的系統中，元件很少完全獨立地運作。 相反地，它會呼叫其他處理序和元件。 例如，資料庫可能依存於託管使用者帳戶的目錄服務。 當您將資料庫移至雲端時，是否可以存取該目錄服務？ 若否，使用者將如何登入？ 當您忽略像這樣的相依性時，資料庫可能會出現完全失敗的情況。

若要降低風險，請檢查資料庫是否相依於以下服務：

  • 目錄服務，例如 Active Directory。
  • 安全性主體的其他存放區。
  • 其他資料庫。
  • Web API 或其他網路服務。

另請記住，其他元件可能相依於您的資料庫。 如果您未重新設定相依元件就移動資料庫，會有什麼後果？ 例如，如果移動了產品類別目錄資料庫，但對外公開的網站依賴該資料庫來判斷要呈現給使用者的產品，那麼移動是否會導致服務中斷？

查看是否有任何一種元件類型依賴您的資料庫：

  • 網站和 Web API。
  • 用戶端應用程式，例如行動應用程式和桌面軟體。
  • 其他資料庫。
  • 報告。
  • 資料倉儲。

若要進行這些檢查，請與每個資料庫和系統元件相關的關係人、系統管理員和開發人員溝通。 如果沒有把握自己是否了解系統的行為，請參閱文件，並考慮執行測試，例如網路擷取作業，並觀察該行為。

準備回復

在任何移轉專案的過程中，都一定要為失敗做好準備。 在雲端的資料庫移轉專案中，最糟的可能性是新的資料庫無法使用，而使用者無法進行工作。 這種情況可能會對公司獲利造成很大的影響，因而降低此風險的常見做法是規劃復原至原始且未經修改的內部部署資料庫。

對於回復方案，請考慮：

  • 如何確保您可以回復至未受到移轉失敗影響的資料庫？ 例如，非常建議您在開始移轉之前，進行完整的資料庫備份。
  • 如果需要進行回復作業，最久可接受多長時間的資料庫離線？
  • 為回復方案準備了多少預算？ 例如，是否負擔得起將資料庫複寫到專用的回復伺服器？ 如果可以，即可在移轉之前關閉此伺服器。 若要回復，請啟動此伺服器。 您會立即擁有不受移轉影響的資料庫，完全不需要將其從備份還原。

離線移轉與線上移轉

若要移轉資料庫，至少有兩種選項：

注意

資料移轉服務中的 MySQL 資料庫目前無法使用線上選項。

  • 暫停系統、移轉資料庫，然後重新設定系統後重新啟動，以使用新的資料庫。 此為離線移轉。
  • 當您將資料庫移至新的位置時，維持系統在運作中。然後在進行移轉時，將針對原始資料庫執行的交易向前復原至新的資料庫。之後將您的應用程式切換為連線到新的資料庫。 此為線上移轉。

執行離線移轉較為簡單，這是因為進行移轉時，使用者無法變更資料。 但是，如果您的資料庫使用頻繁，或是對貴組織的成功具有關鍵性地位，就可能無法這麼做。

離線移轉

假設您的資料庫支援某個分析師團隊，而他們在正常上班時間內，全都在單一時區工作。 該團隊通常不會在週末工作。 在星期五晚上 6:00 到星期日上午 9:00 之間，通常不會使用到資料庫。

在這種情況下，即可依照下列步驟，在週末進行離線移轉：

  1. 星期五晚間完成所有交易之後，將資料庫離線。
  2. 對資料庫進行完整備份或匯出。
  3. 關閉內部部署伺服器並保留它，供回復之用。
  4. 在目標雲端系統上還原資料庫。
  5. 上線目標系統。
  6. 將用戶端重新設定為連線到雲端資料庫。

在這種情況下，因為可以有很長的一段時間能讓服務中斷，但對使用者的影響卻很小，所以離線移轉是可行的。 在這段期間，您可以執行資料庫的完整備份與還原，同時能確保不會遺漏任何一項變更。

線上移轉

現在請考慮另一個支援業務人員的應用程式資料庫。 業務人員分佈在世界各地，而且週末也會工作。 一直很頻繁地使用資料庫，且沒有任何活動量低的時候，如果您讓資料庫離線一段很長的時間，將會影響到使用者。 銷售活動為業務關鍵，因此服務中斷將會直接影響組織的損益底線。

在這類情況下，請考慮執行線上移轉。 在線上移轉作業中，停機時間僅限於切換至新資料庫所需的時間。 使用 Azure 資料移轉服務之類的工具來執行線上移轉。 線上移轉和離線移轉有下列差異：

  • 進行備份或匯出之前，不會將原始資料庫變成離線狀態。
  • 進行移轉時，變更會套用至舊的資料庫。
  • 移轉工具可確保在切換之前，能將這些變更複製到新的資料庫。 這通常是藉由將舊資料庫重新設定為會將變更複寫至新的資料庫來達成。

應用程式移轉

移轉資料庫之後，切換到新系統以及更新應用程式以使用新資料庫的方法與時機為何？ 您可以：

  • 逐一將應用程式移至新的資料庫。
  • 移動一部分的使用者。
  • 採用這兩種方法的組合。

其目的是要讓您以小階段的方式來執行應用程式移轉，如果發生問題，可以輕鬆地復原。 無論您是否已遵循離線或線上方法來進行資料庫移轉，仍應保有位於原始來源的工作設定。 理論上，您應該能夠快速地切換回原始來源。 但是，如果資料經常變更，就必須考量這些變更的發生處。

  • 在離線移轉過程中，來源與目的地彼此獨立。 因此，使用者和應用程式可能不會再看到一致的資料檢視。 在交易式系統中，這種情況可能令人無法接受。 這時候，您必須在兩個系統都保持存留的情況下，在資料庫之間維持某種形式的雙向複寫。 或者，如果應用程式的目的是要產生月報表或週報表、產生銷售預測，或是執行其他統計作業，則這種不一致的現象可能沒什麼關係。 這類應用程式會以「長遠的角度」看待資料，而非依賴於最新資料。 若是需要最新資料的情況下，交易式應用程式會使用新的資料庫，而報表應用程式的移動速度會慢得多。
  • 在線上移轉作業中，新的資料庫通常會透過某種複寫形式，與舊的資料庫保持同步。 複寫流程可能非同步，因此可能會有延遲。 但對新資料庫所做的資料變更，將不會傳播回舊資料庫，因而可能會導致衝突。 而對舊資料庫執行的應用程式，可能會對新資料庫中已修改的資料進行衝突變更。 複寫會盲目地覆寫新資料庫中的變更，因而造成「遺失更新」。

測試方法

如果資料庫在您的業務中扮演重要角色，失敗的後果可能會有大範圍的影響。 為避免發生失敗，請考慮針對已移轉的資料庫執行效能測試，以確保它能應付使用者可能會加諸在該資料庫的負載，並快速回應。 請記住，當需求大幅高於平常時，可能會出現尖峰活動期間。 您必須確定已移轉的系統能處理預計會出現的工作負載。

在允許使用者存取資料庫之前，請務必對的新資料庫執行某種類型的迴歸測試。 這些測試會驗證系統的行為與功能是否正確。

此外，也應該考慮執行「浸泡測試」(soak test)。 浸泡測試是一種負載測試，其設計目的是要查看整個系統如何在壓力下運作。 浸泡測試會對新的資料庫施加壓力，並判斷它在高需求下是否穩定。 浸泡測試會執行一段很長的時間，以查看高需求持續時所發生的情況。

當您確定新系統穩定之後，即可開始移轉使用者。 但有可能會需要額外的保證，才可讓使用者接受新系統。 此時，您可能會考慮「金絲雀測試」(canary testing)。 金絲雀測試會以透明的方式將一小部分的使用者導向至新的系統，但他們並不知道自己正在使用新系統。 它是一種盲測形式，目的是要讓您找出新系統的任何問題。 監視這些使用者的回應，並進行任何所需的調整。

維護平行系統

您可能會因為下列幾種原因，而選擇平行執行舊的內部部署資料庫與新的雲端資料庫：

  • 測試期間。 如前一個主題中所述，最好先針對已移轉的資料庫執行金絲雀測試，以評估其功能、穩定性和容量，然後再使用該資料庫來支援人員。 如果新系統發生問題，以平行方式維護的內部部署系統，可讓您能快速地將使用者還原到舊系統。

  • 階段式移轉。 降低非預期的失敗對生產環境造成影響的其中一種方法是，先將少數使用者移往新的系統，並監視結果。 如果一切執行順利，即可在對新資料庫深具信心時，移動其他使用者群組。 您可以依字母順序、部門、位置或角色來移動使用者，直到全部都使用新資料庫為止。

  • 分次移轉。 另一種方法是依工作負載而非依使用者，分段進行移轉。 例如，您可以先移轉支援人力資源的資料庫資料表，然後再移轉支援業務人員的資料庫資料表。

所有這些情況下，舊的內部部署資料庫都會與新的雲端資料庫平行執行一段時間。 您必須確保對舊資料庫所做的變更，也會套用至新的資料庫，反之亦然。 您可以編寫指令碼進行此同步處理，或使用 Azure 資料移轉服務之類的工具。

如果決定要維持平行資料庫並同步變更，請自問下列問題：

  • 衝突解決方案。 對內部部署資料列所做的變更，與對雲端中相同資料列進行不同的變更，是否可能會在差不多的時間發生？ 如此會造成衝突，不清楚應保留哪一項變更。 您會如何解決這樣的衝突？

  • 網路流量。 在資料庫之間同步處理變更時，會產生多少網路流量？ 您是否有足夠的網路容量可用於此流量？

  • 延遲。 當其中一個資料庫有變更時，在該變更到達另一個資料庫之前，可接受多長的延遲 (如果有的話)？ 例如，在產品類別目錄中，在讓所有使用者皆可看見新產品前，您可能最多可以等待一天。 但是，如果資料庫包含重要的交易資訊 (例如貨幣匯率)，如果不立即進行同步處理的話，也應更頻繁地同步處理該資料。

分次移轉

分次移轉是將完整系統分割成分批的工作負載，一次遷移一個工作負載。

多個資料庫

複雜的系統可能包含支援數個工作負載的多個資料庫。 例如，人力資源可能會使用 StaffDB 資料庫，而業務團隊可能會有會查詢 ProductCatalogDB 資料庫與 OrdersDB 資料庫的行動應用程式。

當然，您可以選擇一次將整個資料庫系統遷移到雲端。 這樣可能會比較簡單，因為您不需要在內部部署和雲端中同時執行資料庫。 不需要考慮這些資料庫在移轉期間的通訊。 但失敗的風險會比較高。 出現單一問題可能會同時影響人力資源團隊和業務團隊。

請考慮執行分次移轉，一次移動一個工作負載，來減輕中型和大型資料庫系統的風險。 在此範例中，可能會考慮要先移轉 StaffDB 資料庫，因為與失敗相關的問題僅限於人力資源團隊，而不會讓您無法接訂單。 解決 StaffDB 移轉所發生的h所有問題，而藉此可了解適用於其他工作負載移轉的經驗。

接下來，可以考慮將產品類別目錄工作負載移轉至雲端。 如果要這麼做，請考慮下列問題：

  • 如何確保新增加至目錄的產品可供訂購？
  • 是否需要與 OrdersDB 資料庫同步處理仍保留在內部部署資料庫中的任何資料？
  • 新產品從產品類別目錄抵達 OrdersDB 資料庫可接受多長時間的延遲？

單一資料庫分次移轉

即使您只有單一資料庫來支援所有的工作負載，仍可考慮分次移轉。 例如，可以將資料庫分割成以下片段：

  • 支援 HR 作業的資料表。
  • 支援業務人員的資料表。
  • 支援分析和報表的資料表。

如果先移轉了 HR 作業的資料表，則發生的任何問題只會影響 HR 人員。 業務人員和資料分析師會繼續運用舊的資料庫，而不會中斷。

執行分次移轉之前，必須完全了解資料庫，以及應用程式如何使用這些資料庫。 例如，資料庫中的某些資料表，可能同時支援銷售和報表。 這表示會無法完全分割工作負載。 必須在內部部署和雲端資料庫之間同步處理這些資料表，直到所有的工作負載都已移轉為止。

安全性考量

您的資料庫可能包含敏感性資料，例如產品詳細資料、員工個人資訊與付款詳細資料，因此安全性永遠是高優先順序。 您必須決定如何在移轉期間和新資料庫中保護此資料。

防火牆保護

在連線到網際網路的應用程式中，資料庫伺服器通常受到至少兩個防火牆的保護。 第一個防火牆會將網際網路與前端伺服器分開，例如，如果這些伺服器代管網站或 Web API。 外部防火牆上只應開啟 TCP 通訊埠 80，但必須對所有來源 IP 位址開啟此連接埠，但封鎖的位址除外。

第二個防火牆會將前端伺服器與資料庫伺服器區隔開。 建議在外界不知道的私人連接埠號碼上，發佈資料庫服務。 在第二個防火牆上，僅針對前端伺服器的 IP 位址，開放此連接埠號碼。 此安排可避免惡意的網際網路使用者，直接與資料庫伺服器通訊。

如果您打算將資料庫伺服器遷移至 Azure 虛擬機器，請使用虛擬網路搭配網路安全性群組 (NSG) 來複寫防火牆規則。 如果您使用適用於 MySQL 的 Azure 資料庫、適用於 MariaDB 的 Azure 資料庫或適用於 PostgreSQL 的 Azure 資料庫，您可以使用 Azure 入口網站中適用於該伺服器的 [連線安全性] 頁面，建立防火牆規則以保護資料庫。

驗證和授權

對大多數的資料庫而言，需要密切控制誰存取及修改哪些資料。 此控制會在使用者連線到資料庫時，要求對該使用者進行積極的識別。 此程序稱為驗證，通常是透過使用者名稱和密碼來完成。 MySQL、MariaDB 和 PostgreSQL 等資料庫系統會提供自己的驗證機制。 當您將系統遷移至雲端時，必須確保安全地持續驗證使用者。

注意

適用於 MySQL 的 Azure 資料庫、適用於 MariaDB 的 Azure 資料庫和適用於 PostgreSQL 的 Azure 資料庫服務會模擬傳統的 MySQL、MariaDB 和 PostgreSQL 驗證。

當您知道使用者是誰時，必須將權限指派給他們，才能完成工作中的任務。 此程序稱為授權。

對於資料庫移轉專案，您必須確定使用者已在雲端資料庫中正確獲得授權：

  1. 找出使用者帳戶儲存在內部部署系統中的位置。 在 MySQL 中，使用者帳戶通常會儲存在資料庫的 user 資料表中 mysql，但也有可能與儲存在 Active Directory 中的使用者帳戶整合。

  2. 取得所有使用者帳戶的清單。 例如，在 MySQL 中，您可以使用此命令：

    SELECT host, user FROM mysql.user;

  3. 針對每個使用者帳戶，找出他們對資料庫的存取權。 例如，在 MySQL 中，您可以將此命令用於 dbadmin@on-premises-host 使用者帳戶：

    SHOW GRANTS FOR 'dbadmin'@'on-premises-host';

  4. 在雲端資料庫中重新建立每個使用者帳戶。 例如，在 MySQL 中，您可以使用此命令來建立新的帳戶：

    CREATE USER 'dbadmin'@'cloud-host'

  5. 授權每個使用者帳戶存取雲端資料庫中的正確存取層級。 例如，在 MySQL 中，您可以使用此命令來允許使用者存取完整的資料庫：

    GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'

加密

透過網路傳送資料時，可能會遭受所謂的「中間人」攻擊攔截。 為了避免這種情況，適用於 MySQL 的 Azure 資料庫、 適用於 MariaDB 的 Azure 資料庫和適用於 POSTGRESQL 的 AZURE 資料庫都支援安全通訊端層 (SSL) 來加密通訊。 預設會強制執行 SSL，強烈建議您不要變更此設定。

您可能需要修改用戶端應用程式的連線設定，才能使用 SSL 加密。 與開發人員討論此主題，判斷所需的變更 (如果有的話)。

監視和管理

在規劃移轉資料庫時，也必須考慮資料庫管理員在移轉後將如何繼續執行其工作。

監視

內部部署資料庫管理員習慣於定期進行監視，找出像是硬體瓶頸或網路存取爭用等問題。 他們會進行監視，以確保在生產力受到影響之前，可以修正所有問題。 您可以預期任何未定期監視的資料庫遲早會開始造成問題。

所以應該對雲端資料庫採取相同的方式。 但應可更輕鬆地解決 PaaS 系統 (例如 Azure) 中的問題，因為無須購買、設置和設定任何硬體，即可新增資源。 但您仍需要找出開發時的問題，因此監視在日常工作中是高優先順序的工作。

將資料庫遷移至雲端之前，請找出您的管理員目前使用的監視工具。 如果這些工具與您提議的雲端式解決方案相容，您可能只需要將它們重新連接到已遷移的資料庫。 如果不相容，則必須調查替代方案。

請記住，Azure 包含一組效能監視工具，並會收集各種效能計數器和記錄資料。 您可以藉由設定 Azure 監視器，使用 Azure 入口網站中的儀表板和圖表來顯示此資料。 您可以建立自訂圖表、資料表和報表，專門為您的管理員需求而設計。

管理

您的資料庫管理員會使用慣用的工具來變更內部部署資料庫的結構描述和內容。 如果他們在移轉後使用相同的工具，您可以繼續受益于他們的專業知識。 首先，請評估現有的工具集是否與建議的雲端託管資料庫相容。 許多工具都是相容的，因為它們是以廣泛採用的標準 (例如 SQL) 為基礎，但請務必確認相容性。 如果目前的管理工具在移轉後無法運作，請嘗試與您的管理員找出替代方案。

Azure 包含數個工具，可讓您用來管理 MySQL、MariaDB 和 PostgreSQL 資料庫：

  • Azure 入口網站。 此網站有強大的設施，可讓您用於設定、監視及管理資料庫，以及在 Azure 雲端中可能建立的所有其他資源。

  • Azure PowerShell。 此為指令碼執行環境與語言，擁有一系列豐富的命令。 使用適用於 Windows 和 Linux 環境的 PowerShell，可將複雜的資料庫管理工作自動化。

  • Azure CLI。 此為 Azure 的命令列介面。 其可用於來管理 Azure 中的服務與資源。 您可以從 Windows 和 Linux Shell 環境使用 CLI，也可以從 Bash 指令碼中使用。