910      汽車大全

從商用到開源：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穩居第二名直逼第一名。參考鏈接：https://db-engines.com/en/ranking

• 在性能上，從我們與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語句編譯成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線程完成。

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

該線程主要是檢測係統死鎖防止因為死鎖造成的應用不可用。

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

DB2實例命令

本文來自雲棲社區合作夥伴“數據和雲”，了解相關信息可以關注“數據和雲

最後更新：2017-11-29 00:34:08

  上一篇：  達摩院：阿裏巴巴的科技雄心

  下一篇：  11月27日雲棲精選夜讀：阿裏畢玄：智能時代，運維工程師在談什麼？