平安科技從 Oracle 遷移到 UbiSQL 的實踐

作者：熊浪，平安科技資深資料庫架構師，在關係型和非關係型分散式資料庫技術領域具有豐富的經驗，擔任平安集團去 O 分散式專案經理，負責分散式資料庫選型和架構設計工作。
平安科技是平安集團旗下科技解決方案專家，踐行“科技賦能金融、科技驅動生態”的企業使命，賦能集團金融服務、醫療健康、汽車服務、智慧城市生態圈建設，致力於成為國際領先的科技公司。

UbiSQL 簡介

UbiSQL 這個詞對大家來說可能比較陌生，UbiSQL 是平安集團內部打造的分散式資料庫產品， 程式碼基於 TiDB，完全相容 TiBD 4.0 版本。在 TiDB 的特性之上，UbiSQL 在穩定性、安全性和應用性上面都做了提升，打造出一個金融級且核心原始碼自主可控的分散式資料庫，提供一棧式 HTAP 解決方案。

UbiSQL 的規劃是提供金融級別的安全能力，比如加密演算法、給 TDE 的透明演算法做增強，以及叢集內部管理的加強。因為後續會增加到上千套叢集，我們對於叢集的管理做了加強，監控都做了合併。此外，UbiSQL 提供冷熱資料的分離，支援把叢集的冷資料都分離到 SATA 盤上，從而降低儲存成本。

從 Oracle 遷移到 UbiSQL 的過程

接下來分享一個比較詳細的 Oracle 遷移實踐，這是我們在平安集團裡面做了多年去 O 工作的總結，希望給到大家借鑑。集團的核心支付系統遷移的資料量大概在 8 T 左右，因為都是 rac 節點，為了避免節點之間的相互影響，就把它遷移到兩個 UbiSQL 的例項上面。

圖：遷移前後叢集的對比

UbiSQL 的架構是通過 F5 負載均衡，打到三個資料中心的 TiDB 叢集上面，F5 在三地機房都有部署，通過 DNS 方式訪問相應 UbiSQL 的例項，在機房 IDC1、IDC2、IDC3 的叢集之間通過 UbiSQL 自身的 Raft 協議實現強一致的資料同步，再通過 Drainer 工具進行非同步複製，複製到遠端的災備叢集。

圖：遷移後的 UbiSQL 架構

首先是遷移前對於現狀的分析，主要包括三個方面：

1. 資料庫的負載以及遷移 SQL 的金融性、物件，儲存過程的分析，確定是不是都可以遷移，這部分分析是 DBA 通過程式碼的掃描、報告得出的。

2. 應用方面的分析，應用層需要看新的資料庫是不是能適配，能不能相容應用，瞭解應用層的結構還有相應的 JDBC 的版本。

3. 關聯絡統的分析，Oracle 資料庫有很多通過 OGG 或者 ETL、Kettle 或者呼叫第三方進行同步，介面呼叫情況也需要做相應的梳理。

接下來基於分析的結果，做資料庫的選型：

1. 選擇 RDBMS 還是選其他的開源資料庫或是分散式資料庫，我們需要根據應用層的要求來看，是做到雙活，還是做到快速的擴容，亦或是分散式，然後根據要求來做相應資料庫的選型。資料庫的架構設計方案，是不是需要做多活，還是 NG 就足夠了，也需要根據相應的業務需求做設計。

2. 應用系統的拆分與解耦方案，確定應用是整個遷移，還是隻遷移一部分，然後再啟動應用的前期改造。

3. 關聯資料的同步方案設計，這部分就是 OGG 或者其他 ETL 資料的同步，分散式資料庫以及開源的 PG，目前不支援 OGG 為源的，所以需要藉助於第三方，比如 Kafka 之類的工具做相應的資料同步。

然後是相應的遷移方案和回退方案設計，需要做相應的人力規劃，還要看一下投入多少人力和成本。

