【恩墨學院】從商用到開源：DB2遷移至MySQL的最佳實踐

身處資料驅動快速變革的時代，資料庫系統的選型和架構設計對於整個IT基礎架構，甚至企業的發展都起到至關重要的作用。那麼今天，如果您的企業需要搭建一套新的應用系統，你會選擇什麼資料庫型別？如果當前的系統不能滿足業務需求，面臨系統遷移，你又會如何選擇？

在2017年初，我們分享過一份國外的報告“開發人員是如何使用資料庫的 ”，並且進行了一次調查『中國資料庫愛好者的選擇和背離』，其中的一些資料展示了使用者對於資料庫的選擇，非常具有參考價值，連結可以直接參考分析報告。

隨著網際網路+時代的到來，企業的業務發展對IT架構提出了更高的要求，傳統的架構往往運維複雜、成本高、不易擴充套件，在很大程度上制約了企業的快速發展。隨著領先網際網路企業的開源架構嘗試和探索，人們開始逐漸接受並嘗試『非IOE』架構和元件，尤其是一些勇於創新的傳統行業企業，如金融、保險、證券等，他們正在快速跟上極速變革的技術新時代。

而在資料庫領域加速這一過程的，便是以MySQL為代表的開源資料庫的應用。MySQL在近幾年發展迅速，以其體積小、速度快、成本低，尤其是開放原始碼等優勢受到廣大使用者的喜愛。

同時，在 DB-Engines 的排名上，Oracle 和 MySQL 兩個產品長期霸佔了前兩名的位置。但根據近幾年的增長趨勢，MySQL 在這個榜單上超越Oracle資料庫是遲早的事，而且這一時點可能很快到來。

近期，雲和恩墨為某證券公司進行了從DB2到MySQL資料庫系統的遷移論證、驗證，對兩類資料庫展開全方位多角度的對比分析，並根據使用者的業務現狀進行了相關架構、效能、備份恢復及高可用驗證。

在以下的系列文章中，我們將把來自於實踐的分析、論證、驗證資料分享給大家，從商用到開源，從DB2到MySQL，從傳統業務到網際網路架構，一切正在發生。

為什麼是MySQL不是DB2？

我們知道，IT架構通常由業務架構、資料架構、IT基礎架構和應用架構構成，而資料架構則是整個IT架構的中心，企業最核心的資產就是資料。

很多傳統的企業比如金融證券等行業的IT軟硬體架構都是IBM系列產品，比如IBM小型機/DB2資料庫/DS8000高階儲存等產品，這種IT架構被業界稱為“IOE”架構，其特點是基於向上擴充套件（Scale Up）技術的高階裝置以及圍繞它們開發的專有硬體、大型商業資料庫和中介軟體組合。

有人說，DB2在金融證券保險行業有絕對不可替代的優勢！

的確，DB2擁有悠久的歷史並且被很多人認為是最早使用SQL的資料庫產品。主要應用於大型應用系統，具有較好的可伸縮性，可支援從大型機到單使用者環境，應用於所有常見的伺服器作業系統平臺下。然而隨著時代的進步，開源產品和技術也已經被證明具備支撐企業核心業務的能力。

時代導向

在移動網際網路時代，各組織都在試圖構建面向網際網路+的安全可控的技術架構，在網際網路轉型升級壓力下，需要對IT系統重構、而資料架構是IT重構的基礎和核心。因此上述傳統的IOE架構正在逐漸演化為新一代以X86架構、開源應用平臺、資料平臺等為技術基礎的新一代技術架構。

MySQL資料庫作為網際網路行業IT架構的標配，在長期的實踐中積累了大量的高可用、分散式架構和災備經驗。

因此，潮流的改變IT傳統架構的演變。越來越多的DB2資料庫客戶轉向開源資料庫，而 MySQL 作為當前最火的開源資料庫，也常常是受到老DB2使用者關注最多的。

政策驅動

