發布時間:2022-12-20 | 信息來源: | 發布作者:沃趣科技
又雙叒叕,
絲滑的零停機在線遷移工具
DBMotion又發新版了!
此次版本更新,進一步加強了校驗模塊的能力,
并新增日志過濾功能、用戶遷移和用戶校驗功能,
以及修復了多項問題。
本次新增了校驗失敗表,查看不一致功能,支持準確查看一個表內的源庫和目標庫到底哪些行不一致。遷移完成之后,如果你的表只有少量行不一致,就能很直接地幫你定位出來。
目前,DBMotion基于性能的考慮,對于源庫和目標庫的數據比較,是分塊做checksum的。通過確定源庫和目標庫上每一個分片的checksum的一致性來確定表是否一致,加快對比的速度。這種對比方案,非常適用于表的絕大部分數據是一致的情況,用戶校驗完成后只需要著重關注不一致的表。
舉個例子,當用戶A使用DBMotion構建遷移任務,配置并完成了對象/表結構的遷移、全量遷移和增量遷移后,開始使用數據校驗進行結果比對。在正常情況下,DBMotion遷移過來的數據應該跟源庫是一模一樣的,但是不管是增量同步、部分延遲、數據已在目標庫被修改或是其他的原因,校驗出數據后,部分表還是會出現不一致。
DBMotion新的版本允許用戶點擊“查看不一致”請求,去查看該校驗失敗的表到底是哪里不一致:
如圖所示,該表中有三行不一致,頁面顯示為:
明顯可以看到:
id=1的行,目標庫多,只在目標庫存在這一行記錄(藍色)。
id=2的行,字段值不一致,age列在源庫是2(綠色),在目標庫上是4(藍色)。
id=4的行,目標庫少,只在源庫上存在這一行記錄(綠色)。
DBMotion將源庫數據遷移到目標庫,能夠最大程度保證對象和數據的一致性。對于數據量特別大但只有很少一部分數據不一致的表來說,“查看不一致”可以精確定位到這些不一致的數據,明確到底是源庫的數據、目標庫的數據或是某一行數據的列不一致,從而確認導致數據不一致的原因。
在分析binlog日志時,如果發現最近的日志中正好有刪除id=1,新增id=4和修改id=2的age值從2變為4的操作。那么,幾乎可以確定這幾行數據就是由于增量復制延遲而導致的,可采用增量同步追上的方式。如發現部分數據沒有同步到目標庫,也可以手工將這一部分數據導入目標庫,確保數據的最終一致性。
這個功能也可能會有一定的副作用:從源庫和目標庫查詢數據不一致的信息時,需要從源庫和目標庫上拉取數據,對網絡、IO有較大影響。如果出現太多源庫和目標庫的數據不一致,建議用戶對相關表進行全量重新同步,來保證數據的一致性。
為了盡量降低這個副作用,查看不一致功能目前只支持查看500條數據不一致的行。如DBMotion查詢到不一致數據達到501行,會提醒用戶,并不再繼續查找。
數據校驗是遷移任務的兜底工作,可以保證遷移前后數據的一致性。DBMotion在這一塊花費了大量的精力進行打磨,后續版本會繼續加強相關功能。
除查看不一致行之外,這次發布還新增了以下功能:
增加日志過濾功能。通過關鍵字、遷移步驟、錯誤級別、時間范圍的篩選,用戶可以將關注的特定日志篩選出來,便于診斷。
增加用戶遷移和用戶校驗功能。保證用戶所選的信息能及時遷移到目標庫,并且在對象校驗時比對目標庫用戶是否存在,密碼是否跟源庫一致。
DBMotion還對以下問題進行了修復:
1.#1168 全量同步時,OOM的問題;
2.#1169 連續DDL時,增量同步報錯;
3.#1309 全量遷移時,syntax error報錯;
4.#1320 預檢查時源端或目標端連接失敗,返回信息不明確等問題。
通過修復這些問題,進一步提升了產品穩定性和可用性。
這些功能的更新,想先人一步使用嗎?
趕緊上Squids體驗吧,
絲滑的DBMotion在線等你!