在這些準備都做完後，我們就開始搭建資料庫、開發環境、測試環境、生產環境。準備好以後我們開始做資料的遷移，將前面梳理出來的一些表結構、物件之類的遷移到新的 UbiSQL 上，需要涉及到表結構的比對和資料的比對，這部分後面會詳細介紹。

應用功能的改造和測試是最重要、最核心的部分，開發人員需要對相應的功能、SQL 以及儲存過程這方面進行改造，這是整個脫 O 的核心部分，如果儲存過程較大，有幾十萬行之類的，需要評估人力的投入。我們今年脫 O 的專案儲存過程大概有 2 萬行左右，投入的人力約 10 個人，做了兩個月左右，把整體約 100個 package，全部轉換為 java 程式碼，這塊的人力投入是挺大的。這部分做完之後就是應用層功能的全迴歸測試，校驗開發轉化的功能是否完全一致，和原來 Oracle 的邏輯是否完全一致。 接下來依次是做應用的效能壓測、資料庫的壓測，然後是相應的遷移手冊。

接下來進入生產實施的階段，按照實際的情況和方案步驟進行遷移，可能是“一次遷移，一次切換”，也可能是“多批次遷移、逐步切換”，因為有一些核心系統的遷移需要做保障措施，比如切過去不能有任何問題，可能切一些灰度資料過去。後續進入到生產資料庫的並行執行階段，我們對遷移後的資料庫做相應監控和報告，緊接著下線老的 Oracle 資料庫和回滾鏈路，進行專案的總結。

流量複製與回放方案

重點剖析一下流量複製和流量回放方面我們的實現方案。首先，為什麼有流量複製和流量回放？流量回放是因為 Oracle 轉化為 java 程式碼後，不知道這個邏輯對不對，完全通過測試人員做迴歸測試，可能測試不全，也有可能遺漏掉很重要的部分，我們想通過流量回放的方案保證生產業務流量完全在測試環境做相應的應用。

流量複製是因為可以做壓測，把生產的流量直接引入到遷移之後的環境，然後把流量做到翻倍，翻到兩三倍做壓測，做完之後還可以在後續核心系統去 O 上面做重複利用，從而節約了相應的成本和人力。

圖：流量複製

流量複製藉助的是 F5，或者 Ngnix 的流量，將所有客戶端的流量通過 F5 訪問到 Oracle 的環境，也可以在 F5 這一層將流量做映象，將實時到 F5 的流量轉發到應用層，應用層通過訪問 UbiSQL，再通過擋板程式做到相應業務的訪問。整個環節的核心在 F5，所有的流量都要經過 F5，如果沒有走 F5 的流量則沒有辦法抓取到相應 SQL 的呼叫或者執行。擋板程式則是將所有環境按照生產環境進行呼叫，如果訪問其他資料庫的話，不需要做相應的訪問，在這個地方會有一個擋板程式。這個擋板程式就是直接訪問其他資料庫，直接獲取結果，不在其他資料庫執行，不然會出現資料混亂。

圖：流量回放方案

流量回放相對比較複雜，主要是開發同學實現的。主要的實現邏輯，就是通過外圍系統的呼叫，通過 Traceid 訪問相應的功能點，功能點上面會有一個 Agent，會去把相應呼叫的情況和引數，呼叫到哪個介面記錄下來，儲存到日誌平臺上。再通過日誌平臺裡面的儲存，將這部分儲存下來，儲存後呼叫後續支付系統的 UbiSQL，就可以做到資料的回放。

因為是儲存下來，想什麼時候呼叫就可以什麼時候去調，這個地方也有相應的擋板程式。做完之後我們可以做到 Oracle 和 UbiSQL 資料庫的對比，因為之前的 SQL 都是一樣的，而且是全量的，那麼就可以把 Oracle 的資料通過恢復的方式恢復到某一個時間點，然後再把 UbiSQL 的資料通過流量回放的方式把那天的資料進行回放，這兩邊的資料基本就是一致的，再通過資料比對工具比對兩邊資料是否一致，這樣來驗證功能是不是完全一致。