將DB2遷移到MySQL並不是一件容易的事，更不可能受單一的時代潮流影響而一蹴而就，對於傳統企業來說是一個逐步試水嘗試的過程；資料是企業IT架構的核心資產，資料的任何丟失都是難以接受的。而受國家資訊保安“自主可控”政策的號召，更加堅定了傳統企業作將DB2遷移到MySQL的嘗試。比如著名的銀監會39號文要求各銀行業金融機構對安全可控資訊科技的應用以不低於15％的比例逐年增加，直至2019年達到不低於75％的總體佔比。

成本驅動

為了穩定執行，很多客戶的 DB2 資料庫都是執行在全套 IBM 平臺中，成本高昂；那麼將DB2遷移到以X86架構為主的MySQL資料庫當中，資料庫執行的底層基礎架構的要求大大降低，每年需要給原廠商的商業 License 費用也會隨之減少。

隨著大資料和雲時代的到來，企業的新業務和應用變更非常快，此時，以低成本的方式進行系統擴充套件和維護便是首要考慮的問題。

自主可控

由於網際網路行業的薪資和職業前景吸引了大量技術人才湧入網際網路公司從事開發運維等工作，使得原廠技術支援團隊人才流失嚴重，而且服務體制僵化，服務響應流程慢等弊端，導致了服務質量的下降，從而拉低了客戶滿意度。

將DB2資料庫遷移到MySQL，那麼可以很大程度降低對原廠服務的依賴性；轉而使用“最受歡迎的開源資料庫”——MySQL，首先一點是國內MySQL從業人員多，而且深入程式碼研究的MySQL DBA也不少，第三方服務運維水平也比較高，是現在傳統企業擁抱網際網路時備受青睞的選擇。

社群生態

整個行業DB2技術從業人員相對較少，圈子也在不斷縮小，存在人才斷崖風險。一方面很多10多年前培養起來的經驗豐富的DB2 DBA，或者去了大型甲方單位像大型銀行、券商等IT建設投入相對比較大的企業，另一方面很多人才轉行到開源領域，或者轉行到大資料雲端計算等行業，社群生態持續收縮。

因此，由於DB2資料庫技術人才儲備的嚴重不足以及業內人才梯隊斷層，導致很多企業招人難，特別是很多中小型企業，社群和產品是相互促進、相互推動，人才必然影響到產品的應用。

推薦使用MySQL的原因

·         在社群成熟度上，MySQL資料庫在開源業界可以說“炙手可熱”，便捷靈活，已經廣泛被業內看好，而且被Oracle公司接管後，其開發不再像以前典型的開源專案那樣開發人員散落世界各地，而是由Oracle公司專門組建了一個MySQL開發團隊，團隊中有的小組在做叢集化軟體，有的在做資料庫演算法，有的在做備份功能，整體上提供了更加成熟的工程模式，未來提升的空間巨大。

·         從市場佔有率看，MySQL排名今年連續攀升，大有趕超資料庫龍頭“Oracle”的趨勢。從如資料庫下排名可以看出，市場還是比較青睞MySQL開源資料庫的。

全球資料庫熱度排名中，MySQL穩居第二名直逼第一名。參考連結：

·         在效能上，從我們與PG等其他資料庫的benchmark測試結果看，MySQL資料庫相對OLTP效能高、簡易又靈活、易用性好，比較適用於響應時間靈敏的業務場景。

要注意的事項

當然，在考慮將DB2遷移到MySQL之前，也應該充分認識到MySQL在功能上的一些缺陷。

比如在多表查詢方面，MySQL只支援NL JOIN,不支援表的全外連線，也不支援HS JOIN和MG JOIN；MySQL的儲存過程和觸發器的功能比較弱，甚至不建議在MySQL資料庫中對儲存過程的使用等。

總之，從功能上，MySQL適合拿來存放資料、不適合做運算場景，實際中大部分網際網路公司也只是把它當做資料儲存器來使用，把需要的資料取出來然後在應用程式中進行運算，這一點和DB2/Oracle那種商業資料庫儘量什麼都放到資料庫裡面的使用風格很不一樣。

