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

場景一：資料遷移上雲

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

作者：翟振興