從SQL Server到MySQL，近百億數據量遷移實戰

從SQL Server到MySQL，近百億數據量遷移實戰

狄敬超（3D） 2018-05-29 10:52:48 212

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

 

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

 

本文主要向你們介紹，從 SQL Server 遷移到 MySQL 所面臨的問題和咱們的解決方案。

 

遷移方案的基本流程

 

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

• 遷移先後的數據一致性；

• 業務停機時間；

• 遷移項目是否對業務代碼有侵入；

• 須要提供額外的功能：表結構重構、字段調整。

 

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

 

數據庫停機遷移的流程：

 

 

停機遷移邏輯比較簡單，使用 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 存儲過程轉換建議。

 

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

 

 

在實際進行中，還額外遇到了一個用來解決樹形結構存儲的字段類型 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，他們關注的特性，不能知足互聯網公司對性能、遷移耗時的要求。簡單篩選後，如下幾款工具進入了咱們候選列表（爲了作特性對比，加入幾個同構數據庫遷移工具）：

 

 

因爲異構數據庫遷移，真正可以進入咱們選型的只有 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。

 

小結

 

基於這幾種方案咱們打了一套組合拳。通過將近一年的使用，進行了 28 個通宵，遷移了 42 個系統，完成了包括用戶、訂單、支付、電商、學習、社羣、內容和工具的遷移。遷移的數據總規模接近百億，全部遷移項目均一次成功。遷移過程當中積累了豐富的實戰經驗，保障了業務快速向前發展。

 

在線遷移的原理和流程

 

上文介紹了從 SQL Server 到 MySQL 異構數據庫遷移的基本問題和全量解決方案。全量方案能夠知足一部分場景的需求，可是這個方案仍然是有缺陷的：遷移過程當中須要停機，停機的時長和數據量相關。對於核心業務來講，停機就意味着損失。好比用戶中心的服務，以它的數據量來使用全量方案，會致使遷移過程當中停機若干個小時。而一旦用戶中心中止服務，幾乎全部依賴於這個中央服務的系統都會停擺。

 

能不能作到無縫地在線遷移呢？系統不須要或者只須要極短暫的停機？做爲有追求的技術人，咱們必定要想辦法解決這些問題。

 

針對 Oracle 到 MySQL，市面上已經有比較成熟的解決方案——alibaba 的 yugong 項目。在解決 SQL Server 到 MySQL 在線遷移以前，咱們先研究一下 yugong 是如何作到 Oracle 的在線遷移。

 

下圖是 yugong 針對 Oracle 到 MySQL 的增量遷移流程：

 

 

這其中有四個步驟：

1. 增量數據收集（建立 Oracle 表的增量物化視圖）；

2. 進行全量複製；

3. 進行增量複製（可並行進行數據校驗）；

4. 原庫停寫，切到新庫。

 

Oracle 物化視圖（Materialized View）是 Oracle 提供的一個機制。一個物化視圖就是主庫在某一個時間點上的複製，能夠理解爲是這個時間點上的 Snapshot。當主庫的數據持續更新時，物化視圖的更新則是要經過獨立的批量更新完成，稱之爲 refreshes。一批 refreshes 之間的變化，就能夠對應到數據庫的內容變化狀況。物化視圖常常用來將主庫的數據複製到從庫，也經常在數據倉庫用來緩存複雜查詢。

 

物化視圖有多種配置方式，這裏比較關心刷新方式和刷新時間。刷新方式有三種：

• Complete Refresh：刪除全部數據記錄從新生成物化視圖；

• Fast Refresh：增量刷新；

• Force Refresh：根據條件判斷使用 Complete Refresh 和 Fast Refres。

 

刷新機制有兩種模式： Refresh-on-commit 和 Refresh-On-Demand。

 

Oracle 基於物化視圖，就能夠完成增量數據的獲取，從而知足阿里的數據在線遷移。將這個技術問題泛化一下，想作到在線增量遷移須要有哪些特性？

 

咱們獲得以下結論（針對源數據庫）：

• 增量變化：支持增量得到增量數據庫變化；

• 延遲：獲取變化數據這個動做耗時須要儘量低；

• 冪等一致性：變化數據的消費應當作到冪等，即無論目標數據庫已有數據什麼狀態，均可以無差異消費。

 

