DBMotion——MySQL遷移利器

最近有一批 MySQL 資料庫要做一下資料遷移 ， 由於之前經歷過大批次資料庫遷移 ， 心力憔悴 。 因此 ， 接手這個任務的時候 ， 感覺肝部有些隱隱作痛 。

由於遷移的時候有各種場景 ， 如同版本 、 跨版本 、 全量遷 、 部分遷 、 可停機 、 不可停機等 ， 所以需要事先部署各種開源工具 。 比如 xtrabackup 、 mydumper 、 pt - table - checksum 等工具 ， 來進行物理遷移 、 邏輯遷移以及資料校驗 。 另外 ， 還要提前進行檢查 、 評估 、 跨部門會議 、 遷移 、 校驗 、 回退等各項繁雜的規劃 。 在無數個深夜裡 ， 各種命令列指定一頓敲 ， 敲的時候還要找幾個人趴在螢幕上一字一句的核對 ， 簡直要瞎了一雙狗眼 。 就沒有一款能讓我端著咖啡點點選選就把遷移給做完的工具嗎 ？ 我默默地在心底發出疑問 。

經朋友推薦 ， 瞭解到了 DBMotion 這個工具 。 看了下簡介和演示 ， 好像很符合我期望中遷移工具的形態 ， 那用起來到底怎麼樣呢 ？ 於是我用這個工具做了一些驗證 。

首先是 DBMmotion 的獲取方式 ， 在瀏覽器輸入 squids.cn 進入網頁 ， 然後翻到最下面 ， 找到智慧小工具 ， 點選 DB M otion 進入 DBM otion 的主頁 。

DBMotion 主頁中有演示影片 ， 對 DBMotion 做了一些介紹 。 使用的話 ， 可以本地利用 docker 搭建 ， 或者點選免費試用直接適用線上環境 。 在這裡 ， 點選免費使用 ， 用一下線上環境 。

點選免費使用後進入到了 DBMotion 的控制檯 ， 頁面比較簡潔 ， 資料傳輸裡面就一個新增任務的按鈕 ， 點一下試試 。

點選新增任務後 ， 看到了熟悉的介面 。 無非是輸入源端目標端的的資料庫 IP 、 埠 、 賬號 、 密碼 ， 另外給了遷移所需要的最小許可權的授權語句 . 由於我對賬號沒做什麼限制 ， 就直接用 root 賬號了 。 遷移方式這裡還提供了三種遷移方式 ， 分別是 M y SQL   to  M y SQL 、 M y SQL to   C lick H ouse ， M ongo   to   M ongo ， 這裡主要關注 M y SQL to  M y SQL 。

輸入源端目標端的資料庫資訊後 ， 測試連線透過後 ， 就進入了遷移選項頁面 。 頁面中可以選擇需要遷移的使用者和 DB ， 還可以指定併發數 、 遷移結構 、 資料及是否同步增量資料 。

這裡選了一個測試的 DB ， 包含 10 張 500 W 的表及測試使用者 。 做一下全量 + 增量的遷移 ， 點選下一步就進入了預檢查的頁面 。 預檢查頁面會有遷移的內容 ， 遷移的資料量大小及耗時評估 。 11 G 預估 5 分鐘遷移完 ， 每秒大概 30 多 M ， 速度還不錯 。 不過這應該是指最大速度 ， 我兩個環境之間的頻寬是 40 M 的 ， 能達到 5 M / s 就不錯了 ， 這裡預估的時候應該沒考慮到頻寬 。 另外 ， 還有一些影響遷移及遷移後使用的一些檢查 ， 並會給出修復建議 ， 省了自行檢查的功夫 。 細看了下預檢查的項 ， 還有 binlog 保留時間以及 procedure 等物件的定義者檢查 。 之前踩過這方面的坑 ， 感覺預檢查的內容還是挺全面的 。

看完預檢查後點選建立就進入了正式遷移 ， 在控制檯生成了此次遷移的任務 。

