從 SQL Server 到 MySQL （一）：異構數據庫遷移

時間 2019-11-17

原文原文鏈接

背景

滬江成立於 2001 年，做爲較早期的教育學習網站，當時技術選型範圍並不大： Java 的版本是 1.2，C# 還沒有誕生，MySQL 尚未被 Sun 收購，版本號是 3.23。工程師們選擇了當時最合適的微軟體系，並在往後的歲月裏，逐步從 ASP 過分到 .net，數據庫也跟隨 SQL Server 進行版本升級。html

十幾年過去了，技術社區已經發生了天翻地覆的變化。滬江的技術棧還基本在 .net 體系上，這給業務持續發展帶來了一些限制。人才招聘、社區生態、架構優化、成本風險方面都面臨挑戰。集團通過慎重考慮，發起了大規模的去 Windows 化項目。這其中包含兩個重點子項目：開發語言從 C# 遷移到 Java，數據庫從 SQL Server 遷移到 MySQL。mysql

本系列文章就是向你們介紹，從 SQL Server 遷移到 MySQL 所面臨的問題和咱們的解決方案。git

遷移方案的基本流程

設計遷移方案須要考量如下幾個指標：github

遷移先後的數據一致性
業務停機時間
遷移項目是否對業務代碼有侵入
須要提供額外的功能：表結構重構、字段調整

通過仔細調研，在平衡複雜性和業務方需求後，遷移方案設計爲兩種：停機數據遷移和在線數據遷移。若是業務場景容許數小時的停機，那麼使用停機遷移方案，複雜度低，數據損失風險低。若是業務場景不容許長時間停機，或者遷移數據量過大，沒法在幾個小時內遷移完成，那麼就須要使用在線遷移方案了。web

數據庫停機遷移的流程：sql

201803/migration-db-offline-readonly.png

停機遷移邏輯比較簡單，使用 ETL（Extract Translate Load）工具從 Source 寫入 Target，而後進行一致性校驗，最後確認應用運行 OK，將 Source 表名改掉進行備份。數據庫

在線遷移的流程：微信

在線遷移的方案稍微複雜一些，流程上有準備全量數據，而後實時同步增量數據，在數據同步跟上（延遲秒級別）以後，進行短暫停機（Hang 住，確保沒有流量），就可使用新的應用配置，並使用新的數據庫。數據結構

須要解決的問題

從 SQL Server 遷移到 MySQL，核心是完成異構數據庫的遷移。架構

基於兩種數據遷移方案，咱們須要解決如下問題：

兩個數據庫的數據結構是否能夠一一對應？出現不一致如何處理？
MySQL 的使用方式和 SQL Server 使用方式是否一致？有哪些地方須要注意？
如何確保遷移先後的數據一致性？
在遷移中，如何支持數據結構調整？
如何保證業務不停狀況下面，實如今線遷移？
數據遷移後若是發現業務異常須要回滾，如何處理新產生的數據？

爲了解決以上的問題，咱們須要引入一整套解決方案，包含如下部分：

指導文檔 A：SQL Server 轉換 MySQL 的數據類型對應表
指導文檔 B：MySQL 的使用方式以及注意點
支持表結構變動，從 SQL Server 到 MySQL 的 ETL 工具
支持 SQL Server 到 MySQL 的在線 ETL 工具
一致性校驗工具
一個回滾工具

讓咱們一一來解決這些問題。

SQL Server 到 MySQL 指導文檔

很是幸運的是，MySQL 官方早就準備了一份如何其餘數據庫遷移到 MySQL 的白皮書。 MySQL :: Guide to Migrating from Microsoft SQL Server to MySQL 裏提供了詳盡的 SQL Server 到 MySQL 的對應方案。包含了：

SQL Server to MySQL - Datatypes 數據類型對應表
SQL Server to MySQL - Predicates 邏輯算子對應表
SQL Server to MySQL – Operators and Date Functions 函數對應表
T-SQL Conversion Suggestions 存儲過程轉換建議

須要額外處理的數據類型：

SQL Server	MySQL
IDENTITY	AUTO_INCREMENT
NTEXT, NATIONAL TEXT	TEXT CHARACTER SET UTF8
SMALLDATETIME	DATETIME
MONEY	DECIMAL(19,4)
SMALL MONEY	DECIMAL(10,4)
UNIQUEIDENTIFIER	BINARY(16)
SYSNAME	CHAR(256)

