開發者必看！你想知道的遷移之道都在這裡了

摘要：資料庫遷移的目的是為了業務遷移，而業務能否順利切換取決於資料庫的遷移能力和遷移後的準確性，站在業務側的角度，至少要滿足以下三個正確性才能夠去做業務的切換。

本文分享自華為雲社群《》，原文作者：心機胖 。

1.背景介紹

隨著GaussDB(for openGauss)資料庫的不斷髮展，越來越多的客戶開始選擇使用GaussDB(for openGauss)，其中很大一部分客戶是將現有的系統替換到GaussDB(for openGauss)上，客戶當前所用的資料庫型別多種多樣，如Oracle、MySQL、PostgreSQL等。那麼如何解決將客戶當前資料庫遷移到GaussDB(for openGauss)上是一個很迫切的需求。GaussDB(for openGauss)自帶的GDS資料遷移工具實現了GaussDB(for openGauss)之間的高效資料遷移，但是無法解決異構同步和實時同步的場景。華為雲資料庫遷移工具DRS以一種易用、穩定、高效的雲服務為GaussDB(for openGauss)提供了異構遷移和實時同步的能力，助力客戶輕鬆將資料庫遷移到GaussDB(for openGauss)。

2.資料庫遷移整體解決方案

資料庫遷移的目的是為了業務遷移，而業務能否順利切換取決於資料庫的遷移能力和遷移後的準確性，站在業務側的角度，至少要滿足以下三個正確性才能夠去做業務的切換。

• 物件遷移是正確的

資料庫的儲存過程、函式、觸發器、表結構、索引等全部資料庫物件能夠完整的遷移到目標庫，並且能夠保證物件的執行邏輯和源庫是一致的。

• 資料遷移是正確的

將源庫的全量資料遷移到目標庫，當業務對停機時間視窗有要求的時候，要考慮全量+增量的線上遷移，保證業務不中斷。同時要能夠對同步的資料進行校驗，保證遷移資料的準確性。

• 遷移後業務執行是正確的

當物件和資料都遷移到目標庫後，業務的切換還存在兩個風險點，一個是業務在目標庫的執行結果是否正確，另一個是目標庫效能能否和源庫一樣支撐住業務的負載。因為異構資料庫之間的差異還是很大的，設計理念和實現方式存在很多不同，會導致看上去類似的兩個物件，其執行結果或效率是完全不同的。所以要有工具來驗證這種差異，保證遷移後業務執行的正確性。

為了實現以上業務切換需要滿足的條件，華為雲提供了資料庫遷移的整體解決方案，透過語法遷移（UGO），DRS-資料遷移，DRS-資料校驗和DRS-流量回放4個工具產品形成了整個遷移過程的閉環。

• 語法遷移（UGO）

實現了將oracle資料庫物件遷移到GaussDB(for openGauss)的能力，可以給出完整的遷移評估報告，哪些物件可以完全相容的進行遷移，哪些物件需要進行轉換進行遷移，哪些物件需要業務配合改造。

• DRS-資料遷移

實現將Oracle、MySQL、PostgreSQL等資料庫資料實時遷移到GaussDB(for openGauss)的能力。

• DRS-資料校驗

實現了對資料遷移後的一致性校驗，具備行級比對、內容級比對和實時的增量資料比對的能力。

• DRS-流量回放

實現對Oracle資料庫的業務流量抓取，並對流量SQL進行轉換，然後在GaussDB(for openGauss)進行回放的能力。

3.DRS資料遷移上雲

DRS提供了簡單、易用的操作介面，採用流程化的配置方式，客戶按照提示步驟一步一步操作便可以搭建出同步鏈路。DRS除了支援Oracle到GaussDB(for openGauss)的資料遷移外，還支援其他資料庫之間的資料同步，下面給出了當前DRS所支援的源庫和目標庫型別的列表。

在資料遷移過程中，DRS採用很多手段和技術去降低可能存在的風險，保證遷移過程的穩定和最終資料的一致性。

• 線上遷移

