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

場景一：數據遷移上雲

數據遷移上雲是最常見的一類場景，目前京東雲提供了兩個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的錯誤。針對這種情況，用戶可以在擴容時選擇延遲切換，可以避開業務高峰，在一定程度上避免類似問題。

作者：翟振興