在實際進行中，還額外遇到了一個用來解決樹形結構存儲的字段類型 Hierarchyid。這個場景須要額外進行業務調整。

咱們在內部作了針對 MySQL 知識的摸底排查工做，並進行了若干次的 MySQL 使用技巧培訓，將工程師對 MySQL 的認知拉到一根統一的線。

關於存儲過程使用，咱們和業務方也達成了一致：全部 SQL Server 存儲過程使用業務代碼進行重構，不能在 MySQL 中使用存儲過程。緣由是存儲過程增長了業務和 DB 的耦合，會讓維護成本變得極高。另外 MySQL 的存儲過程功能和性能都較弱，沒法大規模使用。

最後咱們提供了一個 MySQL 開發規範文檔，借數據庫遷移的機會，將以前相對混亂的表結構設計作了統一了約束（部分有業務綁定的設計，在考慮成本以後沒有作調整）。

ETL 工具

ETL 的全稱是 Extract Translate Load（讀取、轉換、載入），數據庫遷移最核心過程就是 ETL 過程。若是將 ETL 過程簡化，去掉 Translate 過程，就退化爲一個簡單的數據導入導出工具。咱們能夠先看一下市面上常見的導入導出工具，瞭解他們的原理和特性，方便咱們選型。

MySQL 同構數據庫數據遷移工具：

mysqldump 和 mysqlimport MySQL 官方提供的 SQL 導出導出工具
pt-table-sync Percona 提供的主從同步工具
XtraBackup Percona 提供的備份工具

異構數據庫遷移工具：

Database migration and synchronization tools ：國外一家提供數據庫遷移解決方案的公司
DataX ：阿里巴巴開發的數據庫同步工具
yugong ：阿里巴巴開發的數據庫遷移工具
MySQL Workbench ：MySQL 提供的 GUI 管理工具，包含數據庫遷移功能
Data Integration - Kettle ：國外的一款 GUI ETL 工具
Ispirer ：提供應用程序、數據庫異構遷移方案的公司
DB2DB 數據庫轉換工具：一個國產的商業數據庫遷移軟件
Navicat Premium ：經典的數據庫管理工具，帶數據遷移功能
DBImport ：我的維護的遷移工具，很是簡陋，須要付費

看上去異構數據庫遷移工具和方案不少，可是通過咱們調研，其中很多是爲老派的傳統行業服務的。好比 Kettle / Ispirerer，他們關注的特性，不能知足互聯網公司對性能、遷移耗時的要求。簡單篩選後，如下幾個工具進入咱們候選列表（爲了作特性對比，加入幾個同構數據庫遷移工具）：

工具名稱	熱數據備份保證一致性	batch 操做	支持異構數據庫	斷點續接	開源	開發語言	GUI
mysqldump	V 使用 `single-transaction`	X	X	X	V	C	X
pt-table-sync	V 使用 transaction 或 `lock table` 的 FTWRL	V	X	V	V	Pell	X
DataX	X	V	V	X	V	Java	X
yugong	X	V	V	V	V	Java	X
DB2DB	X	V	V	X	X	.net	V
MySQL Workbench	X	?	V	X	V	C++	V

因爲異構數據庫遷移，真正可以進入咱們選型的只有 DataX / yugong / DB2DB / MySQL Workbench。通過綜合考慮，咱們最終選用了三種方案， DB2DB 提供小數據量、簡單模式的停機模式支持，足以應付小數據量的停機遷移，開發工程師能夠自助完成。 DataX 爲大數據量的停機模式提供服務，使用 JSON 進行配置，經過修改查詢 SQL，能夠完成一部分結構調整工程。 yugong 的強大可定製性也爲在線遷移提供了基礎，咱們在官方開源版本的基礎之上，增長了如下額外功能：

支持 SQL Server 做爲 Source 和 Target
支持 MySQL 做爲 Source
支持 SQL Server 增量更新
支持使用 YAML 做爲配置格式
調整 yugong 爲 fat jar 模式運行
支持表名、字段名大小寫格式變化，駝峯和下劃線自由轉換
支持表名、字段名細粒度自定義
支持複合主鍵遷移
支持遷移過程當中完成 Range / Time / Mod / Hash 分表
支持新增、刪除字段