因此，將DB2遷移到MySQL的話，需要認清MySQL適用於OLTP場景，不建議在OLAP場景中運用；而且必須考慮將原先放在DB2中的某些業務邏輯在遷移到MySQL後，從資料庫中剝離出來放到應用中去實現；需要加強對應用架構的管控。

如何實現DB2遷移至MySQL的最佳實踐

基於上述的遷移驅動力，你是不是也決定要把你的DB2系統遷移至MySQL了呢？那麼如何才能規避遷移中的系列問題呢？這需要我們完全把握兩個資料庫的特點，各自的優勢和不足，在遷移中做合理規劃設計。

為此，本系列接下來會包含（但不限於）以下內容，帶領大家全面認識DB2遷移至MySQL的實踐。

遷移準備

1、DB2與MySQL資料庫對比分析。包含：資料庫架構對比，資料型別對比，資料庫物件對比，SQL對比等。

2、測試。包含DB2與MySQL相容性測試，MySQL效能測試，MySQL基於OLPT的測試等等。

遷移過程

1、應用設計與改造。

2、MySQL高可用設計與部署

3、MySQL備份與恢復設計

4、遷移中的重點問題和注意事項

遷移最佳化

1、效能測試

2、系統最佳化

一場從DB2遷移至MySQL的資料庫風暴即將襲來，你準備好了嗎？

MySQL vs DB2  Part 1: 體系架構

我們來對比一下DB2與MySQL體系架構有什麼不同。

MySQL體系架構

首先我們對圖中的元件進行說明。

由連線池元件、管理服務和?工具元件、SQL介面元件、查詢分析器元件、最佳化器元件、緩衝元件、外掛式儲存引擎、物理?檔案組成。MySQL是獨有的外掛式體系結構,各個儲存引擎有自己的特點。

1、Connectors：指的是不同語言中與SQL的互動

2、ManagementServeices & Utilities： 系統管理和控制工具

3、Connection Pool:連線池：管理緩衝使用者連線，執行緒處理等需要快取的需求

4、SQL Interface:SQL介面：接受使用者的SQL命令，並且返回使用者需要查詢的結果。比如select from就是呼叫SQL Interface

5、Parser: 解析器：SQL命令傳遞到解析器的時候會被解析器驗證和解析。解析器是由Lex和YACC實現的，是一個很長的指令碼。

主要功能

a . 將SQL語句分解成資料結構，並將這個結構傳遞到後續步驟，以後SQL語句的傳遞和處理就是基於這個結構的

b.  如果在分解構成中遇到錯誤，那麼就說明這個sql語句是不合理的。

6、Optimizer: 查詢最佳化器：SQL語句在查詢之前會使用查詢最佳化器對查詢進行最佳化。他使用的是“選取-投影-聯接”策略進行查詢。

舉例： selectuid,name from user where gender = 1;

這個select 查詢先根據where 語句進行選取，而不是先將表全部查詢出來以後再進行gender過濾，這個select查詢先根據uid和name進行屬性投影，而不是將屬性全部取出以後再進行過濾將這兩個查詢條件聯接起來生成最終查詢結果

7、Cache和Buffer： 查詢快取。

如果查詢快取有命中的查詢結果，查詢語句就可以直接去查詢快取中取資料。

這個快取機制是由一系列小快取組成的。比如表快取，記錄快取，key快取，許可權快取等

8、Engine ：儲存引擎。儲存引擎是MySql中具體的與檔案打交道的子系統。也是Mysql最具有特色的一個地方。

·         Mysql的儲存引擎是外掛式的。它根據MySql AB公司提供的檔案訪問層的一個抽象介面來定製一種檔案訪問機制（這種訪問機制就叫儲存引擎）

·         現在有很多種儲存引擎，各個儲存引擎的優勢各不一樣，最常用的MyISAM,InnoDB,BDB

·         預設下MySql是使用MyISAM引擎，它查詢速度快，有較好的索引最佳化和資料壓縮技術。但是它不支援事務。

·         InnoDB支援事務，並且提供行級的鎖定，應用也相當廣泛。