流量複製或回放方案通過搭建生產旁路驗證環境，在旁路環境進行回退鏈路的生產級別驗證。相比傳統資料庫回放，這個方案進行應用 + 資料庫整體架構層面的驗證，降低重大核心業務系統新技術上線投產風險。並行驗證通過後，完成資料遷移比對後，可直接切換上線，減少了投產時間。

資料對比與切換方案

資料切換和資料比對的方案，先看資料比對的部分。遷移 Oracle 會有一個資料比對的過程，平安集團內部的有一個 Ludbgate 工具可以實現表結構的轉化、全量資料的同步、增量資料的同步，還有全量資料的比對，增量資料的比對，它是整個遷移過程中資料對比的全鏈路工具。

資料比對大致的邏輯是，當開始做資料同步的時候，會在日誌裡面記錄相應的日誌點，開始全量同步，全量同步完成之後就可以啟動增量同步，因為記錄了相應的啟動時間點，後續就可以通過這個時間點做增量同步，在做增量的同時，會在中間的 MySQL 裡面建立一個影子表，這個影子表的作用主要是記錄程式啟動後同步表的所有 dml 操作的主鍵值。

資料同步完成之後就可以做相應的全量同步，這時所有增量及全量資料一直在不斷變化，需要進行全量的比較，可以基於這個時間點比對兩邊的資料，不管是否靜態都可以進行比較。全量比較主要通過把資料做一定的分割槽，首先對錶記錄做分割槽劃分，用於多程式處理，每個程式根據對應分割槽的 rowid 去 Oracle 獲取對應的記錄並算出 md5 值，同時在 UbiSQL 這端獲取到這個主鍵值，並通過查詢整個行的資料，計算出 md5 值進行比對，如果比對結果不一致就會存到影子表裡面。

全量比對完成之後會啟動增量對比，增量對比是每個小時啟動一次，會將影子表裡面的主鍵值拿到 Oracle 裡面讀取相應的記錄，計算出 md5 值，再在 UbiSQL 裡獲取相應記錄並計算出 md5 值，然後進行對比，如果一致，將此主鍵值從影子表中刪除，如果不一致，下次在啟動的時候會再次做相應對比，這樣減少了比對的時間，做到最短的停機時間。

圖：資料對比和切換方案

資料的切換方案通過 Oracle Ludbgate 訪問到 UbiSQL 這一端，Oracle 這邊有到其他 Oracle OGG 的鏈路，遷移是通過部分流量的切換，因為是資費系統，它需要保證遷移是完全的，沒有任何問題，涉及到錢的問題，大家都覺得比較麻煩，所以我們按照切部分使用者的方式去做。

我們按照切少量流量，在應用端做相應的功能開關，去做到少量資料切到 UbiSQL 這邊，然後做應用的驗證，如果沒有問題，流量會一點一點地切到 UbiSQL 這一端。另外它有相應到第三方的同步，會啟用到 kafka，同步到其他的 Oracle 資料庫。這個方案有一個短板，即不能保證回退的機制，因為寫到 UbiSQL之後，UbiSQL 的新增資料沒有辦法寫回到 Oracle。也就是說回退的時候這部分資料不再被需要。我們給 TiDB 社群提了相應的需求，是不是可以做到在 TiDB 裡面進行使用者寫入的區分，這樣我們就可以做到 Oracle 到 TiDB 雙向的同步，就不會存在無法回退的問題。

圖：遷移後效能對比

最後看下遷移後的效能對比，可以看到，因為都是資費系統，平均響應時間特別短，遷移到 UbiSQL 後進行了大致的統計，在執行 Count 語句的時候效能有提升，在其他的查詢或插入效能方面有損耗，但是損耗不大，基本在 10% 以內，應用端是可以接受的。用這套方法我們遷移了統一支付、CF2 客戶關係系統以及工作流系統，這些都是屬於平安集團內部比較核心的業務系統。