回到咱們面臨的問題上來，SQL Server 是否有這個機制知足這三個特性呢？答案是確定的，SQL Server 官方提供了 CDC 功能。

 

CDC 的工做原理

 

什麼是 CDC？CDC 全稱 Change Data Capture，設計目的就是用來解決增量數據的。它是 SQL Server 2008 新增的特性，在這以前可使用 SQL Server 2005 中的 after insert / afterdelete / after update Trigger 功能來得到數據變化。

 

CDC 的工做原理以下：

 

 

當數據庫表發生變化時候，Capture process 會從 transaction log 裏面獲取數據變化，而後將這些數據記錄到 Change Table 裏面。有了這些數據，用戶能夠經過特定的 cdc 存儲查詢函數將這些變化數據查出來。

 

CDC 的數據結構和基本使用

 

CDC 的核心數據就是那些 Change Table 了，這裏咱們給你們看一下Change Table 長什麼樣，能夠有個直觀的認識。

 

經過如下的函數打開一張表（fruits）的 CDC 功能。

 

1. -- enable cdc for db

2. sys.sp_cdc_enable_db;

3. -- enable by table

4. EXEC sys.sp_cdc_enable_table @source_schema = N'dbo', @source_name = N'fruits', @role_name = NULL;

5. -- list cdc enabled table

6. SELECT name, is_cdc_enabled from sys.databases where is_cdc_enabled = 1;

左右滑動可完整查看

 

至此 CDC 功能已經開啓，若是須要查看哪些表開啓了 CDC 功能，可使用一下 SQL：

 

1. -- list cdc enabled table

2. SELECT name, is_cdc_enabled from sys.databases where is_cdc_enabled = 1;

左右滑動可完整查看

 

開啓 CDC 會致使產生一張 Change Table 表 cdc.dbo_fruits_CT，這張表的表結構如何呢？

 

1. .schema cdc.dbo_fruits_CT

2. name            default  nullable  type          length  indexed

3. --------------  -------  --------  ------------  ------  -------

4. __$end_lsn      null     YES       binary        10      NO

5. __$operation    null     NO        int           4       NO

6. __$seqval       null     NO        binary        10      NO

7. __$start_lsn    null     NO        binary        10      YES

8. __$update_mask  null     YES       varbinary     128     NO

9. id              null     YES       int           4       NO

10. name            null     YES       varchar(255)  255     NO

左右滑動可完整查看

 

這張表的 __ 開頭的字段是 CDC 所記錄的元數據， id 和 name 是 fruits 表的原始字段。這意味着 CDC 的表結構和原始表結構是一一對應的。

 

接下來咱們作一些業務操做，讓數據庫的數據發生一些變化，而後查看 CDC 的 Change Table：

 

1. -- 1 step

2. DECLARE @begin_time datetime, @end_time datetime, @begin_lsn binary(10), @end_lsn binary(10);

3. -- 2 step

4. SET @begin_time = '2017-09-11 14:03:00.000';

5. SET @end_time   = '2017-09-11 14:10:00.000';

6. -- 3 step

7. SELECT @begin_lsn = sys.fn_cdc_map_time_to_lsn('smallest greater than', @begin_time);

8. SELECT @end_lsn = sys.fn_cdc_map_time_to_lsn('largest less than or equal', @end_time);

9. -- 4 step

10. SELECT * FROM cdc.fn_cdc_get_all_changes_dbo_fruits(@begin_lsn, @end_lsn, 'all');

左右滑動可完整查看

 

這裏的操做含義是：

1. 定義存儲過程當中須要使用的 4 個變量；

2. begintime / endtime 是 Human Readable 的字符串格式時間；

3. beginlsn / endlsn 是經過 CDC 函數轉化過的 Log Sequence Number，表明數據庫變動的惟一操做 ID；

4. 根據 beginlsn / endlsn 查詢到 CDC 變化數據。

 

查詢出來的數據以下所示：

 

1. __$start_lsn          __$end_lsn  __$seqval             __$operation  __$update_mask  id  name

2. --------------------  ----------  --------------------  ------------  --------------  --  ------

3. 0000dede0000019f001a  null        0000dede0000019f0018  2             03              1   apple

4. 0000dede000001ad0004  null        0000dede000001ad0003  2             03              2   apple2

5. 0000dede000001ba0003  null        0000dede000001ba0002  3             02              2   apple2

