本文由 dbaplus 社羣授權轉載。
大家好，我是陸金所數據庫團隊的負責人王英傑。這次的分享主要集中在陸金所去O在線換庫的技術特點上，之後詳細給大家剖析陸金所設計的在線換庫方案以及方案如何在一個龐大的金融系統裏通過多個團隊的緊密配合穩妥落地。
同時還會給大家介紹我們團隊自研的一些去O工具，它們是怎麼確保陸金所長達兩年的全站去O，來幫助方案從開發測試、架構、運維等各個方面有條不紊地推進和落地。
除了去O方案外，我還會解答不少業內朋友的疑問——“爲什麼陸金所會啓動這個全站去O的項目”，以及分享我們這個項目背景、去O前的設定目標等，以供大家去O參考。
希望通過這次介紹能讓大家更深入地瞭解，一個金融系統要把Oracle這種商業數據庫去掉會碰到的難點和風險，並且給想去O但是又不敢落地實施的同學提供一些案例實戰解決的思路和方法。
一、成果
在完全不做服務降級的情況下，陸金所整個去O項目從2018年年中啓動以來，歷時兩年已經把全站98%的數據庫從Oracle無縫切換到MySQL上，這98%的數據庫涉及到陸金所的賬務、資金、資產中心以及我們能夠想到的金融行業的主要業務場景。
在整個去O過程中我們也實現了全程0故障、0風險、對用戶幾乎不感知，因爲我們在凌晨的流量低峯期才進行切換，而在整個切換過程中我們也不會做服務降級，所以整個過程用戶也幾乎不感知。
陸金所去O具備四大特質：
- 無縫： 在線更換底層數據，庫完全不做服務降級，讓類似去O的重大項目改造、架構改造在最終落地實施的時候對外部用戶的影響下降到最小，這一部分非常考驗研發團隊做去O架構改造的技術實現能力；
- 穩妥： 把一個非常大的系統拆分成上百層次，再一點一點把數據庫替換掉，全程實現0故障、0風險。在過去兩年，陸金所沒有因爲去O而引發任何生產事故，所以說這一塊在考驗團隊研發能力的同時也考驗去O落地工具的設計和研發水平；
- 高效： 短短兩年就完成數據庫98%的去O落地，最後2%也會在9月之前全部做完，也就是說在Q3，陸金所的數據庫都會完成去Oracle化，整個推進速度還是比較快的；
- 智能： 藉助去O對陸金所整個生產環境的架構實現比較大範圍的重構，實現從開發到測試再到運維自研各種落地智能工具，來把控去O各個核心環節的質量，真正對一個龐大複雜、對架構改造來說風險較大的金融核心系統做到大幅度落地去O。
在這個過程中也大幅度降低了去O過程中投入的人力成本，藉助經驗和輔助工具，在前期提前設計、規劃好整個流程，在後期整個研發團隊按照規劃按部就班地推進，研發投入有了一定可控性。
在去O完成以後，也沒有因爲切換MySQL而增加特殊招聘的成本，整個運維團隊也跟着實現了從Oracle到MySQL的轉型，在人力成本方面做到了完全可控。
二、背景
1、爲什麼要啓動全站100%去O的項目
爲什麼我們要啓動全站去O這個項目，我們在立項之初希望通過去O對整個陸金所的研發有三方面的提升。
1）降低運營成本
成本是個非常現實的問題。如果一個金融系統增長的速度很快，體量已經到了一定規模的時候，能夠把IOE去掉的話，能夠很大程度降低運營成本，這一點是非常肯定的。也就是說，一個金融系統越大，它越能完成去IOE的話，對降低運營成本的提升也會非常大。
2013到2018年期間，陸金所的業務呈現快速增長的趨勢，業務拓展了上百倍，在這種業務體量增長的情況下，我們繼續使用傳統的IOE設備的話對數據庫運維成本來說是非常大的挑戰。就算我們僅僅把I、E去掉，使用X86 + Oracle的存儲架構、前臺也做細粒度的拆分，Oracle的實例還是會很多，而全都購買Oracle實例的軟件數對公司成本來說也是非常高的。
所以說評估下來，無論是在IOE還是X86+Oracle的架構，一個金融系統在業務量迅速增長的情況下，數據庫運營成本都是非常高的。
2）擺脫技術綁架
其次很重要的一點是，我們想通過去O打造一個不依賴特定數據庫特性的金融交易系統。
如果我們能夠做到這一點，就可以徹底擺脫被商業數據庫廠商技術綁架的風險。也就是說，我們希望通過去O對我們生產環境的系統進行大規模的重構，包括水平拆分、應用層服務化改造等一系列操作。
很多傳統金融行業的系統都非常依賴數據庫這個角色，包括利用數據庫的存儲過程、一些特有特性來確保金融場景的業務，甚至整個數據庫的高可用也是通過硬件層面來實現的。
所以我們就想通過去O、使用最廉價的X86服務器，把數據庫的角色轉化爲只支持最基本的增、刪、改、查的存儲引擎，涉及把原本由數據庫實現的一些特性往上移，移到應用層和服務層來進行實現，這也是我們希望通過去O來實現的一個目標。
這樣我們可以做到把傳統金融的數據庫承擔的大量的業務邏輯和架構屬性從數據庫這個層面剝離出來，數據庫層承擔的角色就會更加簡單和單一，以至降低整個運維層面的風險和難度。
3）提升研發能力
除了在運營和架構上會有一個很大的提升以外，我們也希望通過全站去O這個涉及到開發、測試、架構和DBA等全研發團隊都參與的一個重大架構改造項目，來鍛鍊整個研發團隊，提升研發能力。
在陸金所去O之前，整個系統會更偏向傳統金融系統。而且它本身也有一些在歷史上的架構設計不完善的問題，我們也希望通過去O來實現數據庫的拆分、微服務化、分佈式事務改造的架構工作，同時鍛鍊我們研發團隊的能力。
以上主要就是陸金所最開始爲去O制定的一些研發目標和相關的研發任務，後面的介紹的話也會圍繞着我們通過解決這三個方面而最終實現了什麼效果，給大家詳細進行展開。
2、爲什麼選擇MySQL，但不僅僅是MySQL
在去O之前需要對數據庫進行選型，如果把Oracle替換掉的話我們要選擇什麼數據庫來承載Oracle的流量呢？在這個過程中我們會從功能、資源、案例和壓測這四個方面對後續選型進行通篇的考慮。
1）功能和性能
首先我們要評估能承接Oracle的數據庫各種場景下的計算和IO能力。
2）資源
非常重要的是它必須具備非常廣泛的社區資源、技術資料、問題處理案例（包括成功和踩坑的經驗），這些都是我們評估替換的存儲引擎非常重要的因素。
還有一點就是，它要有比較廣泛的用戶基礎，方便我們技術棧後續轉型時招聘對應的開發和運維工程師能有更大的選擇。
3）案例
在整個行業，特別是金融場景下有比較好的參考案例。國內比較大的互聯網公司之前在去O方面也給了我們一些好的成功案例以去借鑑和參考。
4）壓測
最終在確定之後，陸金所上線之前會通過非常嚴格的壓測環境，把一些想用的存儲引擎使用生產環境最真實的數據在陸金所核心應用、核心接口反反覆覆進行壓測，並且得到最終的壓測數據，與生產環境的Oracle數據庫的性能表現做對比以得到最終的評估。
陸金所在切換任何一張表流量的時候，我們都會使用生產環境最真實的數據進行Oracle和MySQL的壓測，最終的壓測結果還是非常不錯的。我們發現在之前使用Oracle 11.2在sql語句的話sql接口比較簡單，區分度和選擇性又很高的情況下，其實Oracle和MySQL在性能上沒有太大差別。而且我們也發現了，MySQL在一些特性，特別是在並行複製上，它的性能和表現比我們想象中的更好。
所以我們在兩年前對MySQL 5.7進行多能壓測以後，最終選定使用MySQL5.7成爲我們去O的主要存儲引擎。它在去O上主要承接所有與事務相關的寫入，還有和用戶的交互，金融層面上的訂單、交易、賬戶、資產、資金的數據寫入。
Oracle實際上是一個非常好的數據庫，它能覆蓋非常全面的場景。很多傳統型公司，無論是前臺交易庫還是後臺的數據倉庫，都會選擇使用Oracle。它在OLTP和OLAP場景下表現得都非常優秀，但是要把Oracle所有的計算場景全都承接下來的話，光使用MySQL是不夠的。所以在這個過程中，我們也想借助去O的這個機會對生產環境引入更多的存儲引擎，讓它們在最合適的使用場景下發揮最大價值。
在使用過程中我們發現，實際效果還是不錯的。基本上很多存儲引擎都是開源系統，成本很低，而且在一些特定場景下的性能和處理速度比Oracle更快，所以最終選型決定了以MySQL爲主，以TiDB、Redis、ES、HBase等存儲引擎爲輔的方式。
我們在去O的過程中不僅僅是去掉Oracle，我們也根據不同使用場景來引入更多的主流存儲引擎。
三、方案
1、去O雙寫和切換方案
本次介紹特別重要的技術亮點是在線換庫，圖中左方是在線替換Oracle的主要架構圖。
應用層面：
說到核心思路，在應用層面上看，Oracle和MySQL兩套防禦數據庫的DAL層實現雙寫，中間有一個流量開關用於控制業務邏輯是走和Oracle相關的這一塊還是和MySQL相關的這一塊。
而且在去O的時候會有一個整體的規劃，很重要的一點是要把一個特別大的系統拆分成多個獨立落地的批次。有些像交易、資產中心的系統做底層服務，上面被關聯、調用到的系統會很多。
在去O過程中的某一個晚上，把特別大的流量從Oracle遷移到MySQL的風險是非常高的，所以我們在去O的過程中會拆分成特別小的批次，而且每一個小的批次做到每一次變更的風險、改造的工作量和難度都在可控範圍內。基於這個方式，我們把一個應用系統拆分成多個批次以後，會在應用層面將業務邏輯層面進行上移。
這個時候，我的業務邏輯層面無論是仿Oracle還是MySQL都是同樣的一套，只是最終是由流量開關來決定流量從Oracle的DAL層走還是從MySQL的DAL層走，每一個批次都會有專屬的流量開關來進行控制。
數據庫層面：
在整個改造的過程中，會涉及應用版本的發佈。應用在發版的過程中會不斷將流量開關發佈上線，包括和Oracle對等的MySQL的代碼也一起發佈上線。
在發版的過程中Oracle數據庫並沒有發生變化，同時它還在對外提供服務。這個時候我們會在Oracle後面建立一個實時數據同步的MySQL數據庫。
假設Oracle這邊有一筆事務提交，它會以秒級的速度往MySQL數據庫進行同步。在這個過程中，大家可以將整個架構理解爲，Oracle後面掛了一個秒級實時同步的備庫。
根據這套框架，陸金所研發了一套自動化的雙建框架，如果我們的Oracle數據庫需要去O，系統流程如下：
- 確定好批次，框定需要去O的表的批次再在系統中勾選好 ；
- 系統會對這些批次的表中的數據做全量增量 ，包括雙向同步的建立，都在後臺自動完成。這樣是把整個運維層面、數據庫層面等需要人爲介入的工作都通過自動化的方式來完成；
- 等待應用版本發佈上線以後進行流量切換 。其中設置了一個總控開關控制從應用到數據庫，從到Oracle到MySQL數據同步的整個流向，從而進行全盤切換；
- 最後實現Oracle的數據實時同步到MySQL 。在流量切換的瞬間，可以做到當這筆事務在Oracle成功提交且同步到MySQL以後，確保在MySQL中也成功提交了的話後臺會對這筆事務進行最後一次質量校驗，校驗後纔會將流量從Oracle切換到MySQL，全程由流量開關控制整個過程。在這個過程中的步驟比較複雜，無論是哪一步出了問題，總控開關都可以讓整個流量切換過程回到最開始的原點。這個過程類似於Oracle數據庫裏的在線重定義，不同的是在線重定義是Oracle的一張表到Oracle的另一張表，是從Oracle到MySQL，並且流量切換到了MySQL以後會把流量進行反向同步。
2、應用流量在O和M之間快速切換
接下來介紹整個流量切換的三個狀態，在圖中這三個狀態描寫得比較簡單，在真正的實際操作中大約會有16個步驟，但整個流程會在10秒內落地完成：
-
初始狀態 ：最開始所有的流量會從Oracle到同步到MySQL，這時候還是由Oracle提供服務；
-
中間狀態 ：切換時，在確保Oracle上的最後一筆數據提交成功且同步到MySQL以後，完成最後一筆增量比對。在這個過程中，Oracle和MySQL的寫服務會短暫地處於不可用狀態，爲了確保Oracle同步到MySQL的最後一點數據都沒有問題，所以整個過程非常快速。我們實踐中完成上百個批次的切換，平均單個批次4秒鐘；
-
完成狀態 ：最後把MySQL的寫開關打開，幾乎所有流量在MySQL上且從MySQL上寫入，之後數據會反向從MySQL同步到Oracle。在整個流量切換的過程中，反向同步是爲了避免切換過去後20%-30%概率的應用問題，比如運用上的bug，或者說接口性能不符合預期，這種時候就要往回切。
-
往回切時，MySQL在完成切換的時間點就已經開始對外提供服務了。所以這時要確保Oracle和MySQL的數據一致性，必須確保在MySQL寫入的數據實時反向同步到了Oracle。在切換過去之後，一旦主庫從Oracle變成了MySQL，MySQL的數據就要反向同步回Oracle，它就變成了一個備庫，所以保證兩個數據庫中的數據一致非常重要；
-
萬一切換到MySQL的時候出現問題，在10秒之內整個流量會從MySQL再往Oracle切。這個過程中，無論走到哪一步都要確保Oracle和MySQL的數據一致，其中任何一步出錯，都可以快速回滾到最開始的狀態。如果整個切換流程結束，但是MySQL那邊的數據出現問題，也可以快速往Oracle回切。
3、適用於金融核心系統的穩妥去O推進方案
接下來分享的是大家在去O過程中的一個 痛點 ：我們對大規模的系統進行去O改造，到底要從哪裏入手？怎麼做才能將系統風險降到最低而且全程可控？
這個痛點也是非常重要的一點，上面說到過陸金所很多系統的規模都很大，我們就會將其拆分成很多個批次。圖中顯示的是拆分成的3個批次，但在一些更大的系統當中，會被拆分成15個以上的批次，整個持續改造的時間超過12個月，我們在很長的時間裏應用將數據一點一點地從Oracle切換到MySQL。
這整個過程可以總結爲： 以表爲粒度建立批次，以批次爲單位推進去O落地 。那我們爲什麼要這麼做呢？
- 如果以表爲粒度，把一個包括了龐大金融系統的閥拆分成多個批次的話，我們只要把跟業務、事務相關的表放在同一個批次下，就可以確保在做去O改造的過程中單個批次的改造難度、上線進度、切換風險是可控的。這樣，我們就把一個需要花費高時間、人力成本要做去O的核心繫統，通過拆分降低成本，每一次做變更和上線發版的時候就只用對其中的一部分表做去O，而且整個推進的過程中單個去O版本里需要改造的內容也非常少。如果這個批次在改造過程中有些問題，拆分批次的操作也會將全站的風險降到最小；
- 另外，如果在這個批次足夠小的情況下，去開發進行去O改造，也可以快速落地和推進到生產環節；
- 最後進行相關流量的切換。因爲整個流量切換的過程不做服務降級，那麼單個批次切換的表越小，單個切換的瞬間對系統造成的影響就會越小。
剛纔說的就是一個 “小步快跑”高速迭代 的過程，我們按照這個原則進行操作。圖中可以看到，應用層上不斷有版本發佈，以下是我們實踐中的操作流程：
- 將大系統拆分成多個批次；
- 逐步對這些批次進行去O改造；
- 在做去O改造的過程中將整個業務邏輯層往上移；
- 之後完成Oracle和MySQL兩邊的流量開關、DAL層相關的代碼的改造工作；
- 持續做版本發佈。
整個過程中Oracle持續對外提供服務。版本上線後運維會進行測試，之後整個數據庫的雙寫機制就會通過自動化運維體系建立起來。
我們在圖中看到，Oracle和MySQL是完全對等的關係，但實際上Oracle上IOE設備的比例非常重，在拆分的過程中不同的表會往不同的X86服務器去拆。我們以表爲粒度就實現了數據庫的架構拆分的相關工作。
按照這個維度一點點地進行拆分，只要這張表要上線和切換，我們在後臺完全建立起這套同步機制之後，就等待應用上線完成。從應用1.0版本到1.1、1.2，最後到應用1.3的版本，應用不斷迭代發版。
每上線一個版本後臺中就會切換一個批次，這個批次從Oracle切到MySQL只會涉及少量部分的表，切換過去沒有問題的話就會在生產環境中不斷地跑。如果有問題的話再把它再從Oracle往MySQL進行回切。整個過程按這種思路來落地和推進的話會非常穩妥。
但是這個過程需要運維團隊有足夠好的工具進行支撐，才能順利完成。可以從圖中看到，整個過程中有一些應用改造所需要的時間跨度很長，比如說持續超過一年，會有十幾個批次需要進行去O改造。
第一張表從Oracle往MySQL切的時候，整個應用的服務會由兩個數據庫同時對外提供服務，在這個過程中就涉及到了在做版本發佈的時候的很多問題。
比如，要發哪個表？加哪個字段的時候要加哪個表？是加Oracle還是MySQL？是先加Oracle還是先加MySQL？這個過程包括了後續相關的運維操作，所以這部分首先需要一整套完善的自動化運維體系來確保這個操作框架順利推進，同時保證我們在長時間的去O改造過程中，以Oracle和MySQL作爲一個應用同時提供服務的時候，每天高頻上線的所有版本和數據庫變更都不會出任何問題。
以陸金所爲例，我們採用了這套框架來推進去O改造，我們很多核心繫統的改造基本上花費12個月或以上，基本上一點點地把Oracle數據庫給替換掉。並且整個過程是完全不做服務降級的，所以對陸金所4500萬多用戶來說幾乎無感知。
四、目標 / 效果
1、通過去O大幅降低運營成本
1）去O前
陸金所去O之前使用的都是IOE設備，數據庫的量不多、也沒有進行服務化的改造。那個時候的架構就是一個比較傳統的金融架構，很多應用向一個比較大的Oracle數據庫進行訪問。DBA團隊每天的工作就做好幾個核心數據庫的預用。
做完去O之後的架構沒有了IOE的設備，通過普通的MySQL+X86服務器支撐起陸金所整個的數據庫架構。由於X86服務器的價格非常低，從投入成本方面來說，每年的運營成本大幅度下降，整個數據庫軟硬件的採購成本下降至不到之前採購成本的百分之十。
整個去O過程持續兩年左右，讓我們團隊對人員的要求有了全方位的變化，因爲後續自動化運維體系和MySQL的運維都需要有一整套相對完善的自動化運維工具用作支撐。
而且去O過程中兩個數據庫之間會有長達一年的雙寫過程，整個版本在發佈和日常數據庫變更中是完全不能出現問題的，所以這個工作必須通過自動化來完成。如果通過人爲介入完成雙寫，在上線之後在很多細節問題上有很大機率會出錯，所以我們在這過程中就運用了一套強大的CMDB和數據庫的運維體系進行支撐。
2）去O後
完成去O之後，陸金所整體的架構變得非常清晰，同時我們也通過去O完成了服務化改造。
這樣，我們各個核心的業務模塊都以微服務化驅動的方式形成一個分佈式的相關架構，而且每個服務都有自己的應用和數據庫，每個數據庫在完成去O和服務化改造之後只給服務內的應用提供直接訪問。
如果非服務內的應用想直接訪問數據庫的話，我們會通過配置中心進行配置，它們是完全沒有相關訪問權限的；如果服務之外的應用想要訪問數據庫的話，必須走應用層提供的相關服務接口，這樣就避免了跨服務器直接訪問數據庫。
整個服務訪問分爲同步調用和相關異步調用。如果服務比較大，在服務內部我們就會對數據庫進行水平拓展；如果是類似用戶、交易、資金這種公共類服務，後續它們會陸續迭代成一些比較大的中臺服務。
通過整個去O的過程，陸金所整個IT的架構就變成集中式的大庫和MySQL的小庫。之後如果對容量有擴展的需求，我們還可以對這套架構進行更細粒度的拆分，可以呈現數據庫水平擴展。
2、通過去O在架構上大幅優化
完成去O之後，我們實現了數據庫層面的幾個特性：
- 去中心化 ：在去O之前，陸金所的幾套大庫如果任何一套出現問題，都會對陸金所的全站可用率產生影響。而拆分到MySQL之後，MySQL跑到X86上，X86的硬件可用率比之前存儲盒小型機的時候差很多，所以在MySQL這部分會做更細粒度的拆分。對單個MySQL數據庫來說，拆分之後一旦出現故障、需要切換的時候，對全站可用率的影響完全可控。實現這套框架後，我們也可以把不同的MySQL佈置在不同的機房，在網絡調用可控的情況下，實現真正意義上的機房多活；
- 彈性擴容；
- 應用層的服務化拆分；
- 應用訪問數據庫的規範化落地。
3、通過去O在各種不同場景引入最合適的存儲引擎
陸金所在去O前對存儲引擎進行了架構選型，涉及到架構選型的時候會支持哪些業務場景、通過哪些數據庫承接。
去O不僅僅是流量去到MySQL，因爲MySQL無法承接Oracle的全部流量，所以需要特別考慮下面幾種場景的流程承接方案：
- Oracle當中少量hash join查詢場景： 這些在OLTP場景下的查詢的qps不大，Oracle處理這種查詢相對比較得心應手，而在MySQL 5.7下完全無法處理這種查詢；
- Oracle中多表關聯和多層複雜嵌套查詢場景；
- 在MySQL細粒度拆分後，跨庫、跨分片的查詢場景；
- 在MySQL集羣和Hadoop集羣之間構建一個秒級數據同步的ODS層。
爲了解決以上問題，我們引用了一些新的存儲引擎，發現它們在合適的場景下替換Oracle產生的效果不僅比IOE的成本更低、性能更快。
五、場景
使用TiDB承接Oracle流量：
六、落地
1、應該如何落地呢
左邊是一套傳統的金融架構系統框架，那麼怎樣變成右邊這一套做過I域拆分、水平分片、去O改造的一套陸金所繫統架構？PPT裏畫得比較簡單，在實際生產環境中系統還在對外提供服務的時候，我們應該怎樣對一個7*24小時的金融核心系統進行這麼大的架構改造呢？
這本身就是一個高風險的工作。我們在過程中要做到規避風險，又確保各種工程實現細節有效落地，還同時保證系統的業務連續性，甚至是對外部用戶幾乎不感知。
2、理解去O這類架構改造的本質
3、建立起強大的去O風控系統
4、有效支持多團隊協同配合
5、陸金所去O的落地節奏
七、寫在最後
比起降低成本，陸金所去O收益更大的是整個研發團隊的提升：
去O的細節內容除了數據庫外，還會涉及：
- 去O的架構改造方案
- 去O中間件
- 去O的開發規範和開發技巧
- 如何進行去O壓測
- 去O的運維變更方案
- 去O工具
通過全站系統的去O落地實踐，我們對去O改造各個階段中需要謹慎處理哪些細節，規避什麼風險都有了一定的研究和積累。
Q & A
Q1： 這裏的數據同步用的工具是什麼？ Oracle和MySQL間數據如何實時同步 ？事務提交是否要在Oracle和MySQL雙提交交易才返回？ 最後一步交易如何識別？
A： 數據同步是使用陸金所自研的同步工具，原理是解析Oracle的redolog和MySQL的binlog來實現O和M之間的雙向同步，要特別注意解決循環寫入的問題。事務只要在當前的寫流量所在的寫庫提交即返回事務成功響應。以CAP的方式來看待這個方案，可以理解爲在數據同步雙寫階段是一個確保AP模式的分佈式架構，在寫流量切換的一瞬間切換爲CP模式，切換完成後又恢復到AP模式。目標是確保以異步方式實現雙寫，不要因爲雙寫同步而影響生產的寫流量。
Q2： 前後數據庫服務器的數量增加了多少？
A： 因爲服務化和分片改造，去O後MySQL的實例數量大概是Oracle的5到10倍之間。
Q3： 存儲過程是如何處理的？全部轉移到應用端處理嗎？
A： 存儲過程的業務邏輯在應用層通過java重構，存儲過程的數據庫交互操作在應用DAL層實現，SQL寫在mybatis裏。
Q4： 這個切換的批次是如何劃分的？有什麼方法嗎？
A： 按在業務和服務儘可能的拆分小，讓單個批次的去O改造工作量和變更風險足夠可控。
Q5： 單個微服務MySQL採用什麼高可用架構?
A： 一主多從，兩地三中心，MHA。
Q6： 選型時有考慮PostgreSQL嗎？
A： PGSQL這幾年成長很快，但目前找到頂尖的PGSQL工程師相對MySQL工程師會更難。同時金融場景使用MySQL重構在一線互聯網公司有更多的落地，所以我們選擇了使用MySQL來替換Oracle中的事務寫入場景。未來我們會在陸金所生產環境使用更多的PGSQL來承接流量。
Q7： 有運行在國產處理器平臺的數據嗎？
A： 國產處理器評估中，未來會採用。
Q8： 異地機房數據同步怎麼做的？
A： 使用MySQL原生的主備同步模式。
Q9： 在保證Oracle與MySQL寫保持一致時，對前端業務會有影響吧？有多大影響？
A： 切換期間寫操作會有瞬間抖動，抖動持續幾秒後恢復，寫接口具備重試能力且批次拆分的足夠小，對外部用戶幾乎不感知。
Q10： 是否全部是community版本？分庫分表使用現有中間件還是自研的？
A： Percona分支版本，自研中間件。
Q11： 請問自動化管理工具是用什麼開發的？
A： Python，涉及到運維和開發兩個板塊。
Q12： 請問你們的異步消息總線用的什麼？
A： 自研的日誌解析器+消息中間件+管理平臺。
Q13： 切換到MySQL後，同城雙活架構（數據層雙活）變成怎麼樣的？
A： 基於數據路由層+數據庫分片架構實施。
Q14： Oracle redolog解析是用的開源工具還是自研工具？
A： 自研。
Q15： 對於有關聯的業務查詢，拆分細瞭如何解決？有時關聯操作的代價太大了。
A： 先做服務化改造，數據庫對象僅提供給服務內的應用訪問，服務之外的應用不能直接訪問數據庫對象。這是去O改造的基礎。
Q16： 傳統行業的存儲過程是怎麼處理的？
A： 具體問題具體分析，功能拆分、服務化、數據庫拆分是重點工作，在這個過程中實現去存儲過程、去O。
Q17： 雙寫的功能可以開發，但切到MySQL之後，如何評估它是否能支撐原來Oracle的高併發業務？或者說，壓測如何模擬實際業務的流量？
A： 在切換之前要進行嚴格的壓力測試，壓測數據庫的數據來源於生產脫敏，確保數據量和數據分佈和生產一致。壓測需要覆蓋每一個去O接口，開發和DBA需要自動或人工審覈每一筆改造的SQL執行計劃，壓測需要得到所有接口和SQL在O和M之間的響應時間。
作者介紹：
王英傑，陸金所數據架構團隊負責人
- 陸金所數據庫團隊負責人，主導和見證了陸金所數據庫和大數據平臺全程的建設和演進過程。
原文鏈接：