·         Mysql也支援自己定製儲存引擎，甚至一個庫中不同的表使用不同的儲存引擎，這些都是允許的。

MySQL不是透過多程式來完成其功能的，MySQL只有一個程式，程式裡有多個執行緒。

MySQL的體系架構可劃分為以下三個邏輯層：

·         應用層（Application Layer）

·         邏輯層（Logical Layer）

·         物理層（Physical Layer）

（1）應用層（ApplicationLayer）

·         MySQL管理工具和應用例項（Administrator&Utilities）

主要是連線到MySQL伺服器檢索、修改或增加資料，有以下常見MySQL管理工具或實用程式。

·         本地查詢介面（Query Interface）

MySQL查詢介面主要指mysql指令碼，使用mysql工具可以直接與MySQL伺服器互動，是日常與MySQL伺服器打交道最頻繁的工具。

·         客戶端應用介面（Client API）

客戶端應用介面主要是使用MySQL伺服器對外公佈的一些API呼叫訪問資料庫，主要有CAPI、PythonAPI以及JavaAPI。

（2）邏輯層（LogicalLayer）

MySQL邏輯層主要是包括以下幾個功能：

·         SQL引擎編譯SQL語句

將客戶端傳送的SQL語句請求透過SQL引擎將SQL語句編譯成MySQL伺服器內部存取資料的指令的過程，編譯過程包括查詢解析（QueryParser）、查詢檢查(Query check)，查詢最佳化（QueryOptimizer）以及查詢執行（Query Excution）四個階段。

·         事務控制

事務（Transaction）是由一組SQL語句組成的邏輯處理單元，這個邏輯處理單元被原子性地處理，即要麼其中的所有SQL語句全部執行成功，要麼全部失敗，沒有第三種可能。那麼MySQL是怎麼保證事務被原子性地處理呢？這就是Transactionmanagement元件的功能了。當事務全部處理完畢時，透過該元件完成決定commit還是rollback操作。

·         日誌管理

資料庫需要將所有對資料變更的操作記錄下來，以便當資料庫發生crash時做Redo或Undo操作，或者在分散式結構中將操作透過從一個計算節點共享到其他計算節點，這些功能都是透過事務日誌來控制的。

MySQL的事務日誌管理系統是Recoverymanagement元件，主要功能是持久化事務日誌以及當資料庫crash時將資料庫恢復到crash之前的一致性狀態。

·         儲存管理

資料庫中運算元據的主要場所是bufferpools，怎麼控制資料頁和索引頁在bufferpool中的狀態就是透過storagemanagement完成的，該元件主要還是對Page層面的管理，包括將頁讀入記憶體、頁的清理等。

值得一提的是，MySQL的邏輯層的上述幾個元件功能並不是MySQL特有的，而是普遍適用於DB2/Oracle等常見關係型資料庫。

（3）物理層

資料庫的物理層主要關注的是資料怎麼落地儲存以及被有效訪問的問題，MySQL的物理層設計比較特殊，MySQL提供了多種儲存引擎供使用者選擇，而且這些儲存引擎是可插拔的（Pluggable）,這是區別於業內其他關係型資料庫的一個很重要的特徵。MySQL資料庫為使用者提供了20多種可插拔的儲存引擎，比較常見的有如下列表所示幾種：

如上圖的儲存引擎中，從功能上比較接近商業資料庫功能的是InnoDB儲存引擎。從MySQL5.5開始，InnoDB成為MySQL伺服器的預設儲存引擎；而早在SunMicroSystem被Oracle收購之前的2005年，InnoDB儲存引擎就被Oracle收購。

相比較於其他MySQL儲存引擎，MySQLInnoDB儲存引擎支援以下關鍵特性：

·         多版本併發控制（MVCC）

·         行級鎖（Row-level Locking）

·         外來鍵支援（Foreign key support）

·         群集索引（Cluster Indexing）

·         可自由分配的bufferpools

·         線上資料庫備份

以下以InnoDB內部是怎麼和磁碟檔案互動的詳細架構示意圖。

