本文件針對從地端部署環境或其他雲端環境，將資料庫遷移至 Google Cloud 的雲端架構師，介紹幾乎零停機時間的資料庫遷移作業概念、原則、術語和架構。
本文件為兩部分中的第 1 部分。第 2 部分將討論設定及執行遷移程序，包括失敗情況。
資料庫遷移是指使用資料庫遷移服務，將資料從一或多個來源資料庫遷移至一或多個目標資料庫的程序。遷移完成後，來源資料庫中的資料集會完整地 (但可能會重新結構化) 位於目標資料庫中。接著，存取來源資料庫的用戶端會切換至目標資料庫，而來源資料庫則會關閉。
下圖說明這個資料庫遷移程序。
本文將從架構角度說明資料庫遷移作業：
- 資料庫遷移作業涉及的服務和技術。
- 同質與異質資料庫遷移的差異。
- 遷移停機時間容許值的取捨與選擇。
- 設定架構，可在遷移期間發生意外錯誤時提供備用方案。
本文件不會說明如何設定特定資料庫遷移技術。而是以基礎、概念和原則的角度介紹資料庫遷移。
架構
下圖為一般資料庫遷移架構。
資料庫移轉服務會在 Google Cloud 中執行，並同時存取來源和目標資料庫。這裡有兩種變化版本：(a) 顯示從地端資料中心或遠端雲端的來源資料庫，遷移至 Spanner 等受管理的資料庫；(b) 則是顯示遷移至 Compute Engine 上的資料庫。
雖然目標資料庫的類型 (受管理和未受管理) 和設定不同，但兩者的資料庫遷移架構和設定都相同。
術語
這些文件最重要的資料遷移術語定義如下：
來源資料庫：包含要遷移至一或多個目標資料庫的資料。
目標資料庫：接收從一或多個來源資料庫遷移的資料的資料庫。
資料庫遷移：將資料從來源資料庫遷移至目標資料庫，目標是在遷移作業完成後關閉來源資料庫系統。整個資料集或子集都會遷移。
同質遷移：從來源資料庫遷移至目標資料庫，且來源和目標資料庫皆為相同供應商提供的資料庫管理系統。
異質遷移：從來源資料庫遷移至目標資料庫，且來源和目標資料庫採用不同供應商的不同資料庫管理系統。
資料庫移轉系統：可連線至來源資料庫和目標資料庫，並執行從來源資料庫到目標資料庫的資料遷移作業的軟體系統或服務。
資料遷移程序：資料遷移系統執行的已設定或已實作的程序，用於將資料從來源傳送至目標資料庫，並可能在傳輸期間轉換資料。
資料庫複製：從來源資料庫持續將資料傳輸至目標資料庫，但不以關閉來源資料庫為目標。資料庫複製 (有時稱為「資料庫串流」) 是一個持續進行的程序。
資料庫遷移的分類
資料庫遷移有不同類型，屬於不同類別。本節將說明定義這些類別的條件。
複製與遷移
在資料庫遷移作業中，您會將資料從來源資料庫移至目標資料庫。資料完全遷移後，您可以刪除來源資料庫，並將用戶端存取權重新導向至目標資料庫。有時，如果您在目標資料庫中遇到無法預料的問題，可以將來源資料庫保留做為備用措施。不過，在目標資料庫可靠運作後，您最終會刪除來源資料庫。
相較之下，使用資料庫複製功能，您可以持續將資料從來源資料庫傳輸至目標資料庫，而無須刪除來源資料庫。有時資料庫複製作業又稱為資料庫串流。雖然有定義的開始時間，但通常不會定義完成時間。複製作業可能會停止或變成遷移作業。
本文件僅討論資料庫遷移。
部分遷移與完整遷移
資料庫遷移是指完整且一致的資料轉移作業。您可以將要轉移的初始資料集定義為完整資料庫或部分資料庫 (資料庫中的資料子集)，以及之後在來源資料庫系統中提交的所有變更。
異質遷移與同質遷移
同質資料庫遷移是指使用相同資料庫技術的來源資料庫和目標資料庫之間的遷移作業，例如從 MySQL 資料庫遷移至 MySQL 資料庫，或是從 Oracle® 資料庫遷移至 Oracle 資料庫。同質遷移也包括從自行代管的資料庫系統 (例如 PostgreSQL) 遷移至代管版本 (例如 PostgreSQL 適用的 Cloud SQL 或 PostgreSQL 適用的 AlloyDB)。
在同質資料庫遷移作業中，來源和目標資料庫的結構定義可能相同。如果結構定義不同，則在遷移期間必須轉換來源資料庫的資料。
異質資料庫遷移是指在不同資料庫技術的來源和目標資料庫之間進行遷移，例如從 Oracle 資料庫遷移至 Spanner。異質資料庫遷移作業可在相同資料模型之間進行 (例如從關聯資料轉換為關聯資料)，也可以在不同資料模型之間進行 (例如從關聯資料轉換為鍵/值資料)。
在不同資料庫技術之間遷移資料時，不一定會涉及不同的資料模型。舉例來說，Oracle、MySQL、PostgreSQL 和 Spanner 都支援關聯式資料模型。不過，Oracle、MySQL 或 PostgreSQL 等多模組資料庫支援不同的資料模型。資料儲存在多模型資料庫中以 JSON 文件格式儲存，可遷移至 MongoDB，且轉換作業所需的時間很短，甚至不需要轉換，因為來源和目標資料庫的資料模型相同。
雖然同質和異質遷移的差異取決於資料庫技術，但另一種分類方式則是根據相關資料庫模型進行。舉例來說，如果資料庫和 Spanner 都使用關聯資料模型，從資料庫遷移至 Spanner 的作業就屬於同質遷移；如果資料庫和 Spanner 使用不同資料模型，例如在 Oracle 中以 JSON 物件儲存的資料，遷移至 Spanner 中的關聯資料模型，就屬於異質遷移。
依據資料模型分類遷移作業，比起依據相關資料庫系統分類，更能準確表達遷移資料所需的複雜度和工作量。不過，由於業界常用的分類方式是根據相關資料庫系統，因此後續各節都會以此區分。
遷移作業的停機時間：零、最少或大量
成功將資料集從來源遷移至目標資料庫後，請將用戶端存取權切換至目標資料庫，然後刪除來源資料庫。
將用戶端從來源資料庫切換至目標資料庫時，需要進行多個程序：
- 如要繼續處理，用戶端必須關閉與來源資料庫的現有連線，並建立與目標資料庫的新連線。理想情況下，關閉連線時會以優雅的方式進行，也就是說，您不會不必要地回復進行中的交易。
- 關閉來源資料庫的連線後，您必須將剩餘的變更從來源資料庫遷移至目標資料庫 (稱為「排空」)，以確保所有變更都已擷取。
- 您可能需要測試目標資料庫，確保這些資料庫正常運作，且用戶端能夠正常運作，並在其定義的服務等級目標 (SLO) 範圍內運作。
在遷移期間，不可能讓用戶端完全不停機，因為有時用戶端無法處理要求。不過，您可以透過多種方式盡量縮短用戶端無法處理要求的時間 (幾乎沒有停機時間)：
- 您可以在切換用戶端之前，以唯讀模式啟動用於目標資料庫的測試用戶端。採用這種方法時，測試會與遷移作業同時進行。
- 在切換期間即將結束時，您可以將遷移的資料量 (也就是在來源和目標資料庫之間傳輸的資料量) 設為盡可能少。由於來源資料庫和目標資料庫之間的差異較少，因此這個步驟可縮短資料流出時間。
- 如果在目標資料庫上運作的全新用戶端可以與在來源資料庫上運作的現有用戶端同時啟動，您就能縮短切換時間，因為新用戶端可在所有資料都排空後立即執行。
雖然在切換期間達到零停機時間是不可能的，但您可以盡可能同時啟動活動，並持續進行資料遷移作業，以便盡量減少停機時間。
在某些資料庫遷移情境中，您可以接受較長的停機時間。通常，這項額度是基於業務需求而設定。在這種情況下，您可以簡化做法。舉例來說，如果是同質資料庫遷移作業，您可能不需要修改資料；匯出及匯入或備份及還原都是理想的做法。在異質遷移作業中，資料庫遷移系統不必在遷移期間處理來源資料庫系統的更新。
不過，您必須確保可接受的停機時間足夠長，以便進行資料庫遷移作業和後續測試。如果無法明確建立這段停機時間，或停機時間過長，您就必須規劃出最能減少停機時間的遷移作業。
資料庫遷移基數
在許多情況下，資料庫遷移作業會在單一來源資料庫和單一目標資料庫之間進行。在這種情況下，基數為 1:1 (直接對應)。也就是說，來源資料庫會以不變的方式遷移至目標資料庫。
不過，直接對應並非唯一選項。其他基數包括：
- 合併 (n：1)。在合併作業中，您會將資料從多個來源資料庫遷移至較少數量的目標資料庫 (甚至是單一目標)。您可以使用這種方法簡化資料庫管理作業，或採用可擴充的目標資料庫。
- 分發 (1:n)。在分發中，您會將資料從一個來源資料庫遷移至多個目標資料庫。舉例來說，如果您需要將含有區域資料的大型集中式資料庫遷移至多個區域目標資料庫，就可以使用這種方法。
- 重新分配 (n：m)。在重新分配中，您會將資料從多個來源資料庫遷移至多個目標資料庫。如果您有分割的來源資料庫，且分割區大小差異極大，可以使用這種方法。重新分配會將分割資料平均分配至幾個代表分割資料的目標資料庫。
除了遷移資料，資料庫遷移作業還可讓您重新設計及實作資料庫架構。
遷移作業一致性
資料庫遷移作業應保持一致。在遷移作業的脈絡中，「一致」的意思是：
- 完成。所有指定要遷移的資料都會實際遷移。指定的資料可以是來源資料庫中的所有資料，或是資料的子集。
- 不重複。每個資料都只會遷移一次。不會將重複資料導入目標資料庫。
- 已排序。來源資料庫中的資料變更會以與來源資料庫相同的順序套用至目標資料庫。這一點對於確保資料一致性至關重要。
另一種描述遷移一致性的說法是，在遷移作業完成後，來源和目標資料庫之間的資料狀態是相同的。舉例來說，在同質遷移作業中，如果涉及關聯資料庫的直接對應，來源和目標資料庫中必須存在相同的資料表和資料列。
這種描述遷移一致性的替代方式非常重要，因為並非所有資料遷移作業都會依序將來源資料庫中的交易套用至目標資料庫。舉例來說，您可以備份來源資料庫，然後使用備份將來源資料庫內容還原至目標資料庫 (當可能發生重大停機時)。
主動/被動與雙主動遷移
一個重要的差異點是，來源和目標資料庫是否都開放修改查詢處理作業。在主動/被動資料庫遷移作業中，來源資料庫可在遷移期間進行修改，而目標資料庫則僅允許唯讀存取。
主動-主動遷移可在遷移期間支援用戶端同時寫入來源和目標資料庫。在這種遷移作業中，可能會發生衝突。舉例來說，如果來源和目標資料庫中的相同資料項目經過修改，導致在語意上彼此衝突，您可能需要執行衝突解決規則來解決衝突。
在主動-主動遷移作業中，您必須能夠使用衝突解決規則解決所有資料衝突。如果無法這樣做，資料可能會不一致。
資料庫遷移架構
資料庫遷移架構會說明執行資料庫遷移作業所需的各種元件。本節將介紹一般部署架構，並將資料庫遷移系統視為個別元件。並討論資料庫管理系統的功能，說明如何支援資料遷移作業，以及許多用途中重要的非功能性屬性。
部署架構
資料庫遷移作業可在任何環境 (例如內部部署或不同雲端) 的來源和目標資料庫之間進行。每個來源和目標資料庫都可以位於不同的環境中，不一定要全部位於相同的環境中。
下圖顯示涉及多個環境的部署架構範例。
DB1 和 DB2 是兩個來源資料庫，而 DB3 和 Spanner 則是目標資料庫。這項資料庫遷移作業涉及兩個雲端和兩個內部部署的資料中心。箭頭代表叫用關係：資料庫移轉服務會叫用所有來源和目標資料庫的介面。
這裡未討論的特殊情況是將資料從一個資料庫遷移至相同的資料庫。這種特殊情況僅會使用資料庫遷移系統進行資料轉換，不會在不同環境的不同系統之間遷移資料。
基本上，資料庫遷移有三種方法，本節將討論以下三種方法：
- 使用資料庫遷移系統
- 使用資料庫管理系統複製功能
- 使用自訂資料庫遷移功能
資料庫遷移系統
資料庫遷移系統是資料庫遷移的核心。系統會執行從來源資料庫執行實際資料擷取作業，將資料傳輸至目標資料庫，並視需要在傳輸期間修改資料。本節將概略說明基本資料庫遷移系統功能。資料庫遷移系統的例子包括 資料庫遷移服務、Striim、Debezium、tcVision 和 Cloud Data Fusion。
資料遷移程序
資料庫遷移系統的核心技術構成要素是資料遷移程序。資料遷移程序是由開發人員指定，並定義要從中擷取資料的來源資料庫、要將資料遷移至的目標資料庫，以及在遷移期間套用至資料的任何資料修改邏輯。
您可以指定一或多個資料遷移程序，並根據遷移需求依序或同時執行這些程序。舉例來說，如果您要遷移獨立的資料庫，則可並行執行相對應的資料遷移程序。
資料擷取和插入
您可以透過兩種方式偵測資料庫系統中的變更 (插入、更新、刪除)：以資料庫為基礎的變更資料擷取 (CDC)，以及使用資料庫管理系統的查詢介面，對資料本身進行差異查詢。
以交易記錄為基礎的 CDC
資料庫支援的 CDC 是根據與查詢介面分開的資料庫管理功能。其中一種方法是根據交易記錄檔 (例如 MySQL 中的二進位記錄檔)。交易記錄會以正確順序記錄對資料所做的變更。交易記錄會持續讀取，因此可觀察到每項變更。對於資料庫遷移作業而言，這類記錄非常實用，因為 CDC 可確保每個變更都會顯示，並且會以正確的順序遷移至目標資料庫，不會遺漏任何資料。
在資料庫管理系統中擷取變更時，CDC 是首選方法。CDC 已內建於資料庫中，對系統的負載影響最小。
差異查詢
如果沒有資料庫管理系統功能可支援以正確順序觀察所有變更，您可以改用差異查詢。在這個做法中，資料庫中的每個資料項目都會取得額外的屬性，其中包含時間戳記或序號。每次變更資料項目時，系統都會新增變更時間戳記或增加序號。輪詢演算法會讀取自上次執行或上次使用的序號以來的所有資料項目。輪詢演算法判斷變更後，就會將目前時間或序號記錄到內部狀態，然後將變更傳遞至目標資料庫。
雖然這個方法適用於插入和更新作業，但您必須謹慎設計刪除作業，因為刪除作業會從資料庫中移除資料項目。資料刪除後，輪詢器就無法偵測到刪除作業。您可以使用額外的狀態欄位 (邏輯刪除標記) 來實作刪除作業，該欄位會指出資料已刪除。或者，您也可以將已刪除的資料項目收集到一個或多個資料表中，然後由輪詢器存取這些資料表，判斷是否已刪除。
如要瞭解差異查詢的變化版本，請參閱「變更資料擷取」。
差異查詢是最不建議的方法，因為這涉及結構定義和功能變更。查詢資料庫也會增加與執行用戶端邏輯無關的查詢負載。
轉接器和代理程式
資料庫遷移系統需要存取來源和資料庫系統。轉接器是封裝存取功能的抽象項目。最簡單的情況下，轉接程式可以是 JDBC 驅動程式，用於將資料插入支援 JDBC 的目標資料庫。在較複雜的情況下，轉接器會在目標環境 (有時稱為「代理程式」) 中執行，存取記錄檔等內建資料庫介面。在更複雜的情況下，轉接程式或代理程式會與另一個軟體系統介接，而該系統會進一步存取資料庫。舉例來說，代理程式會存取 Oracle GoldenGate，而後者會存取 Oracle 資料庫。
存取來源資料庫的轉接程式或代理會實作 CDC 介面或差異查詢介面，這取決於資料庫系統的設計。無論是哪種情況，轉接器或代理程式都會將變更提供給資料庫遷移系統，而資料庫遷移系統不會知道變更是否已由 CDC 或差異查詢擷取。
資料修改
在某些用途中，資料會從來源資料庫遷移至目標資料庫，且不會經過修改。這些直通遷移作業通常是同質的。
不過，許多用途都需要在遷移程序中修改資料。通常，當結構定義、資料值有所差異，或在轉換期間有清理資料的機會時，就需要進行修改。
以下各節將討論資料遷移作業中可能需要的幾種修改類型，包括資料轉換、資料增強或相關聯、資料縮減或篩選。
資料轉換
資料轉換會轉換來源資料庫中的部分或所有資料值。以下列舉幾個例子：
- 資料類型轉換。有時來源和目標資料庫之間的資料類型不相符。在這些情況下，資料類型轉換會根據類型轉換規則，將來源值轉換為目標值。舉例來說，來源中的時間戳記類型可能會轉換為目標中的字串。
- 資料結構轉換。資料結構轉換可修改相同資料庫模型或不同資料庫模型之間的結構。舉例來說，在關聯系統中，一個來源資料表可能會拆分為兩個目標資料表，或是多個來源資料表可能會透過彙整功能，將資料去除異常化為一個目標資料表。來源資料庫中的 1:n 關係可能會轉換為 Spanner 中的父項和子項關係。來源文件資料庫系統中的文件，可能會分解為目標系統中的一組關聯資料列。
- 資料值轉換。資料值轉換與資料類型轉換是分開的。資料值轉換可變更值，但不會變更資料類型。舉例來說，當地時區會轉換為世界標準時間 (UTC)。或者，以字串表示的短郵遞區號 (五位數) 會轉換為長郵遞區號 (五位數加上連字號加上四位數，也稱為 ZIP+4)。
資料擴充和關聯
資料轉換作業會套用至現有資料，而不會參照其他相關的參照資料。透過資料增強功能，系統會在將來源資料儲存到目標資料庫前，先查詢其他資料來加強來源資料。
- 資料相關性。您可以連結來源資料。舉例來說，您可以合併兩個來源資料庫中兩個資料表的資料。舉例來說，您可以在一個目標資料庫中，將客戶與所有未完成、已完成和已取消的訂單建立關聯，其中客戶資料和訂單資料來自兩個不同的來源資料庫。
- 資料擴充。資料擴充會加入參照資料。舉例來說，您可以新增與郵遞區號相對應的城市名稱，以便豐富只包含郵遞區號的記錄。包含郵遞區號和對應城市名稱的參考資料表，是為了這個用途而存取的靜態資料集。參照資料也可以是動態資料。舉例來說，您可以使用所有已知客戶的清單做為參考資料。
資料縮減和篩選
另一種資料轉換方式是在遷移至目標資料庫前，減少或篩選來源資料。
- 資料縮減。資料縮減會從資料項目中移除屬性。舉例來說，如果資料項目中含有郵遞區號，則系統可能會捨棄對應的城市名稱，因為郵遞區號可重新計算，或已不再需要。有時，系統會基於歷史原因保留這項資訊，以便記錄使用者輸入的城市名稱，即使城市名稱隨時間變更也一樣。
- 資料篩選資料篩選功能會一併移除資料項目。舉例來說，所有已取消的訂單都可能會遭到移除，而不會轉移至目標資料庫。
資料組合或重組
如果資料從不同來源資料庫遷移至不同目標資料庫，可能需要在來源和目標資料庫之間以不同方式合併資料。
假設客戶和訂單儲存在兩個不同的來源資料庫中。一個來源資料庫包含所有訂單，另一個來源資料庫則包含所有客戶。遷移完成後，客戶和其訂單會儲存在單一目標資料庫結構定義中的 1:n 關係中，但不是在單一目標資料庫中，而是在多個目標資料庫中，每個資料庫都包含資料的一個分區。每個目標資料庫都代表一個區域，並包含位於該區域的所有客戶及其訂單。
目標資料庫位址
除非只有一個目標資料庫，否則每個要遷移的資料項目都必須傳送至正確的目標資料庫。以下是幾種處理目標資料庫的方法：
- 以結構定義為依據的位址。以結構定義為依據的位址指定方式會根據結構定義決定目標資料庫。舉例來說，即使客戶資訊分散在多個來源資料庫中，客戶集合的所有資料項目或客戶資料表的所有資料列都會遷移至儲存客戶資訊的相同目標資料庫。
- 以內容為依據的路由。以內容為準的路由 (例如使用以內容為準的路由器) 會根據資料值判斷目標資料庫。舉例來說，位於拉丁美洲地區的所有客戶都會遷移至代表該地區的特定目標資料庫。
您可以在資料庫遷移作業中同時使用這兩種位址。無論使用哪種位址類型，目標資料庫都必須有正確的結構定義，才能儲存資料項目。
傳輸中資料的持續性
資料庫遷移系統或其執行環境可能在遷移期間發生錯誤，導致傳輸中的資料遺失。發生錯誤時，您必須重新啟動資料庫遷移系統，並確保儲存在來源資料庫中的資料能一致且完整地遷移至目標資料庫。
在復原過程中，資料庫遷移系統需要找出上次成功遷移的資料項目，以便決定從來源資料庫的哪個位置開始擷取資料。為了在發生錯誤時繼續作業，系統需要保留遷移進度的內部狀態。
您可以透過以下幾種方式維護狀態：
- 您可以在任何資料庫修改前，將所有擷取的資料項目儲存在資料庫移轉系統中，然後在修改後的版本成功儲存在目標資料庫後，移除資料項目。這種做法可確保資料庫遷移系統能準確判斷要擷取及儲存的內容。
- 您可以維護傳輸中資料項目的參照清單。其中一種方法是將每個資料項目的主鍵或其他專屬 ID 與狀態屬性一併儲存。發生失敗後，這個狀態是系統持續復原的基礎。
- 您可以在無法判斷來源和目標資料庫系統之間的差異後，查詢來源和目標資料庫。系統會根據差異決定下一個要擷取的資料項目。
其他維護狀態的方法可能會依特定來源資料庫而定。舉例來說，資料庫遷移系統可以追蹤從來源資料庫擷取哪些交易記錄項目，以及哪些項目插入目標資料庫。如果發生失敗，您可以從上次成功插入的項目重新開始遷移。
除了錯誤或失敗，持續傳輸中的資料也相當重要。舉例來說，您可能無法從來源資料庫查詢資料，以判斷資料庫的狀態。舉例來說，如果來源資料庫包含佇列，該佇列中的郵件可能在某個時間點遭到移除。
持續性傳輸中資料的另一個用途，是處理資料的大型視窗。在資料修改期間，資料項目可以獨立轉換。不過，資料修改作業有時會依賴多個資料項目 (例如，每天處理的資料項目編號，每天從零開始)。
傳輸中資料的持久性最終用途，是在資料庫系統無法再次存取來源資料庫時，提供資料修改期間的資料可重複性。舉例來說，您可能需要使用不同的修改規則重新執行資料修改作業，然後驗證並比較結果與初始資料修改作業。如果您需要追蹤目標資料庫中因資料修改不正確而產生的任何不一致性，就可能需要採用這種做法。
完整性和一致性驗證
您需要確認資料庫遷移作業是否完成且一致。這項檢查可確保每個資料項目只會遷移一次，且來源和目標資料庫中的資料集相同，且遷移作業已完成。
視資料修改規則而定，資料項目可能會擷取，但不會插入目標資料庫。因此，直接比較來源和目標資料庫並非驗證完整性和一致性的可靠方法。不過，如果資料庫遷移系統會追蹤篩除的項目，您就可以比較來源和目標資料庫，以及篩除的項目。
資料庫管理系統的複製功能
同質遷移的特殊用途是指目標資料庫是來源資料庫的副本。具體來說，來源和目標資料庫中的結構定義相同、資料值相同，且每個來源資料庫都會直接對應至目標資料庫 (1:1)。
在這種情況下，您可以使用大多數資料庫管理系統內建的複製作業功能，將一個資料庫複製到另一個資料庫。
資料複製有兩種：邏輯和實體。
邏輯複製：在邏輯複製的情況下，資料庫物件的變更會根據其複製 ID (通常為主鍵) 進行轉移。邏輯複寫的優點是靈活、精細，且可自訂。在某些情況下，邏輯複寫可讓您在不同資料庫引擎版本之間複製變更。許多資料庫引擎都支援邏輯複製篩選器，您可以在其中定義要複製的資料組合。主要缺點是邏輯複製可能會引入一些效能負載，且這種複製方法的延遲時間通常高於實體複製。
實體複製：相較之下，實體複製會在磁碟區塊層級運作，提供更出色的效能，且複製延遲時間較短。對於大型資料集而言，實體複本可能更為簡單且有效率，尤其是在非關聯資料結構的情況下。不過，這項功能無法自訂，且高度依賴資料庫引擎版本。
例如 MySQL 複寫、PostgreSQL 複寫 (請參閱 pglogical) 或 Microsoft SQL Server 複寫。
不過，如果需要修改資料，或您有任何非直接對應的基數，就需要使用資料庫遷移系統的功能來處理這類用途。
自訂資料庫遷移功能
以下是建構資料庫遷移功能 (而非使用資料庫遷移系統或資料庫管理系統) 的部分原因：
- 您需要完全掌控每項細節。
- 您想重複使用資料庫遷移功能。
- 您希望降低成本或簡化技術足跡。
建構遷移功能的構件包括：
- 匯出和匯入：如果不考量停機時間，您可以使用資料庫匯出和資料庫匯入功能，在同質資料庫遷移中遷移資料。不過，匯出和匯入資料時，您必須先讓來源資料庫進入休止狀態，以免在匯出資料前發生更新。否則匯出作業可能不會擷取變更，目標資料庫也不會是來源資料庫的確切副本。
- 備份與還原：與匯出和匯入作業一樣，備份和還原作業會造成服務中斷時間，因為您需要讓來源資料庫處於閒置狀態，才能讓備份包含所有資料和最新變更。直到在目標資料庫上成功完成還原作業為止。
- 差異查詢：如果可以變更資料庫結構定義，您可以擴充結構定義，以便在查詢介面中查詢資料庫變更。新增時間戳記屬性，指出上次變更的時間。您可以新增其他刪除旗標，指出資料項目是否已刪除 (邏輯刪除)。有了這兩項變更，以規則間隔執行的輪詢器就能查詢自上次執行以來的所有變更。變更會套用至目標資料庫。如需其他方法，請參閱「變更資料擷取」一文。
以上只是建構自訂資料庫遷移作業的幾種可能選項。雖然自訂解決方案可提供最具彈性的導入方式和控管權限，但也需要持續維護，才能解決資料庫遷移期間可能發生的錯誤、可擴充性限制和其他問題。
資料庫遷移作業的其他考量
以下各節將簡要討論在資料庫遷移作業中重要的非功能性層面。這些方面包括錯誤處理、可擴充性、高可用性和災難復原。
處理錯誤
資料庫遷移期間的失敗，不得導致資料遺失或資料庫變更處理程序順序錯誤。無論失敗原因為何 (例如系統錯誤、網路中斷、VM 當機或區域故障)，都必須保留資料完整性。
當遷移系統從來源資料庫擷取資料，但因某些錯誤而未將資料儲存在目標資料庫中時，就會發生資料遺失的情況。資料遺失時，目標資料庫就不會與來源資料庫相符，因此會出現不一致和不完整的情況。完整性和一致性驗證功能會標記這個狀態 (完整性和一致性驗證)。
擴充性
在資料庫遷移作業中，遷移時間是一項重要的指標。在零停機時間遷移作業中 (也就是停機時間最短的情況)，資料會在來源資料庫持續變更的情況下遷移。為了在合理的時間範圍內完成遷移，資料傳輸速度必須比來源資料庫系統的更新速度快上許多，尤其是來源資料庫系統很大時。傳輸率越高，資料庫遷移作業完成的速度就越快。
當來源資料庫系統處於閒置狀態且未經修改時，由於沒有要納入的變更，遷移作業可能會更快。在同質資料庫中，您可以使用備份與還原或匯出與匯入功能，且檔案轉移規模較小，因此遷移作業可能會相當快速。
高可用性和災難復原
一般來說，來源和目標資料庫都會設定為高可用性。主要資料庫會設有對應的讀取備用資源，在發生故障時，這項備用資源會升級為主要資料庫。
當可用區發生故障時，來源或目標資料庫會切換至其他可用區，以便持續提供服務。如果在資料庫遷移期間發生區域失敗，由於系統無法存取的來源或目標資料庫有幾個，因此遷移系統本身會受到影響。遷移系統必須重新連線至發生失敗後正在執行的已升級主要資料庫。資料庫遷移系統重新連線後，必須復原遷移作業，確保目標資料庫中的資料完整且一致。遷移系統必須判斷上次一致的轉移作業，才能決定要從哪裡繼續。
如果資料庫遷移系統本身發生錯誤 (例如，無法存取執行該系統的區域)，則必須進行復原。冷啟動是一種復原方法。在這種方法中，資料庫遷移系統會在作業區中安裝並重新啟動。需要解決的最大問題是，遷移系統必須能夠在發生錯誤之前，判斷最後一次一致的資料移轉作業，並從該點繼續進行，確保目標資料庫中的資料完整性和一致性。
如果資料庫遷移系統已啟用高可用性，則可能會失敗，並在之後繼續處理。如果資料庫遷移系統的停機時間有限，您就需要選取資料庫並實作高可用性。
就資料庫遷移復原而言，災難復原與高可用性非常相似。資料庫遷移系統必須重新連線至不同區域 (容錯區域) 中的資料庫，而非重新連線至不同區域中新升級的主要資料庫。資料庫遷移系統本身也是如此。如果無法存取執行資料庫遷移系統的區域，資料庫遷移系統必須移轉至其他區域，並從上次一致的資料傳輸作業繼續執行。
陷阱
有幾個陷阱可能會導致目標資料庫中的資料不一致。以下是一些常見的避免詞彙：
- 違反訂單規範。如果透過橫向擴展來達成遷移系統的擴充性，則會同時執行多個資料移轉程序 (並行處理)。來源資料庫系統中的變更會依據已提交的交易排序。如果變更是從交易記錄中擷取，則必須在整個遷移作業中維持順序。由於基礎程序之間的速度不同，因此平行資料傳輸可能會變更順序。您必須確保資料以從來源資料庫收到的順序插入目標資料庫。
- 違反一致性規定。使用差異查詢時，來源資料庫會有額外的資料屬性，例如包含提交時間戳記。目標資料庫不會有修訂時間戳記，因為修訂時間戳記只會在來源資料庫中建立變更管理機制。請務必確保插入目標資料庫的資料具有一致的時間戳記，也就是說，所有具有相同時間戳記的變更都必須位於相同的插入或更新或 upsert 交易中。否則，如果部分變更已插入，而其他具有相同時間戳記的變更則未插入，目標資料庫可能會出現 (暫時) 不一致的狀態。如果未存取目標資料庫進行處理，這個暫時不一致的狀態並無影響。不過，如果用於測試，一致性就至關重要。另一個方面是，在來源資料庫中建立時間戳記值，以及這些值與設定交易的提交時間的關聯。由於交易確認依附程式，較早的交易可能會在較晚的交易後顯示。如果在兩筆交易之間執行差異查詢，系統就不會看到較早時間戳記的交易，導致目標資料庫出現不一致的情況。
- 資料遺漏或重複。發生容錯移轉時，如果主要執行個體和容錯移轉備援副本之間未複製部分資料，就必須小心復原。舉例來說，來源資料庫發生容錯移轉，但並非所有資料都複製到容錯移轉備援機制。同時，在發生失敗之前，資料已遷移至目標資料庫。容錯移轉後，新升級的主要資料庫會落後於目標資料庫的資料變更 (稱為「閃回」)。遷移系統需要辨識這種情況，並以這種方式復原，讓目標資料庫和來源資料庫恢復一致狀態。
- 本地交易：如要讓來源和目標資料庫接收相同的變更，常見做法是讓用戶端同時寫入來源和目標資料庫，而非使用資料遷移系統。這種做法有幾個陷阱。其中一個陷阱是，兩個資料庫寫入作業是兩個獨立的交易；您可能會在第一個作業完成後，但在第二個作業完成前遇到失敗情形。這種情況會導致資料不一致，您必須從中復原資料。此外，一般來說，客戶端的數量不只一個，而且彼此之間沒有協調。用戶端不知道來源資料庫交易的提交順序，因此無法寫入實作該交易順序的目標資料庫。用戶端可能會變更訂單，導致資料不一致。除非所有存取作業都經過協調的用戶端，且所有用戶端都確保目標交易順序，否則這種做法可能會導致與目標資料庫的狀態不一致。
一般來說，還有其他陷阱需要留意。如要找出可能導致資料不一致的問題，最好的做法是進行完整的失敗分析，並重複執行所有可能的失敗情況。如果資料庫遷移系統中實作並行作業，則必須檢查所有可能的資料遷移程序執行順序，確保資料一致性。如果實作高可用性或災難復原 (或兩者皆實作)，則必須檢查所有可能的失敗組合。
後續步驟
- 請參閱「資料庫遷移：概念和原則 (第 2 部分)」。
- 請參閱下列文件，瞭解資料庫遷移作業：
- 如要進一步瞭解資料庫遷移指南，請參閱「資料庫遷移」。
- 探索 Google Cloud 的參考架構、圖表和最佳做法。歡迎瀏覽我們的雲端架構中心。