云時代已經來臨，云上很多場景下都需要資料的遷移、備份和流轉，各大云廠商也大都提供了自己的遷移工具，本文主要介紹京東云資料庫為解決用戶資料遷移的常見場景所提供的解決方案，

場景一：資料遷移上云

資料遷移上云是最常見的一類場景，目前京東云提供了兩個DTS（Data Transformation Service）遷移工具供選擇，一個是資料遷移，一個是資料同步：

二者的主要區別如下：

下面是這兩個工具使用中的一些常見問題：

01 兩個遷移工具的原理是什么？

以MySQL為例，兩個工具都有全量遷移/增量遷移/資料校驗三個階段，這三個階段的主要原理如下：

全量階段：

資料遷移使用mysqldump --single-transaction來取得一致性快照，但無法保證非事務引擎表的資料一致性，加上增量才可以保證資料的最終一致性，這個程序是串行操作；

資料同步使用多表并行的select方式，根據主鍵順序分批獲取記錄，回圈執行，如果沒有主鍵，則進行全表查詢，為了最大限度減少對源實體的影響，這個程序不加鎖，也不用開啟事務獲得一致讀，因此全量期間遷移的資料是不一致的，通過增量階段可以達到最終一致性，所以資料同步只提供了‘全量+增量’和‘增量’兩種選項，不提供單獨的‘全量’選項，

增量階段：

資料遷移和資料同步一樣，都是通過遷移啟動前記錄的gtid點位，抓取對應binlog同步apply到目標端，二者區別在于遷移是串行的，同步會將同一個表的事務合并后一次提交，效率更高，

資料校驗：

將源庫的資料分塊計算crc，每個塊的元資料和校驗資訊記錄到目標實體_jdts_check為前綴的庫下checksum表中，目標庫同步完成后根據同樣演算法進行計算，比較對應塊號的crc值是否一致來判斷校驗是否成功，

02 遷移速度可以調整嗎？

資料遷移不可以，資料同步可以選擇更大的遷移實體和增加更多的并發來調整，但由于并發機制是基于表粒度的，對于少量大表的情況，增加并發并不會有明顯作用，

03 遷移進度為什么顯示超過100%？

為了效率更高，遷移顯示的進度是根據已經遷移的記錄數除以資料字典記錄的記錄數顯示，資料字典的值并不完全準確，因此理論上會出現進度超過100%的現象，

04 遷移延時為什么很長？

大多情況是源庫寫操作壓力大導致目標庫binlog apply進度趕不上源庫的寫入速度，也有可能是目標庫讀寫壓力大或者遷移實體壓力大，具體需要聯系京東云技術服務及時介入，

05 遷移期間目標庫是否可以讀寫資料？

理論上可以讀寫，但不建議在遷移期間操作，主要有兩個弊端：

• 寫入臟資料會導致校驗不一致，
• 讀寫資料會導致目標庫壓力增大，級訓資料同步速度，

06 目標端如果有同名庫表是否會被覆寫？

不會的，如果目標庫庫表有資料，預檢的時候會報錯不通過；如果是空的庫表，則可以直接寫入，

07 自檢提示源或目標庫網路不通怎么辦？

檢查源庫和目標庫的白名單限制，需要加上dts遷移實體的ip，在遷移任務配置的時候會在頁面提示，

08 目標庫中的_jdts為前綴的庫可以洗掉嗎？

遷移完成可以洗掉，

09 可以從只讀實體同步嗎？

只要源實體是gtid方式復制的，都可以通過主實體或只讀實體同步，

10 資料遷移選擇內網時，為啥只能用json格式，不能圖形化選擇庫表？

因為資料遷移創建任務的時候，遷移實體還未創建，無法判斷內網連通性；資料同步已經做了改進，內外網均可以通過圖形化方式選擇庫表，

11 遷移期間對源實體有影響嗎？

無論資料遷移還是資料同步，都需要對源實體庫表做select，會有一定的讀IO壓力，建議盡量在業務低峰期同步或從只讀實體同步，對于資料同步任務， 可通過控制臺暫停任務，待源庫負載降低，再啟動資料同步任務，

12 mysql系統庫應該如何遷移？

目前不支持遷移MySQL庫，建議用戶遷移時提前在目標庫創建配置好對應的用戶和權限，或者通過mysqldump等工具從源庫匯入，

