本文件將說明如何設定及執行資料庫遷移程序，包括失敗情境。本文為上下兩集系列文的下集。第 1 部分：針對需要將資料庫從地端部署環境或其他雲端環境遷移至 Google Cloud的雲端架構師，介紹幾乎無停機時間資料庫遷移作業的概念、原則和術語。
設定資料庫遷移
本節將說明資料庫遷移的幾個階段。首先，您需要設定遷移作業。接著，在完成遷移並將用戶端切換至目標資料庫後，您可以移除來源資料庫，或視需要實施備用方案，以防切換後的遷移作業發生問題。備用方案有助於確保業務持續運作。
在遷移期間，您必須特別留意可能會出現的任何結構定義或資料變更。如要進一步瞭解這些變更可能造成的影響，請參閱本文件稍後的「遷移期間的動態變更」一節。
目標結構定義
您必須為每個目標資料庫系統定義及建立結構定義。針對同質資料庫遷移作業，您可以將來源資料庫結構定義匯出至目標資料庫，藉此建立目標資料庫結構定義，以便更快速地建立此規格。
命名結構定義的方式十分重要。其中一個選項是比對來源和目標結構定義名稱。不過，雖然這可簡化用戶端切換作業，但如果工具同時連線至來源和目標資料庫結構描述 (例如比較資料)，這種做法可能會讓使用者感到困惑。如果您使用設定檔來抽象化結構定義名稱，並為目標資料庫結構定義提供與來源不同的名稱，就能更輕鬆地區分結構定義。
在異質資料庫遷移作業中，您需要建立每個目標資料庫的結構定義。這項工程流程可能需要多次重複。在實作遷移作業之前，您可能需要進一步變更結構定義，以便配合遷移程序和任何資料修改作業。
由於您在測試及執行遷移作業時，可能會多次建立目標資料庫，因此建立結構定義的程序必須可重複執行 (最好是透過安裝指令碼執行)。您可以使用程式碼管理系統來控制指令碼版本、確保一致性，以及存取指令碼的變更記錄。
查詢遷移和執行語意
最後，您需要將用戶端從存取來源資料庫系統切換為存取目標資料庫系統。在同質資料庫整合中，如果結構定義未經修改，查詢就不會變更。雖然用戶端必須在目標資料庫系統上進行測試，但用戶端不必因查詢而修改。
一般來說，如果是異質資料庫遷移，您必須修改查詢，因為來源和目標資料庫的結構定義不同。差異可能是來源和目標資料庫之間的資料類型不相符。此外，來源資料庫系統可用的查詢語言功能，不一定會在目標資料庫系統中提供，反之亦然。在極端情況下，您可能需要將來源資料庫系統的查詢轉換為目標系統上的多個查詢。在相反的情況下，如果目標資料庫的查詢語言功能比來源資料庫多，您可能需要將來源資料庫中的多個查詢合併為對應目標資料庫的單一查詢。
查詢的語意也可能不同。舉例來說，某些資料庫系統會在交易中立即實現交易中的更新，因此在讀取相同資料項目時，系統會擷取更新後的值。其他系統不會立即實現更新，而是等待交易完成。如果來源資料庫系統的邏輯依賴寫入資料的實體化，目標資料庫上的相同邏輯可能會導致資料錯誤，甚至失敗。
如果您必須遷移查詢，請測試所有功能，確保用戶端在遷移前後的行為相同。您也可以在資料層級進行測試，但這類測試無法取代用戶端層級的測試。用戶端會從商業邏輯角度執行查詢，且只能在商業邏輯層級進行測試。
遷移程序
對於異質資料庫遷移作業，遷移程序會指定從來源資料庫系統擷取的資料如何修改，並插入目標資料庫。資料修改作業 (例如本文「資料變更」一節所述) 會在資料項目從來源資料庫擷取並轉移至目標資料庫時定義及執行。
對於同質資料庫遷移作業，如果來源和目標資料庫的結構定義相同，就不需要修改資料。資料會從來源資料庫擷取後，插入目標資料庫。
視資料庫遷移系統而定，您可能需要進行多項設定。舉例來說，您必須指定要修改和轉移的資料是否必須間歇性地儲存在資料庫遷移系統中。儲存資料可能會使整體遷移程序變慢，但在發生錯誤時，可大幅加快復原速度。您可能需要指定驗證類型。舉例來說，某些資料庫遷移系統會查詢來源和目標系統，以便在查詢點建立遷移資料集的等價關係。錯誤處理作業需要您指定失敗復原行為。同樣地，這項需求取決於您使用的資料庫遷移系統。
無庸置疑，您需要反覆徹底測試資料遷移作業。理想情況下，您應測試遷移作業，確保所有已知資料項目都已遷移、不會發生資料修改錯誤、效能和傳輸量足夠，且能完成遷移作業。
備用程序
在資料庫遷移期間，來源資料庫會繼續運作 (除非遷移作業涉及預定的停機時間)。如果資料庫遷移作業在任何時間點失敗，您可以在最壞的情況下中止遷移，並將目標資料庫重設為初始狀態。解決失敗問題後，您可以重新啟動資料庫遷移作業。失敗和解決方法不會影響運作中的來源資料庫系統。
如果在資料庫遷移作業完成後，用戶端已切換至目標資料庫，但仍發生失敗情形，則失敗和解決程序可能會影響用戶端，導致無法正常運作。在最佳情況下，失敗問題會迅速解決，且客戶的停機時間會縮短。在最糟的情況下，問題無法解決，或解決問題需要很長的時間，而您必須將用戶端切換回來源資料庫。
如要將用戶端切換回來源資料庫，您必須將目標資料庫的所有資料修改內容遷移回來源資料庫。您可以將此程序視為單獨的完整資料庫遷移作業，進行設定及執行。不過，由於客戶端目前無法在目標資料庫上運作，因此會造成大量停機時間。
為避免在這種情況下造成用戶端停機，您必須在原始資料庫遷移作業完成後立即啟動遷移程序。套用至目標資料庫系統的每項變更都會立即套用至來源資料庫系統。採用這種做法可確保目標和來源資料庫系統隨時保持同步。
從目標資料庫備援至來源資料庫需要大量的努力。請務必決定是否要實作及測試備用程序，或是瞭解不這麼做的後果，也就是大量停機時間。
執行資料庫遷移作業
執行資料庫遷移作業涉及五個不同的階段，本節將討論這些階段。第六個階段是備用方案，但備用方案是極端情況，並視為正常資料庫遷移執行作業的例外狀況。
本節所述的程序是幾乎不造成停機的異質資料庫遷移作業。如果您可以接受長時間的停機時間，可以使用備份和還原或匯出和匯入方法，將前三個階段 (初始載入、持續遷移和資料移除) 合併為一個階段。
同質資料庫遷移作業屬於特殊情況。透過這類遷移作業，您可以使用資料庫管理系統複製功能 (適用於支援這項功能的系統)，在來源資料庫系統仍在運作時遷移資料。
本文討論的階段概略說明瞭您可能需要根據資料庫遷移程序需求修改的方法。
階段 1：初始載入
起點是從所有來源資料庫遷移所有指定的資料。在資料遷移作業開始時，來源資料庫會處於特定狀態，且該狀態會在遷移期間變更。
在同時發生變更時開始遷移作業的訣竅，就是在擷取第一個資料項目之前，記下資料庫系統時間。有了這個時間戳記，您就能從該時間起的交易記錄中衍生出所有資料庫變更。此外，初始載入程序必須在所有資料中讀取一致的資料庫狀態。您可能需要在資料庫上設定短暫的鎖定，以免讀取不一致的資料集。
這個階段包含以下內容：
- 在資料庫遷移作業開始前記下資料庫系統時間。
- 執行初始載入遷移程序，從需要遷移的來源資料庫中查詢資料集 (完整或部分)，然後遷移資料集。在關聯式資料庫模型中，初始載入遷移程序會執行
SELECT *或含有選取或投影的查詢，或同時執行這兩種查詢。遷移程序會依照程序中指定的方式修改資料。
執行初始載入遷移程序時，用戶端通常會對來源資料庫進行變更。由於您會在開始時記錄資料庫系統時間，因此日後可以從交易記錄中衍生出這些變更。
初始載入階段的結果，就是將初始資料集從來源資料庫系統完整遷移至目標資料庫系統。不過，來源和目標資料庫尚未同步，因為用戶端可能在遷移期間修改了來源資料庫。第 2 階段則是擷取及遷移這些變更。
階段 2：繼續遷移
繼續遷移有兩個目的。首先，它會讀取在初始載入作業開始後，來源資料庫中發生的變更。第二，擷取並將這些變更轉移至目標資料庫。
這個階段包含以下內容：
- 從資料庫系統開始持續遷移程序，時間記錄在第 1 階段。遷移作業會讀取該時間點的交易記錄，並將所有變更套用至目標資料庫系統。
- 執行任何資料修改作業。遷移程序會依您指定的方式執行此步驟。
在資料庫系統時間之後記錄的變更，有時會在初始載入期間轉移。因此，在繼續遷移期間，這些變更可能會再次套用。您需要定義遷移程序，確保不會兩次套用變更，例如使用 ID。假設在初始載入期間，系統會轉移已變更的資料項目，並將該插入項目記錄在交易記錄中。只要將 ID 套用至資料項目，遷移系統就能從交易記錄判斷，由於資料項目已存在，因此不需要再插入資料。
持續遷移階段的結果是，目標資料庫與來源資料庫完全同步，或幾乎完全同步。如果來源資料庫系統中的變更未遷移，則資料庫會處於「幾乎同步」狀態。
視資料庫遷移系統的設定方式而定，差異可能會大或小。舉例來說，為了提高效率，並非所有變更都需要立即遷移，否則如果來源的變更量激增，可能會造成來源負載過重。一般來說，系統會收集變更，並以大量作業大量遷移。使用較小的批次，來源和目標之間的差異就會減少，但如果經常變更，來源可能會產生較高的負載。
如果設定了動態批次大小，建議您在持續遷移階段同步處理較大的批次，然後在資料庫幾乎同步完成時，同步處理逐漸縮小的批次。這個做法可讓追趕進度過程更有效率，並減少日後來源和目標資料庫之間的差異。
階段 3：耗盡
如要準備將用戶端從來源資料庫切換至目標資料庫，您必須確保來源資料庫和目標資料庫完全同步。「排空」是指將來源資料庫中的剩餘變更遷移至目標資料庫的程序。
這個階段包含以下內容：
- 讓來源資料庫系統處於待命狀態。這表示來源資料庫不會發生任何資料修改，且交易記錄不會收到額外的修改項目。
- 等待所有變更遷移至目標資料庫。這個程序是實際的變更排空程序。
- 排空作業完成後，請備份目標資料庫，以便日後增量備份作業有明確的起點。
在耗盡階段結束後，來源資料庫系統和目標資料庫系統會同步，且不會發生資料修改。
為確保資料耗盡，您可以將「最後插入」資料項目寫入來源資料庫。當「最後插入」資料項目出現在對應的目標資料庫中時，資料排空階段就會完成。
階段 4：切換
耗盡階段完成後，您可以將用戶端從來源切換至目標資料庫。我們建議您採取下列最佳做法：
- 在啟用正式版資料庫的存取權限前，請先測試基本功能，確保用戶端可正常運作並發揮預期功能。測試案例數量會決定正式版資料庫的實際停機時間。
- 啟用用戶端存取權之前，請先備份目標資料庫。這個最佳做法可確保目標資料庫的初始狀態可復原。
切換完成後，用戶端會全面運作，並開始存取實際工作環境資料庫 (本文件在此處稱為目標資料庫)。
階段 5：刪除來源資料庫
完成切換至正式版資料庫後，您可以刪除來源資料庫。建議您為每個來源資料庫建立最終備份，以便取得可存取的明確結束狀態。資料法規也可能基於法規遵循要求保留最終備份。
階段 6：備用方案
實作備用方案 (尤其是針對極為重要的資料庫用戶端)，可有效防範遷移作業發生問題。備用方案就像是遷移作業的反向操作。也就是說，您可以設定備援機制，從目標資料庫遷移回來源資料庫。在異質資料庫遷移作業中，備用方案會變得更複雜。因此，我們建議您徹底測試資料庫遷移程序，以及連結至目標資料庫的應用程式是否符合服務水準協議 (SLA)，再執行切換作業。
清空來源資料庫並備份所有資料庫後，您可以啟用遷移程序，找出目標資料庫中的變更，並在切換前將這些變更遷移至來源資料庫。
建立這些遷移程序可確保在用戶端對目標資料庫進行變更後，來源資料庫會同步處理，並維持最新的資料狀態。在切換後的數天或數週內，您可能需要使用備用方案。舉例來說，客戶端可能會首次存取功能，但因無法快速修正的功能故障而遭到封鎖。在這種情況下，用戶端可以切換回存取來源資料庫。在切換回用戶端之前，必須將目標資料庫的所有變更排入來源資料庫。
在這種方法中，請特別留意以下情況：
- 您必須設計目標結構定義，才能進行反向遷移 (從目標資料庫遷移至來源資料庫)。舉例來說，如果初始遷移程序 (從來源到目標) 包含了彙整或彙整，則反向遷移作業就會變得複雜，甚至無法進行。在這種情況下，個別資料也必須在目標資料庫中提供。
- 來源資料庫可能會有交易記錄，但目標資料庫不提供這類非功能性功能，因此可能會發生問題。在這種情況下，反向遷移 (從目標到來源) 必須仰賴差異查詢。您必須在目標資料庫結構定義中設計及準備該設定。
- 原本在來源資料庫上運作的用戶端必須保持可用且可運作，以便在備援情況下啟用。如要確保功能等同，請務必對存取目標資料庫的用戶端，也對存取來源資料庫的用戶端進行任何功能變更。
雖然備用機制是最後的手段，但實作備用機制至關重要，且必須視為完整的資料庫遷移作業，包括測試。
遷移期間的動態變更
一般來說，資料庫是動態系統，因為結構定義和資料值會變更。資料庫結構定義會根據業務需求等因素而變更，資料值則會隨著結構定義變更而變更，或不受結構定義變更影響。資料值變更隨時可能會發生，並與應用程式實作的對應變更相關。以下各節將討論一些可能的變更，以及這些變更對資料庫遷移作業的影響。
結構定義異動
資料庫可分為需要預先定義結構定義的系統，或不需結構定義的系統。一般來說，需要預先定義結構定義的系統會支援結構定義變更作業，例如在關聯式系統中新增屬性或欄。
在這些系統中，您可以透過變更管理程序控制變更。變更管理程序可讓您以受控的方式進行變更。任何依賴結構定義的作業 (例如查詢或資料遷移程序) 都會同時變更，以確保整體變更一致。
資料庫系統不需要預先定義的結構定義，因此可隨時變更。除了授權使用者之外，在某些情況下，系統也可以透過程式碼變更結構定義。在這些情況下，架構變更隨時可能發生。依賴結構定義的作業可能會失敗，例如查詢或資料遷移程序。為避免這些資料庫系統中發生失控的結構定義變更，您必須將變更管理程序做為慣例和接受的規則導入，而非由系統強制執行。
資料變更
一般來說，結構定義會控制各種資料屬性可用的資料值。無結構定義系統對資料值沒有任何限制。
無論是哪種情況，都可能會顯示先前未儲存的資料值。舉例來說，列舉類型通常會在資料庫系統中實作為一組字串。在程式語言層級，這些項目可能會在用戶端中實作為真正的列舉類型，但不一定如此。用戶端可能會儲存其他用戶端不認為有效的列舉值。此外，資料遷移程序可能會將其功能關閉為列舉值。如果出現新的值，資料遷移程序可能會失敗。
另一個例子是 JSON 結構的儲存方式。在許多情況下，JSON 結構會儲存在資料類型字串中；不過，這些結構會在存取時解讀為 JSON 值。如果 JSON 結構變更，資料庫系統不會偵測到這點；將字串解讀為 JSON 值的資料遷移程序可能會失敗。
遷移程序變更
在資料庫遷移作業進行期間進行變更管理相當困難且複雜，可能導致資料遷移失敗或資料不一致。建議您將必要的變更延後至資料排空階段結束，屆時來源和目標資料庫系統會同步。此時的變更會限制在目標資料庫及其用戶端 (除非也實作備用方案)。
如果您需要在資料遷移期間變更遷移程序，建議您盡量減少變更次數，並盡可能進行多項小幅變更，而非複雜的變更。此外，您可以先使用來源和目標資料庫的測試例項，測試這些變更。理想情況下，您應將實際工作環境資料載入測試來源，然後遷移至測試目標。透過這種做法，您可以驗證所提案的變更，而不會影響正在進行的實際工作環境遷移作業。測試並驗證變更後，您就可以將變更套用至正式版系統。
如要在資料遷移作業進行期間進行變更，您必須能夠停止資料遷移系統並重新啟動，並且可能需要修改資料遷移程序。在這種情況下，您不必從一開始就進行初始資料載入階段。如果資料遷移系統支援測試遷移執行功能，您也可以使用這項功能。
建議您在資料遷移期間避免變更結構定義、資料值或資料遷移程序。如果您必須進行變更，建議您從頭開始重新遷移資料，確保您有明確的起始狀態。無論如何，您都必須使用實際資料進行測試，並在套用變更前備份資料庫，以便在需要時將整個系統重設為一致狀態。
遷移失敗的因應措施
資料庫遷移期間可能會發生非預期的問題。以下列出幾個可能需要事先規劃的領域：
- 傳輸量不足。即使進行工作負載測試，遷移系統仍可能缺乏足夠的傳輸量。這類問題可能有多種原因，例如來源資料庫變更的費率異常增加，或是網路節流。您可以為這種情況做好準備，為所有相關元件準備額外的資源，以便動態擴大或擴展。
- 資料庫不穩定。來源資料庫或目標資料庫可能會出現不穩定的情況，導致資料遷移程序速度變慢，或間歇性地無法存取。資料遷移程序可能需要經常復原。在這種情況下，有意進行 HA 或 DR 切換可能會解決問題。切換作業會變更非功能性環境 (機器和儲存空間)，或許有助於緩解問題。在這種情況下，您需要測試切換和資料庫遷移復原程序，確保切換不會導致目標資料庫中的資料不一致。
- 交易記錄檔案大小用盡。在某些情況下，交易記錄會儲存在有上限的檔案中。可能會達到這個上限，導致資料庫遷移作業失敗。請務必瞭解資料庫系統的哪些部分可動態重新設定，以便解決資源限制問題。如果無法動態設定特定方面，就必須謹慎決定初始大小。
您越能讓事前測試更貼近實際情況並完整進行，就越有可能事先發現潛在問題並加以解決。