6. 0000dede000001ba0003  null        0000dede000001ba0002  4             02              2   apple3

7. 0000dede000001c10003  null        0000dede000001c10002  2             03              3   apple4

8. 0000dede000001cc0005  null        0000dede000001cc0002  1             03              3   apple4

左右滑動可完整查看

 

能夠看到 Change Table 已經如實的記錄了咱們操做內容，注意 __$operation 表明了數據庫操做：

• 1 刪除

• 2 插入

• 3 更新前數據

• 4 更新後數據

 

根據查出來的數據，咱們能夠重現這段時間數據庫的操做：

• 新增了 id 爲 1 / 2 的兩條數據；

• 更新了 id 爲 2 的數據；

• 插入了 id 爲 3 的數據；

• 刪除了 id 爲 3 的數據。

 

CDC 調優

 

有了 CDC 這個利器，意味着咱們的方向是沒有問題的，終於稍稍吁了一口氣。但除了瞭解原理和使用方式，咱們還須要深刻了解 CDC 的工做機制，對其進行壓測、調優，瞭解其極限和邊界，不然一旦線上出現不可控的狀況，就會對業務帶來巨大損失。

 

咱們先看看 CDC 的工做流程，就能夠知道有哪些核心參數能夠調整：

 

 

上圖是 CDC Job 的工做流程：

• 藍色區域是一次 Log 掃描執行的最大掃描次數：maxscans number（maxscans）；

• 藍色區域同時被最大掃描 transcation 數量控制：maxtrans；

• 淺藍色區域是掃描間隔時間，單位是秒：pollinginterval。

 

這三個參數平衡着 CDC 的服務器資源消耗、吞吐量和延遲，根據具體場景，好比大字段，寬表，BLOB 表，能夠調整從而達到知足業務須要。他們的默認值以下：

• maxscan 默認值 10；

• maxtrans 默認值 500；

• pollinginterval 默認值 5 秒。

 

CDC 壓測

 

掌握了可以調整的核心參數，咱們即將對 CDC 進行了多種形式的測試。在壓測以前，咱們還須要肯定關鍵的健康指標，這些指標有：

• 內存：buffer-cache-hit / page-life-expectancy / page-split 等；

• 吞吐：batch-requets / sql-compilations / sql-re-compilations / transactions count；

• 資源消耗：user-connections / processes-blocked / lock-waits / checkpoint-pages；

• 操做系統層面：CPU 利用率、磁盤 IO。

 

出於篇幅考慮，咱們沒法將全部測試結果貼出來，這裏放一個在併發 30 下面插入一百萬數據（隨機數據）進行展現：

 

 

 

測試結論是，在默認的 CDC 參數下面：

 

CDC 的開啓/關閉過程當中會致使若干個 Process Block，大流量請求下面（15k TPS）過程會致使約 20 個左右 Process Block。這個過程當中對服務器的 IO / CPU 無明顯波動，開啓/關閉瞬間會帶來 mssql.sql-statistics.sql-compilations 劇烈波動。CDC 開啓後，在大流量請求下面對 QPS / Page IO 無明顯波動，對服務器的 IO / CPU 也無明顯波動， CDC 開啓後能夠在 16k TPS 下正常工做。

 

若是對性能不達標，官方有一些簡單的優化指南：

• 調整 maxscan maxtrans pollinginterval；

• 減小在插入後馬上插入；

• 避免大批量寫操做；

• 限制須要記錄的字段；

• 儘量關閉 net changes；

• 沒任務壓力時跑 cleanup；

• 監控 log file 大小和 IO 壓力，確保不會寫爆磁盤；

• 要設置 filegroup_name；

• 開啓 spcdcenable_table 以前設置 filegroup。

 

yugong 的在線遷移機制

 

截至目前爲止，咱們已經具有了 CDC 這個工具，可是這僅僅提供了一種可能性，咱們還須要一個工具將 CDC 的數據消費出來，並喂到 MySQL 裏面去。

 

還好有 yugong。Yugong 官方提供了 Oracle 到 MySQL 的封裝，而且抽象了 Source / Target / SQL Tempalte 等接口，咱們只要實現相關接口，就能夠完成從 SQL Server 消費數據到 MySQL 了。

 

這裏咱們不展開，我後續還會專門寫一篇文章講如何在 yugong 上面進行開發。能夠提早劇透一下，咱們已經將支持 SQL Server 的 yugong 版本開源了。

 