如下圖是支援訪問MySQL資料庫伺服器的API介面型別，可以透過編寫程式呼叫四種API介面訪問MySQL資料庫：

·         JDBC with Connector/J

透過Java程式訪問MySQL伺服器

·         .NET with Connector/NET

使用.NET程式訪問MySQL伺服器

·         ODBC with Connector/ODBC

·         Other APIs with C Library

使用基於C語言庫的程式語言，比如C/C++語言、Python/PHP/Perl/Ruby語言等訪問MySQL資料庫。總之，MYSQL支援透過當前最流行的幾種主流語言訪問。

DB2體系架構

DB2 for LUW程式模型在DB2v9.5之前都是多程式模型，DB2v9.5之後體系架構變更為單程式多執行緒模型。

DB2是一個C/S結構，客戶端可以透過TCP/IP或IPC協議與伺服器通訊，每當客戶端與伺服器建立連線之後，會在伺服器端產生一個代理執行緒（db2agent）負責處理來自客戶端的所有請求，但是當某一時刻併發請求很多或者連線斷開時，重複地產生與銷燬代理執行緒會產生很大的系統開銷，所以DB2伺服器在啟動時建立一個常連線池來避免重複地建立/銷燬代理執行緒，但是如果某一個處理的請求非常大時，如果單個執行緒去處理效率比較低下，為了提高單個請求的處理能力，與客戶端通訊的那個代理執行緒（db2agent）可以從執行緒池中額外召集幾個執行緒（db2agentp）來共同處理某個請求。

DB2的執行緒主要分為以下幾大類：

·         常連線池內的執行緒db2agent和db2agentp：處理客戶端請求，比如從bufferpool中取請求的資料，或者將請求拆解放到預取（prefetch）佇列中供預取程式（prefetcher）從磁碟取資料使用、或者將一些DML操作記錄到日誌緩衝區（logbuffer）中等。

·         通訊管理執行緒db2tcpcm和db2ipccm：負責對來自客戶端的連線請求進行安全驗證和檢查，並與客戶端實現三次握手連線。

·         資料頁預取程式db2pfchr/頁面清理程式db2pclnr：當請求的資料不在bufferpool中時，需要預取程式db2pfchr透過非同步讀資料的方式將將所需資料從磁碟讀入bufferpool中。

DB2對資料的操縱主要在bufferpool中進行，當插入某些資料或對某些資料做了變更後形成髒頁（dirtypage）後，需要使用執行緒db2pclnr根據一定的機制定期清理bufferpool中的髒頁，一方面持久化資料，另一方面給bufferpool騰出更多可置換空間供使用。

·         日誌頁讀寫程式db2loggr/db2loggw：DB2採用的是讀日誌優先（Read logahead）的策略來持久化資料，即在將insert/delete/update的資料寫入磁碟前，必須先將對這些操作的日誌從日誌緩衝區持久化到磁碟當中，這個操作由db2loggw執行緒完成。

當需要使用持久化到磁碟的日誌恢復或撤銷某些操作時，需要從磁碟中將對應的日誌讀入到日誌緩衝區中，此時有db2loggr執行緒完成。

·         全域性死鎖檢測執行緒db2dlock：該執行緒主要是檢測系統死鎖防止因為死鎖造成的應用不可用。

以下為部分常見DB2管理工具和例項：

該執行緒主要是檢測系統死鎖防止因為死鎖造成的應用不可用。

以下為部分常見DB2管理工具和例項：

DB2例項命令

恩墨學院隸屬於雲和恩墨（北京）資訊科技有限公司，致力於提供專業高水準的與大資料培訓服務，挖掘培養大資料與資料庫人才。恩墨學院提供包括個人實戰技能培訓、個人認證培訓、企業內訓在內的全方位大資料和資料庫技術培訓。ACE級別超強師資，配備專業實驗室，沉浸式學習與訓練，專業實驗室、配備專業助教指導訓練。能迅速融入專家圈子，業內資源豐富，迅速積累職場人脈。課程包括：班、Oracle 、Oracle OCP考試等。