關於 yugong 的二次開發，咱們也積累了一些經驗，這個咱們下篇文章會來分享。

一致性校驗工具

在 ETL 以後，須要有一個流程來確認數據遷移先後是否一致。雖然理論上不會有差別，可是若是中間有程序異常，或者數據庫在遷移過程當中發生操做，數據就會不一致。

業界有沒有相似的工具呢？有，Percona 提供了 pt-table-checksum 這樣的工具，這個工具設計從 master 使用 checksum 來和 slave 進行數據對比。這個設計場景是爲 MySQL 主從同步設計，顯然沒法完成從 SQL Server 到 MySQL 的一致性校驗。儘管如此，它的一些技術設計特性也值得參考：

一次檢查一張表
每次檢查表，將表數據拆分爲多個 trunk 進行檢查
使用 REPLACE...SELECT 查詢，避免大表查詢的長時間帶來的不一致性
每一個 trunk 的查詢預期時間是 0.5s
動態調整 trunk 大小，使用指數級增加控制大小
查詢超時時間 1s / 併發量 25
支持故障後斷點恢復
在數據庫內部維護 src / diff，meta 信息
經過 Master 提供的信息自動鏈接上 slave
必須 Schema 結構一致

咱們選擇 yugong 做爲 ETL 工具的一大緣由也是由於它提供了多種模式。支持 CHECK / FULL / INC / AUTO 四種模式。其中 CHECK 模式就是將 yugong 做爲數據一致性檢查工具使用。 yugong 工做原理是經過 JDBC 根據主鍵範圍變化，將數據取出進行批量對比。

這個模式會遇到一點點小問題，若是數據庫表沒有主鍵，將沒法進行順序對比。其實不一樣數據庫有本身的邏輯主鍵，Oracle 有 rowid， SQL Server 有 physloc。這種方案能夠解決無主鍵進行比對的問題。

如何回滾

咱們須要考慮一個場景，在數據庫遷移成功以後業務已經運行了幾個小時，可是遇到了一些 Critical 級別的問題，必須回滾到遷移以前狀態。這時候如何保證這段時間內的數據更新到老的數據庫裏面去？

最樸素的作法是，在業務層面植入 DAO 層的打點，將 SQL 操做記錄下來到老數據庫進行重放。這種方式雖然直觀，可是要侵入業務系統，直接被咱們否決了。其實這種方式是 binlog statement based 模式，理論上咱們能夠直接從 MySQL 的 binlog 裏面獲取數據變動記錄。以 row based 方式重放到 SQL Server。

這時候又涉及到逆向 ETL 過程，由於極可能 Translate 過程當中，作了表結構重構。咱們的解決方法是，使用 Canal 對 MySQL binlog 進行解析，而後將解析以後的數據做爲數據源，將其中的變動重放到 SQL Server。

因爲回滾的過程也是 ETL，基於 yugong，咱們繼續定製了 SQL Server 的寫入功能，這個模式相似於在線遷移，只不過方向是從 MySQL 到 SQL Server。

其餘實踐

咱們在遷移以前作了大量壓測工做，並針對每一個遷移的 DB 進行線上環境一致的全真演練。咱們構建了和生產環境機器配置同樣，數據量同樣的測試環境，並要求每一個系統在上線以前都進行若干次演練。演練以前準備詳盡的操做手冊和事故處理方案。演練準出的標準是：可以在單次演練中不出任何意外，時間在估計範圍內。經過演練咱們保證了整個操做時間可控，減小操做時候的風險。

爲了讓數據庫的狀態更爲直觀的展示出來，咱們對 MySQL / SQL Server 添加了細緻的 Metrics 監控。在測試和遷移過程當中，能夠便利地看到數據庫的響應狀況。

爲了方便 DBA 快速 Review SQL。咱們提供了一些工具，直接將代碼庫中的 SQL 拎出來，能夠方便地進行 SQL Review。再配合其餘 SQL Review 工具，好比 Meituan-Dianping/SQLAdvisor，能夠實現一部分自動化，提升 DBA 效率，避免線上出現明顯的 Slow SQL。