DRS透過全量遷移將客戶資料庫中的存量資料遷移到GaussDB(for openGauss)中，透過增量同步，實時解析源庫日誌，將客戶的實時變化資料同步到Gauss(for openGauss)，透過全量和增量的無縫銜接來保證客戶在不中斷業務的情況下，完整地將全部資料遷移到GaussDB(for openGauss)。

• 預校驗

在DRS的遷移任務啟動之前，為提早發現遷移啟動後可能存在的風險或錯誤，DRS引入預校驗環節，能夠提前對配置資訊、資料庫相容性資訊、連通性資訊等進行校驗，同時會對一些可以遷移成功但可能會對業務產生影響的情況進行告警，讓客戶及時發現並提前處理。

• 斷點機制

為保證資料遷移的一致性，DRS在每個元件中都設有斷點機制，無論是在正常啟停、異常重啟還是在故障切換的場景下都可以保證資料同步的準確性，不會造成資料丟失。

4.DRS技術實現原理

DRS在技術實現上主要分為兩個大的模組，一個是全量的資料同步，另一個是增量資料同步。全量同步解決對靜態資料的遷移，增量同步解決對實時的變化資料遷移。

全量同步的技術架構

全量同步的整體邏輯比較簡單，就是從源庫把資料透過select的方式查詢出來，然後再將這些資料寫入到目標庫，只是在具體的程式碼實現上會有一些關鍵技術點。

• 資料分片

一般全量同步產品的同步粒度都可以達到表級別的併發，即多個執行緒可以同時對多張表同時進行同步，但往往客戶的系統中會存在單表資料量特別大的情況，比如一張表幾十億甚至上百億的資料，此時這張表的同步時間就變為整個全量同步的時間。那麼如何進一步提升單張表的同步效率呢？我們可以對單表做進一步的拆分，按照主鍵去把它拆分成多個分片，多執行緒以分片為單位做並行的同步。

當前DRS按照下面的策略對錶進行分片：

• 無主鍵表不進行分片
• 分割槽表按分割槽進行同步，不再對每個分割槽進行分片
• 有主鍵表按主鍵（第一列）進行分片

 

• 資料不落盤

為減少全量同步過程中對磁碟的佔用，DRS匯出的資料不進行落盤快取，而是直接透過記憶體傳遞給匯入執行緒，在匯出和匯入速率相當的情況下，可以最大化的提高全量同步的效率。

• 斷點控制

全量同步半途中斷是一個非常讓人棘手的問題，可能一張2億條資料的表，在同步到1.8億的時候因為網路或源庫快照過舊的問題導致同步失敗，如果沒有好的斷點控制機制，那可能之前的付出都白白浪費，還要重新再次同步一次。DRS透過以分片為單位做為斷點的儲存記錄，對於上面的例子，即使同步中斷，也可以再次被拉起，而且拉起後，已經同步成功的分片將不再同步，還沒有同步的分片則會繼續同步。

• 流量控制

客戶的業務往往是存在高峰期和低峰期，高峰期時，資料庫的資源佔用是最高的，我們要儘量避開在業務高峰期做全量的同步，因為全量同步對源庫的cpu、記憶體和網路資源佔用是很大的。DRS採用流量控制的機制來減少業務高峰期對源庫的資源佔用，主要是透過控制網路流量的方式，客戶可以設定要進行流量控制的時間段，DRS在全量同步過程中，會實時計算同步的流量大小，執行到該時段後，當流量超過設定的閾值，會放緩資料獲取的速度。執行過該時段後，便恢復全部的資料同步速度。

• 全量+增量的無縫銜接

在業務切庫的場景中，資料的遷移過程一般可以選擇兩種方案，一種是一次性將源庫的資料遷移到目標庫，但是需要業務停機視窗，這個視窗的大小取決於全量資料遷移的時間。當資料量較大時，整個遷移過程可能需要幾天的時間，這種業務停機是無法接受的。所以另一種方案就是業務不中斷的資料遷移方案，它的實現原理就是基於全量遷移和增量同步的無縫銜接，對於Oracle->GaussDB(for openGauss)的遷移，Oracle資料庫提供了指定scn進行快照匯出的功能，基於這個特性，DRS在做全量同步時，指定scn進行匯出，這樣整個全量同步的資料就是此scn點前的快照資料，然後增量同步以這個scn點作為同步的分界點，只有大於這個scn的增量事務才會被同步到目標庫。這樣就實現了全量和增量的無縫銜接，同步過程無需業務進行停機，當全量資料同步完成且增量同步追趕到當前時間點時，便可進行業務切換，業務中斷視窗可以控制在秒級。