點選任務名稱進入遷移詳情 ， 看看都有些啥 。 可以看到有物件遷移 、 全量遷移等欄目 ， 增量遷移和資料校驗等都是灰色的 ， 因為還沒有進入到增量遷移的步驟 。 看了下物件遷移 ， 主要是顯示錶結構 、 儲存過程 、 函式等物件的遷移情況 。 又著重看了下全量遷移的顯示 ， 可以看到遷移進行的時間 、 預計剩餘的時間以及遷移進度及速度 。 感覺還不錯 ， 能讓人心裡對當前遷移的進度有個直觀的判斷 ， 方便向領導彙報進度 ， 比之前命令列的方式感受要好很多 。 此外還有每個表的遷移詳情 ， 看起來更加直觀 。 另外實時速度有 4 M 左右 ， 基本已經把頻寬打滿了 ， 也符合了我之前對遷移預估時間的猜測 。

遷移過程中 ， 我到源庫中 genral   log 以及 show   processlist 看了一下 ， 沒有發現加鎖的情況 ， 感覺比較奇怪 ， 不加鎖怎麼保證我資料的一致性呢 ？ 後面諮詢了下官方的技術人員 ， 得知 DBMotion 遷移過程中不會對資料庫加鎖 ， 因為增量的時候會將全量遷移時刻開始的資料往後重做一遍 ， insert 會改為 replace ，delete 刪除成功就刪除了，刪除失敗就忽略， update 只要不更新主鍵就做成 replace ，如果是更新主鍵，就做成 delete+replace ， 但前提是全量遷移過程中不要做 DDL 。 按照這個邏輯推演了一下 ， 確實可以實現最終一致性 ， 至於全量過程中不做 DDL ， 這個提前和業務宣告一下就好了 。

遷移全程無鎖 ， 想想感覺就很舒服 。 之前遷移的時候 ， 老是有某些連線沒停乾淨 ， 導致我做備份加鎖失敗 ， 去掉加鎖後還能實現資料一致性 ， 在這裡給個好評 。

全量完成後 ， 增量遷移的詳情也可以點進去了 。 主要想關注下增量進度的顯示 ， 看到有專門的延遲顯示 ， 還是符合期望值的 。

然後再看一下資料校驗 。 諮詢了下官方客服 ， 校驗的時候要停業校驗 ， 看來沒有做成 pt - table - checksum 那種線上的方式 ， 不過也能接受 。 停止測試增量資料的壓測 ， 點選一下執行校驗 ， 可以看到校驗了各種物件結構以及資料 ， 資料採用了行數和 checksum 的雙重校驗方式 。

這裡模擬下不一致 ， 看看能不能校驗出來 。 模擬字符集和資料不一致後重新執行校驗 ， 檢視結果 ， 都給我校驗出來了 ， 再次好評 。 資料校驗對遷移來說還是很重要的 ， 這是一個兜底的功能 ， 資料校驗不透過我頂多不做業務切換 ， 要是資料有問題但是沒有校驗出來 ， 那可就麻煩了 。 經過我大量的不一致模擬 ， 發現 DBMotion的校驗功能還是非常靠譜的 。 千奇百怪的不一致都能給我校驗出來 ， 用起來非常踏實 ， 不過目前沒有重新同步不一致的功能 ， 加上這個功能的話就更完美了 。

校驗透過後 ， 點選結束遷移就可以完成這次遷移了 。 全程我只需要輸入一下遷移庫的資訊 ， 選擇一些要遷移的內容 ， 剩下的就完全自動化 ， 並有視覺化頁面的及時反饋 。 用我匱乏的成語儲備來形容一下整個過程 ， 就是雲淡風輕 。

  嘗試了 DBMotion 工具 ， 終於實現了我點點選選喝著咖啡完成遷移的願望了 。 我想以後我的肝會變好 ， 眼睛也會變好了 。 點點選選 ， 操作簡單 ， 全程無鎖 ， 速度喜人 。 更有強大的校驗功能來兜底 ， 你不想擁有一個嗎 ？