平安科技是平安集團(tuán)旗下科技解決方案專家，踐行“科技賦能金融、科技驅(qū)動生態(tài)”的企業(yè)使命，賦能集團(tuán)金融服務(wù)、醫(yī)療健康、汽車服務(wù)、智慧城市生態(tài)圈建設(shè)，致力于成為國際領(lǐng)先的科技公司。

UbiSQL 簡介

UbiSQL 這個(gè)詞對大家來說可能比較陌生，UbiSQL 是平安集團(tuán)內(nèi)部打造的分布式數(shù)據(jù)庫產(chǎn)品，代碼基于 TiDB，完全兼容 TiBD 4.0 版本。在 TiDB 的特性之上，UbiSQL 在穩(wěn)定性、安全性和應(yīng)用性上面都做了提升，打造出一個(gè)金融級且內(nèi)核源碼自主可控的分布式數(shù)據(jù)庫，提供一棧式 HTAP 解決方案。

UbiSQL 的規(guī)劃是提供金融級別的安全能力，比如加密算法、給 TDE 的透明算法做增強(qiáng)，以及集群內(nèi)部管理的加強(qiáng)。因?yàn)楹罄m(xù)會增加到上千套集群，我們對于集群的管理做了加強(qiáng)，監(jiān)控都做了合并。此外，UbiSQL 提供冷熱數(shù)據(jù)的分離，支持把集群的冷數(shù)據(jù)都分離到 SATA 盤上，從而降低存儲成本。

從 Oracle 遷移到 UbiSQL 的過程

接下來分享一個(gè)比較詳細(xì)的 Oracle 遷移實(shí)踐，這是我們在平安集團(tuán)里面做了多年去 O 工作的總結(jié)，希望給到大家借鑒。集團(tuán)的核心支付系統(tǒng)遷移的數(shù)據(jù)量大概在 8 T 左右，因?yàn)槎际?rac 節(jié)點(diǎn)，為了避免節(jié)點(diǎn)之間的相互影響，就把它遷移到兩個(gè) UbiSQL 的實(shí)例上面。

圖：遷移前后集群的對比

UbiSQL 的架構(gòu)是通過 F5 負(fù)載均衡，打到三個(gè)數(shù)據(jù)中心的 TiDB 集群上面，F(xiàn)5 在三地機(jī)房都有部署，通過 DNS 方式訪問相應(yīng) UbiSQL 的實(shí)例，在機(jī)房 IDC1、IDC2、IDC3 的集群之間通過 UbiSQL 自身的 Raft 協(xié)議實(shí)現(xiàn)強(qiáng)一致的數(shù)據(jù)同步，再通過 Drainer 工具進(jìn)行異步復(fù)制，復(fù)制到遠(yuǎn)程的災(zāi)備集群。

圖：遷移后的 UbiSQL 架構(gòu)

首先是遷移前對于現(xiàn)狀的分析，主要包括三個(gè)方面：

數(shù)據(jù)庫的負(fù)載以及遷移 SQL 的金融性、對象，存儲過程的分析，確定是不是都可以遷移，這部分分析是 DBA 通過代碼的掃描、報(bào)告得出的。

應(yīng)用方面的分析，應(yīng)用層需要看新的數(shù)據(jù)庫是不是能適配，能不能兼容應(yīng)用，了解應(yīng)用層的結(jié)構(gòu)還有相應(yīng)的 JDBC 的版本。

關(guān)聯(lián)系統(tǒng)的分析，Oracle 數(shù)據(jù)庫有很多通過 OGG 或者 ETL、Kettle 或者調(diào)用第三方進(jìn)行同步，接口調(diào)用情況也需要做相應(yīng)的梳理。

接下來基于分析的結(jié)果，做數(shù)據(jù)庫的選型：

選擇 RDBMS 還是選其他的開源數(shù)據(jù)庫或是分布式數(shù)據(jù)庫，我們需要根據(jù)應(yīng)用層的要求來看，是做到雙活，還是做到快速的擴(kuò)容，亦或是分布式，然后根據(jù)要求來做相應(yīng)數(shù)據(jù)庫的選型。數(shù)據(jù)庫的架構(gòu)設(shè)計(jì)方案，是不是需要做多活，還是 NG 就足夠了，也需要根據(jù)相應(yīng)的業(yè)務(wù)需求做設(shè)計(jì)。