如何回滾

 

數據庫遷移這樣的項目，咱們不只僅要保證單向從 SQL Server 到 MySQL 的寫入，同時要從 MySQL 寫入 SQL Server。

 

這個流程一樣考慮增量寫入的要素：增量消費、延遲、冪等一致性。

 

MySQL 的 binlog 能夠知足這三個要素，須要注意的是，MySQL binlog 有三種模式，Statement based、Row based 和 Mixed。只有 Row based 才能知足冪等一致性的要求。

 

確認理論上可行以後，咱們同樣須要一個工具將 binlog 讀取出來，而且將其轉化爲SQL Server 能夠消費的數據格式，而後寫入 SQL Server。

 

咱們目光轉到 alibaba 的另一個項目 Canal。Canal 是阿里中間件團隊提供的 binlog 增量訂閱 & 消費組件。之因此叫組件，是因爲 Canal 提供了 Canal-Server 應用和 Canal Client Library，Canal 會模擬成一個 MySQL 實例，做爲 Slave 鏈接到 Master 上面，而後實時將 binlog 讀取出來。至於 binlog 讀出以後想怎麼使用，權看用戶如何使用。

 

咱們基於 Canal 設計了一個簡單的數據流，在 yugong 中增長了這麼幾個功能：

• SQL Server 的寫入功能

• 消費 Canal 數據源的功能

 

Canal Server 中的 binlog 只能作一次性消費，內部實現是一個 Queue，爲了知足咱們能夠重複消費數據的能力，咱們還額外設計了一個環節，將 Canal 的數據放到 Queue 中，在將來任意時間能夠重複消費數據。咱們選擇了 Redis 做爲這個 Queue，數據流以下：

 

 

最佳實踐

 

數據庫的遷移在去 Windows 中，是最容不得出錯的環節。應用是無狀態的， 出現問題能夠經過回切較快地回滾。但數據庫的遷移就須要考慮周到，作好資源準備，發佈流程，故障預案處理。

 

考慮到多個事業部都須要經歷這樣一個過程，咱們項目組將每個步驟都固化下來，造成了一個最佳實踐。咱們的遷移步驟以下，供你們參考：

 

 

參考連接

• MySQL :: Guide to Migrating from Microsoft SQL Server to MySQL: https://www.mysql.com/it/why-mysql/white-papers/guide-to-migrating-from-sql-server-to-mysql/

• mysqldump: https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html

• mysqlimport: https://dev.mysql.com/doc/refman/5.7/en/mysqlimport.html

• pt-table-sync: https://www.percona.com/doc/percona-toolkit/LATEST/pt-table-sync.html

• XtraBackup: https://www.percona.com/software/mysql-database/percona-xtrabackup

• Database migration and synchronization tools: https://www.convert-in.com/

• DataX: https://github.com/alibaba/DataX

• yugong: https://github.com/alibaba/yugong

• MySQL Workbench: https://www.mysql.com/cn/products/workbench/

• Data Integration - Kettle: https://community.hds.com/docs/DOC-1009855

• Ispirer: https://www.ispirer.cn/products/sql-server-to-mysql-migration

• DB2DB 數據庫轉換工具: http://www.szmesoft.com/DB2DB

• Navicat Premium: https://www.navicat.com/en/products/navicat-premium

• DBImport: http://www.cnblogs.com/cyq1162/p/5637978.html

• Meituan-Dianping/SQLAdvisor: https://github.com/Meituan-Dianping/SQLAdvisor

• Materialized View Concepts and Architecture：https://docs.oracle.com/cd/B10500_01/server.920/a96567/repmview.htm

• Tuning the Performance of Change Data Capture in SQL Server 2008 | Microsoft Docs：https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008/dd266396(v=sql.100

• alibaba/yugong: 阿里巴巴去Oracle數據遷移同步工具(全量+增量,目標支持MySQL/DRDS)：https://github.com/alibaba/yugong

• alibaba/canal: 阿里巴巴mysql數據庫binlog的增量訂閱&消費組件 。阿里雲DRDS( https://www.aliyun.com/product/drds )、阿里巴巴TDDL 二級索引、小表複製powerd by canal.：https://github.com/alibaba/canal)

原文地址：http://dbaplus.cn/news-157-2067-1.html