線上資料遷移,數字化時代的必修課 —— 京東雲資料遷移實踐
打破資料邊界,是數字化時代常掛在嘴邊的一句話,資料的價值是在流動中體現的,資料應用也是如此。以往為了滿足開發、測試、資料保護容災和資料分析的需要,我們不斷對資料進行復制、備份、遷移,因此資料遷移非常重要。
資料遷移的常見場景
今天我們來重點聊聊混合雲時代中資料遷移,先來看看常見的幾種企業資料遷移的需求與場景:
-
傳統上雲:裝置老舊,需要升級,硬體升級價效比不高,雲上更經濟;
-
跨雲遷移:綜合對比多家廠商價格,靈活選型採用成本最優方案;
-
災備遷移:需要多雲、異構雲來架構自己的災備體系,保證資料的安全;
-
異地開服:服務不同地域的使用者,因各地網路質量不一致需要多雲模式用於構建服務本地使用者的遊戲伺服器;
-
資料安全:要符合金融安全政策的要求,需要資料的遷移。
這些客戶都因系統和技術升級、業務發展、以及安全合規等因素採用混合多雲的方案,同時對其資料的遷移有著很高的訴求,在不同的業務模式和需求下也會面臨多種問題。
資料遷移的困境
資料庫的發展多樣性提升遷移門檻
在面對關係型資料庫與非關係型資料庫之間的遷移,關係型資料庫SQL RDBMS發展久,遷移生態工具齊全,且大部分資料庫產品都自帶遷移工具;而非關係NoSQL,資料定義更寬鬆,產品體積輕量,放棄了一致性校驗,導致某些資料結構濫用,提升了遷移難度。而遷移工具大部分開放給生態來做,由於發展時間較短,工具完善度不如RDBMS高。
廠商試圖“資料綁架”,使遷移雪上加霜
分析完關係型資料庫到非關聯式資料庫的發展,可以看到資料儲存結構本身已發生了巨大的變化,這從根因上已大幅提升了遷移的難度,而一些雲廠商對資料庫的再次改造,且對關係型資料庫底層改造不透明,導致資料庫的複雜性大大加大,試圖用資料遷移成本高來長期繫結客戶,更是令資料的遷移雪上加霜。
“個體差異”導致通用型解決方案缺失
不同的企業由於自身需求不同與使用場景的多樣性,每一個客戶,對我們來說都是一個新的案例,我們必須“量身定製”化服務,但在過程中我們也總結出幾類常見難點:
-
難點一:多節點資料庫遷移,節點數量不一致
-
難點二:原生產品跨版本問題,版本不一致且上下版本相容性不夠好
-
難點三:快取類資料易失性更高
大規模生產實踐,練就京東雲資料遷移優勢
2019年京東物流為了實現其輕資產化、降低成本、升級架構的三大目的,將其ES開始由本地機房遷移到雲上。依託京東云云搜尋ES高可用、易擴充套件、近實時等特性,京東物流成功地將分揀中心自動化系統、冷鏈流程監控系統、開放訂單跟蹤系統等上百個系統遷移上雲。
京東雲不僅提供了常規的停機遷移方案,還提供了特殊的不停機遷移方案,保證了物流業務不停服。
不停機遷移方案如下:在雲端建立新叢集,將雲上叢集和使用者叢集合併成一個大叢集,利用Elasticsearch資料分佈API(cluster.routing.allocation.exclude)將使用者叢集中的索引資料遷移到雲上叢集的資料節點,最後將使用者叢集和雲上叢集構成的大叢集拆分,關閉使用者叢集即可完成遷移。(採用這種方式須注意同時滿足以下兩個條件:使用者叢集版本和雲上叢集版本相同;使用者叢集所有節點和雲上叢集所有節點網路能夠互通。)
透過上述方法,很快就就完成了京東物流近百個系統的數百個叢集、數千個節點資料上雲工作。在此之上京東雲還配套提供了一鍵報警等核心功能,對上雲工作進行全天候、全方位的保障。截止目前,京東物流已有超過90%的應用在公有云上部署了例項,去年11.11期間業務量超過日常三倍以上的情況下,整體運營平穩。
“對症下藥”,自研關係型資料庫遷移利器—— 資料傳輸DTS
關係型資料庫依然是各行業的主流應用之一,怎樣更快的將傳統關係型資料中的資料遷移上雲也是很多行業使用者關心的。為此京東雲特意打造了一款針對關係型資料庫的遷移工具——資料傳輸DTS。
資料傳輸DTS 提供實時資料流服務,支援資料遷移、資料訂閱和資料同步服務,可簡單方便的滿足資料上雲、業務非同步解耦、資料異地災備、業務系統資料流轉等業務場景。目前資料傳輸DTS支援MySQL、MariaDB、Percona、SQL Server、PostgreSQL等多種資料庫遷移,可以簡單快速地將本地自建資料庫遷移至京東雲,源資料庫在遷移過程中可繼續正常執行,從而最大程度地減少應用程式的停機時間。
自研RedisSyncer線上遷移工具,打造線上遷移優勢
Redissyncer1.0:貼近需求,技術創新
某家線上廣告公司需要將Redis從自有機房遷移到雲上。客戶系統承載著大量結算快取和業務快取,要求在遷移過程中不能有業務中斷。當時有一些開源工具,但是不滿足要求。主要是由於版本問題,客戶用的Redis版本是4.0而當時開源的工具只支援3.28及以下版本。本著京東雲客戶業務為先的原則,和鼓勵創新的技術精神,我們思考,能不能為客戶自研一套工具,能夠Cover住Redis資料流轉大部分場景的通用工具,於是2019年7月Redissyncer 1.0版本誕生,並持續經歷幾個行業的應用實踐:
-
網際網路行業使用者,Redis單例項,資料體量不大20Gb左右。透過啟動引數修復、調整每批次Value值等細節最佳化順利完成了遷移任務;
-
遊戲行業的使用者,使用者需要將自有IDC中的Redis遷移到京東雲。在使用我們的產品之前,使用者自己找過若干開源產品但都不符合要求。由於使用者的例項數量較多,在瞭解過Redissyncer產品特性後,使用者決定使用我們的工具自行遷移。
Redissyncer2.0:多場景歷練,滿足多類需求
在剖析過更多客戶痛點與需求後,2019年11月底,Redissynce2.0版本升級。完善了同步模式拆分、斷點續傳、離線檔案載入、跨版本遷移、流式載入等功能。
金融使用者。使用者需要將原生Redis叢集遷移到自研的Redis叢集。目標叢集節點數多大16*2即16對主從構成的叢集,遷移過程很順利,經過準備15分鐘完成應用割接。
Redissyncer3.0:精益求精,更好體驗
持續經過嚴苛生產場景的打磨,我們陸續修復了一些測試中很難遇到的bug,新增了一些新特性。使得產品不僅支援升級遷移同時支援降級遷移;為了提高使用者體驗,我們參考Redis、MySQL等優秀開源產品的方式做了一個命令列客戶端命名為redissyncer-cli。至此,完成了Redissyncer3.0的升級,這個專案的體系建設基本上可以滿足Redis遷移同步場景中的大部分需求了。
擁抱開源,開放共進
目前京東雲已經積累了覆蓋網際網路、遊戲、金融、物流、零售等多場景領域的遷移經驗。隨著混合多雲趨勢到來,我們深知使用者遷移之苦,也願意以相容開放的心態為客戶提供技術服務,真正做到把選擇權交給使用者,同時為了讓更多人享受技術帶來的便利,我們在今年決定將自研Redissyncer完全開源,將技術迴歸社群,給更多使用者和開發者帶來便利!
歡迎點選【 京東科技 】,瞭解開發者社群
更多精彩技術實踐與獨家乾貨解析
歡迎關注【京東科技開發者】公眾號
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69912185/viewspace-2763735/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- kafka資料遷移實踐Kafka
- Datapump資料遷移的實踐總結
- 遷移資料.
- 資料庫線上遷移的設想資料庫
- 資料的遷移
- 【遷移】使用rman遷移資料庫資料庫
- cassandra百億級資料庫遷移實踐資料庫
- Jenkins搭建與資料遷移實踐Jenkins
- PgSQL·最佳實踐·雲上的資料遷移SQL
- 【資料遷移】使用傳輸表空間遷移資料
- Mongo資料遷移實驗Go
- Kafka資料遷移Kafka
- 資料庫遷移資料庫
- redis資料遷移Redis
- 轉資料遷移
- ORACLE 資料遷移Oracle
- DXWB 資料遷移
- Harbor資料遷移
- 京東雲開發者|京東雲RDS資料遷移常見場景攻略
- Hadoop資料遷移MaxCompute最佳實踐Hadoop
- 資料庫平滑遷移方案與實踐分享資料庫
- 【資料遷移】RMAN遷移資料庫到ASM(三)遷移onlinelog等到ASM資料庫ASM
- 伺服器資料遷移的方法-硬體不同如何遷移資料伺服器
- 線上遷移表空間資料檔案
- 資料遷移(1)——通過資料泵表結構批量遷移
- 【Redis 技術探索】「資料遷移實戰」手把手教你如何實現線上 + 離線模式進行遷移 Redis 資料實戰指南(scan模式遷移)Redis模式
- 資料庫遷移之資料泵實驗資料庫
- 資料檔案的遷移
- gitlab資料遷移Gitlab
- 資料庫遷移 :理解資料庫
- Mysql資料遷移方法MySql
- Fastdfs資料遷移方案AST
- 【Redis】 redis資料遷移Redis
- 【Hive】hive資料遷移Hive
- laravel資料庫遷移Laravel資料庫
- Odoo遷移資料庫Odoo資料庫
- exp,imp 遷移資料
- NAS資料遷移初探