應(yīng)用系統(tǒng)的拆分與解耦方案，確定應(yīng)用是整個(gè)遷移，還是只遷移一部分，然后再啟動應(yīng)用的前期改造。

關(guān)聯(lián)數(shù)據(jù)的同步方案設(shè)計(jì)，這部分就是 OGG 或者其他 ETL 數(shù)據(jù)的同步，分布式數(shù)據(jù)庫以及開源的 PG，目前不支持 OGG 為源的，所以需要借助于第三方，比如 Kafka 之類的工具做相應(yīng)的數(shù)據(jù)同步。

然后是相應(yīng)的遷移方案和回退方案設(shè)計(jì)，需要做相應(yīng)的人力規(guī)劃，還要看一下投入多少人力和成本。

在這些準(zhǔn)備都做完后，我們就開始搭建數(shù)據(jù)庫、開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境。準(zhǔn)備好以后我們開始做數(shù)據(jù)的遷移，將前面梳理出來的一些表結(jié)構(gòu)、對象之類的遷移到新的 UbiSQL 上，需要涉及到表結(jié)構(gòu)的比對和數(shù)據(jù)的比對，這部分后面會詳細(xì)介紹。

應(yīng)用功能的改造和測試是最重要、最核心的部分，開發(fā)人員需要對相應(yīng)的功能、SQL 以及存儲過程這方面進(jìn)行改造，這是整個(gè)脫 O 的核心部分，如果存儲過程較大，有幾十萬行之類的，需要評估人力的投入。我們今年脫 O 的項(xiàng)目存儲過程大概有 2 萬行左右，投入的人力約 10 個(gè)人，做了兩個(gè)月左右，把整體約 100個(gè) package，全部轉(zhuǎn)換為 java 代碼，這塊的人力投入是挺大的。這部分做完之后就是應(yīng)用層功能的全回歸測試，校驗(yàn)開發(fā)轉(zhuǎn)化的功能是否完全一致，和原來 Oracle 的邏輯是否完全一致。 接下來依次是做應(yīng)用的性能壓測、數(shù)據(jù)庫的壓測，然后是相應(yīng)的遷移手冊。

接下來進(jìn)入生產(chǎn)實(shí)施的階段，按照實(shí)際的情況和方案步驟進(jìn)行遷移，可能是“一次遷移，一次切換”，也可能是“多批次遷移、逐步切換”，因?yàn)橛幸恍┖诵南到y(tǒng)的遷移需要做保障措施，比如切過去不能有任何問題，可能切一些灰度數(shù)據(jù)過去。后續(xù)進(jìn)入到生產(chǎn)數(shù)據(jù)庫的并行運(yùn)行階段，我們對遷移后的數(shù)據(jù)庫做相應(yīng)監(jiān)控和報(bào)告，緊接著下線老的 Oracle 數(shù)據(jù)庫和回滾鏈路，進(jìn)行項(xiàng)目的總結(jié)。

流量復(fù)制與回放方案

重點(diǎn)剖析一下流量復(fù)制和流量回放方面我們的實(shí)現(xiàn)方案。首先，為什么有流量復(fù)制和流量回放?流量回放是因?yàn)?Oracle 轉(zhuǎn)化為 java 代碼后，不知道這個(gè)邏輯對不對，完全通過測試人員做回歸測試，可能測試不全，也有可能遺漏掉很重要的部分，我們想通過流量回放的方案保證生產(chǎn)業(yè)務(wù)流量完全在測試環(huán)境做相應(yīng)的應(yīng)用。

流量復(fù)制是因?yàn)榭梢宰鰤簻y，把生產(chǎn)的流量直接引入到遷移之后的環(huán)境，然后把流量做到翻倍，翻到兩三倍做壓測，做完之后還可以在后續(xù)核心系統(tǒng)去 O 上面做重復(fù)利用，從而節(jié)約了相應(yīng)的成本和人力。

圖：流量復(fù)制

