摘要：數據庫遷移的目的是爲了業務遷移，而業務可否順利切換取決於數據庫的遷移能力和遷移後的準確性，站在業務側的角度，至少要知足如下三個正確性纔可以去作業務的切換。
本文分享自華爲雲社區《華爲雲GaussDB(for openGauss)專場直播第4期：用對遷移工具，遷移也能夠很簡單》，原文做者：心機胖 。html
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)的能力，能夠給出完整的遷移評估報告，哪些對象能夠徹底兼容的進行遷移，哪些對象須要進行轉換進行遷移，哪些對象須要業務配合改造。oracle
- 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》技術直播整理完成，錯過直播的小夥伴們，歡迎點擊此處回顧精彩內容哦~