增量同步的技術架構

DRS的增量同步架構主要分為3個部分，分別是資料抓取、落盤檔案和資料回放。

• 資料抓取

資料抓取透過對源庫日誌的解析，實時獲取源庫的變化資料，在內部實現上主要包括日誌拉取、日誌解析、事務整合和資料落盤幾個步驟。

• 日誌拉取

DRS採用Oracle的Logminer介面獲取實時的redo日誌，當redo歸檔後，DRS會讀取歸檔日誌檔案。為了防止源庫的歸檔日誌被不確定性刪除，DRS會啟動日誌拉取的執行緒（可以多執行緒併發）把日誌拉取到本地，然後進行後續的解析。

• 日誌解析

Oracle Logminer介面獲取到的資料需要進一步解析才能獲取到實際的變化內容，DRS的日誌解析執行緒對返回的資料進行過濾、拼接、後設資料對映、轉換等操作形成一條完整的變更記錄物件。

• 事務整合

日誌解析是按照源庫變化資料的順序進行解析，解析後的每條記錄的事務是交叉混合在一起的，必須對每條記錄按照事務id進行整合才能形成一個完整的事務。另一方面對於Oracle RAC的場景，還需要對不同節點的事務進行排序，避免事務亂序的情況發生。

• 落盤檔案

經過了事務整合後，形成了一個按照源庫業務提交順序的序列，DRS會按照這個順序把這些資料寫入到磁碟檔案。落盤的資料包含了源庫每一條變化資料的全部資訊，包含表資訊、列資訊、事務資訊、資料資訊和其他額外資訊（如時間戳、rowid等），根據這些資訊後面的元件便可以把每一條變化資料還原成物件的SQL。

• 資料回放

資料回放就是將資料抓取到的資料在目標庫進行執行的過程，但它和資料的抓取是解耦的。它讀取DRS的落盤檔案，解析出每條變化的資料，根據檔案中記錄的後設資料資訊重構出對應的SQL語句，在目標庫執行。

在資料回放之前，DRS提供了過濾和轉換的功能，可以對同步的資料進行過濾，可配置過濾條件，如只同步id < 10000的資料，也可以對同步資料的表名、schema名或列名進行對映等。

異常處理和回放效能是兩個重要的考量點，DRS透過配置資料衝突策略來處理回放中的異常資料，透過併發機制來提高裝載的效能。

• 衝突策略

所謂的衝突是指在資料回放的時候出現了資料類報錯（如主鍵衝突、update和delete無法找到記錄等），這些報錯一版都是由於兩邊的資料不一致造成的。DRS對這類錯誤採用了三種處理策略，分別是覆蓋、忽略和等待。

覆蓋：當出現衝突時，用抓取到的資料覆蓋掉目標庫的資料

忽略：資料衝突後，直接跳過錯誤記錄，繼續執行

等待：資料衝突後，等待人工處理

• 併發機制

DRS的併發機制採用記錄級別的併發，最大化的提升資料裝載的效能。

首先從DRS的落盤檔案中讀取增量資料，按順序放入一個佇列中，並行分析引擎會從佇列中獲取每一條資料，並根據其主鍵資訊判斷是否存在資料衝突，對於沒有衝突的資料說明可以並行去執行，則把這些資料分散到多個執行緒佇列中，當執行緒佇列中的資料量達到設定的閾值時，這批資料會作為一個事務在目標庫執行。對於有衝突的資料，則把這條資料放到衝突佇列，等待執行緒把上一批資料執行完成後，再次進入並行分析引擎判斷是否存在衝突。

 

Ps：該內容根據《GaussDB(for openGauss)資料遷移之DRS》技術直播整理完成，