流量復(fù)制借助的是 F5，或者 Ngnix 的流量，將所有客戶端的流量通過 F5 訪問到 Oracle 的環(huán)境，也可以在 F5 這一層將流量做鏡像，將實(shí)時(shí)到 F5 的流量轉(zhuǎn)發(fā)到應(yīng)用層，應(yīng)用層通過訪問 UbiSQL，再通過擋板程序做到相應(yīng)業(yè)務(wù)的訪問。整個(gè)環(huán)節(jié)的核心在 F5，所有的流量都要經(jīng)過 F5，如果沒有走 F5 的流量則沒有辦法抓取到相應(yīng) SQL 的調(diào)用或者執(zhí)行。擋板程序則是將所有環(huán)境按照生產(chǎn)環(huán)境進(jìn)行調(diào)用，如果訪問其他數(shù)據(jù)庫的話，不需要做相應(yīng)的訪問，在這個(gè)地方會有一個(gè)擋板程序。這個(gè)擋板程序就是直接訪問其他數(shù)據(jù)庫，直接獲取結(jié)果，不在其他數(shù)據(jù)庫執(zhí)行，不然會出現(xiàn)數(shù)據(jù)混亂。

圖：流量回放方案

流量回放相對比較復(fù)雜，主要是開發(fā)同學(xué)實(shí)現(xiàn)的。主要的實(shí)現(xiàn)邏輯，就是通過外圍系統(tǒng)的調(diào)用，通過 Traceid 訪問相應(yīng)的功能點(diǎn)，功能點(diǎn)上面會有一個(gè) Agent，會去把相應(yīng)調(diào)用的情況和參數(shù)，調(diào)用到哪個(gè)接口記錄下來，存儲到日志平臺上。再通過日志平臺里面的存儲，將這部分存儲下來，存儲后調(diào)用后續(xù)支付系統(tǒng)的 UbiSQL，就可以做到數(shù)據(jù)的回放。

因?yàn)槭谴鎯ο聛?，想什么時(shí)候調(diào)用就可以什么時(shí)候去調(diào)，這個(gè)地方也有相應(yīng)的擋板程序。做完之后我們可以做到 Oracle 和 UbiSQL 數(shù)據(jù)庫的對比，因?yàn)橹暗?SQL 都是一樣的，而且是全量的，那么就可以把 Oracle 的數(shù)據(jù)通過恢復(fù)的方式恢復(fù)到某一個(gè)時(shí)間點(diǎn)，然后再把 UbiSQL 的數(shù)據(jù)通過流量回放的方式把那天的數(shù)據(jù)進(jìn)行回放，這兩邊的數(shù)據(jù)基本就是一致的，再通過數(shù)據(jù)比對工具比對兩邊數(shù)據(jù)是否一致，這樣來驗(yàn)證功能是不是完全一致。

流量復(fù)制或回放方案通過搭建生產(chǎn)旁路驗(yàn)證環(huán)境，在旁路環(huán)境進(jìn)行回退鏈路的生產(chǎn)級別驗(yàn)證。相比傳統(tǒng)數(shù)據(jù)庫回放，這個(gè)方案進(jìn)行應(yīng)用 + 數(shù)據(jù)庫整體架構(gòu)層面的驗(yàn)證，降低重大核心業(yè)務(wù)系統(tǒng)新技術(shù)上線投產(chǎn)風(fēng)險(xiǎn)。并行驗(yàn)證通過后，完成數(shù)據(jù)遷移比對后，可直接切換上線，減少了投產(chǎn)時(shí)間。

數(shù)據(jù)對比與切換方案

數(shù)據(jù)切換和數(shù)據(jù)比對的方案，先看數(shù)據(jù)比對的部分。遷移 Oracle 會有一個(gè)數(shù)據(jù)比對的過程，平安集團(tuán)內(nèi)部的有一個(gè) Ludbgate 工具可以實(shí)現(xiàn)表結(jié)構(gòu)的轉(zhuǎn)化、全量數(shù)據(jù)的同步、增量數(shù)據(jù)的同步，還有全量數(shù)據(jù)的比對，增量數(shù)據(jù)的比對，它是整個(gè)遷移過程中數(shù)據(jù)對比的全鏈路工具。

數(shù)據(jù)比對大致的邏輯是，當(dāng)開始做數(shù)據(jù)同步的時(shí)候，會在日志里面記錄相應(yīng)的日志點(diǎn)，開始全量同步，全量同步完成之后就可以啟動增量同步，因?yàn)橛涗浟讼鄳?yīng)的啟動時(shí)間點(diǎn)，后續(xù)就可以通過這個(gè)時(shí)間點(diǎn)做增量同步，在做增量的同時(shí)，會在中間的 MySQL 里面創(chuàng)建一個(gè)影子表，這個(gè)影子表的作用主要是記錄進(jìn)程啟動后同步表的所有 dml 操作的主鍵值。