13 遷移程序出現Got fatal error 1236 ... 的報錯怎么辦？

這個報錯可能會在增量遷移程序出現，主要原因是增量需要的binlog在源端被洗掉所致，因此遷移期間盡量將源端binlog保留較長的時間，如果出現此類報錯，如果無法找回被刪binlog，只能重新開始遷移，

14 源端目標端版本必須一致嗎？

資料遷移要求兩邊版本一致；資料同步目前支持低->高版本遷移，

場景二：異地災備

用戶經常會對資料有異地災備的需求，京東云目前提供了兩種方式，一種是可以配置跨地域備份同步，如下圖：

這種方式簡單免費，會定期將最新備份同步到異地，缺點是資料是非實時的，如果災備恢復會有資料丟失，

另外一種方案是災備同步（目前暫只支持MySQL），可以在京東云控制臺創建一個異地災備實體，然后利用DTS的資料同步功能將災備實體和源實體進行資料同步，同步方式選擇災備同步，和普通同步機制不同，災備同步利用的是MySQL的原生復制，因此災備實體和源實體是完全一致的，相當于一個異地的只讀實體，這樣就可以達到異地災備的目的，

對于災備實體，有幾點需要注意：

• 災備實體目前只支持和京東云MySQL進行同步，暫不支持自建或第三方云實體，
• 災備實體無法進行變配/重啟/主從切換等操作，需要提前選好規格，
• 災備實體也是主從實體，可以讀但無法進行寫操作，類似異地只讀實體，可以手工提升為主備實體，
• 災備實體是基于dts同步的，一旦手工結束同步，災備實體將自動提升為普通主備實體，

場景三：資料訂閱

很多業務場景都會用到資料訂閱，比如訂閱資料到ES擴展搜索、上下游訂閱價格變更/服務通知、多業務庫資料合并/構建寬表等，京東云提供了資料訂閱功能來滿足類似需求，目前源端支持
MySQL/Percona/MariaDB/PostgreSQL，目標端僅支持Kafka，

目標端使用json格式記錄訂閱資訊，下面是一個update操作的例子：

{
"version": "0.1",
"database": "dbtest",
"table": "t1",
"type": "update",
"ts": 1582617997,
"time_zone": "Asia/Shanghai",
"host": "mysql-internet-cn-north-1-c52cb616874d4d29.rds.jdcloud.com",
"data": {
"created": "2020-02-25 16:01:46",
"flag": "10691",
"info": "dts_test",
"pkid": "11663",
"uuid": "11cae53d-57a5-11ea-98a6-fa163ea31339"
},
"old": {
"created": "2020-02-25 16:01:46",
"flag": "10691",
"info": null,
"pkid": "11663",
"uuid": "11cae53d-57a5-11ea-98a6-fa163ea31339"
},
"pks": {
"pkid": "11663"
}
}

資料訂閱有幾點需要注意：

• 訂閱的訊息長度如果超過中間件的最大訊息長度，訊息將被丟棄，因此理論上會有丟失資料風險，
• 目標端接受的資料起點默認為訂閱的實時時間點，如果需要全量訂閱可以聯系京東云技服人員，

場景四:自建MySQL和云上MySQL相互復制

用戶經常有這樣的需求，是否可以用自建MySQL來同步云上MySQL？或者反過來，是否可以云上MySQL作為自建MySQL的從庫來滿足某些場景？

• 從MySQL復制機制來看，理論上應該都是可以的，但京東云的賬號不支持賦予super權限，無法執行change master操作，所以云上MySQL無法作為自建MySQL的從庫，
• 反過來，自建MySQL可以有super權限，是可以作為云上MySQL的從庫，但這個是非標準操作，并不建議用戶使用，主要原因是在某些情況下，會造成復制中斷，比如云上MySQL配置變更后需要主從切換，而此時自建從庫和切換前的源主庫有復制延遲，部分binlog還未傳遞到自建從庫，此時主從切換后復新主庫由于沒有這些binlog，會造成自建從庫報1236的錯誤，針對這種情況，用戶可以在擴容時選擇延遲切換，可以避開業務高峰，在一定程度上避免類似問題，

作者：翟振興

標籤：其它

上一篇：「MySQL高級篇」explain分析SQL，索引失效&&常見優化場景

下一篇：說說 Redis 事務