數(shù)據(jù)同步完成之后就可以做相應(yīng)的全量同步，這時(shí)所有增量及全量數(shù)據(jù)一直在不斷變化，需要進(jìn)行全量的比較，可以基于這個(gè)時(shí)間點(diǎn)比對兩邊的數(shù)據(jù)，不管是否靜態(tài)都可以進(jìn)行比較。全量比較主要通過把數(shù)據(jù)做一定的分區(qū)，首先對表記錄做分區(qū)劃分，用于多進(jìn)程處理，每個(gè)進(jìn)程根據(jù)對應(yīng)分區(qū)的 rowid 去 Oracle 獲取對應(yīng)的記錄并算出 md5 值，同時(shí)在 UbiSQL 這端獲取到這個(gè)主鍵值，并通過查詢整個(gè)行的數(shù)據(jù)，計(jì)算出 md5 值進(jìn)行比對，如果比對結(jié)果不一致就會存到影子表里面。

全量比對完成之后會啟動增量對比，增量對比是每個(gè)小時(shí)啟動一次，會將影子表里面的主鍵值拿到 Oracle 里面讀取相應(yīng)的記錄，計(jì)算出 md5 值，再在 UbiSQL 里獲取相應(yīng)記錄并計(jì)算出 md5 值，然后進(jìn)行對比，如果一致，將此主鍵值從影子表中刪除，如果不一致，下次在啟動的時(shí)候會再次做相應(yīng)對比，這樣減少了比對的時(shí)間，做到最短的停機(jī)時(shí)間。

圖：數(shù)據(jù)對比和切換方案

數(shù)據(jù)的切換方案通過 Oracle Ludbgate 訪問到 UbiSQL 這一端，Oracle 這邊有到其他 Oracle OGG 的鏈路，遷移是通過部分流量的切換，因?yàn)槭琴Y費(fèi)系統(tǒng)，它需要保證遷移是完全的，沒有任何問題，涉及到錢的問題，大家都覺得比較麻煩，所以我們按照切部分用戶的方式去做。

我們按照切少量流量，在應(yīng)用端做相應(yīng)的功能開關(guān)，去做到少量數(shù)據(jù)切到 UbiSQL 這邊，然后做應(yīng)用的驗(yàn)證，如果沒有問題，流量會一點(diǎn)一點(diǎn)地切到 UbiSQL 這一端。另外它有相應(yīng)到第三方的同步，會啟用到 kafka，同步到其他的 Oracle 數(shù)據(jù)庫。這個(gè)方案有一個(gè)短板，即不能保證回退的機(jī)制，因?yàn)閷懙?UbiSQL之后，UbiSQL 的新增數(shù)據(jù)沒有辦法寫回到 Oracle。也就是說回退的時(shí)候這部分?jǐn)?shù)據(jù)不再被需要。我們給 TiDB 社區(qū)提了相應(yīng)的需求，是不是可以做到在 TiDB 里面進(jìn)行用戶寫入的區(qū)分，這樣我們就可以做到 Oracle 到 TiDB 雙向的同步，就不會存在無法回退的問題。

圖：遷移后性能對比

最后看下遷移后的性能對比，可以看到，因?yàn)槎际琴Y費(fèi)系統(tǒng)，平均響應(yīng)時(shí)間特別短，遷移到 UbiSQL 后進(jìn)行了大致的統(tǒng)計(jì)，在執(zhí)行 Count 語句的時(shí)候性能有提升，在其他的查詢或插入性能方面有損耗，但是損耗不大，基本在 10% 以內(nèi)，應(yīng)用端是可以接受的。用這套方法我們遷移了統(tǒng)一支付、CF2 客戶關(guān)系系統(tǒng)以及工作流系統(tǒng)，這些都是屬于平安集團(tuán)內(nèi)部比較核心的業(yè)務(wù)系統(tǒng)。

原文鏈接：https://blog.csdn.net/TiDB_PingCAP/article/details/122982104