1、數據遷移概述前端
數據遷移，是一個很是複雜的過程，不只僅是將數據從一個地方移動到另外一個地方。這裏須要考慮業務定義、架構變動、應用改造、數據安全等諸多方面問題。在實際遷移工做中，須要結合企業的方方面面，作好合理的規劃及實施，不然極可能會致使遷移結果達不到預期，浪費人力財力。在正式開始遷移以前，有幾項工做是須要提早考慮的。數據庫
一、遷移目的
在咱們正式開展遷移以前，首先要對遷移目的有個清晰的定位。後面的不少工做的前提，正基於此。下面羅列下常見的目的，真實場景中可能包含一個或多個的組合。後端
1）成本安全
現有方案成本太高，於是考慮至低成本方案。這裏須要關注幾點：性能優化
-
遷移後方案的整體成本，不只要考慮初期採購成本，也要考慮後期維護及商業方案中過了初始幾年後的持有成本；服務器
-
遷移方案自己的成本，這裏包括經濟、時間、人力、風險成本等多種因素；網絡
-
如實施失敗時，必要的回退成本，包括所以而產生的對業務的影響所到來的經濟損失。數據結構
2）性能架構
現有方案不能知足性能要求，這裏須要考慮幾個問題：運維
-
性能要求是否合理？是常態化需求，仍是偶然高峯？將來業務增加對性能的要求多大？
-
是否可在業務側、應用側，經過必要的改造、升級知足性能要求（畢竟前端的改造代價，比後端要小的多）？
-
是否可在原有數據平臺上經過Scale Up或者Scale Out來解決性能問題？畢竟更換底層的平臺的代價很大。
3）空間
現有方案不能知足容量要求，這裏須要考慮幾個問題：
-
當前存量數據，是否可經過清理、轉儲、歸檔等手段，來減小現有容量？（水平拆分）；
-
現有數據是不是同質的，便是否可經過分拆，劃分出獨立單元來承載業務？（垂直拆分）；
-
現有存量使用及將來增量狀況，這些對於將來選型都很重要。
4）自主可控
隨着近些年來，內外部環境和自上而下的政策性要求，對於企業核心技術的自主可控要求愈來愈高。於是對於國產化需求，日益高漲。
5）技術演進
隨着企業自身的技術發展，對於後端數據平臺的要求不斷變化。例如數據中臺、微服務等興起，做爲數據載體也需求有所變化。
6）業務需求
業務發展變化，也對於支撐平臺的需求不斷變化。
7）軟硬件更換升級
軟件，技術更替、版本迭代；特別是硬件，有着明顯的週期性特色。企業按期都會避免升級替換類訴求。
二、業務場景分析
在着手遷移以前，須要對現有業務作了全面的梳理，重點是將其對數據載體的要求整理清楚。爲了知足這些業務場景，將來的遷移需求是經過單一平臺仍是經過多種異構組合來完成？這些內容對於後續遷移選型有着重要意義。在這個階段，還須要增長對將來的增加變化或業務調整致使的可能變化。能夠仿照下表，完成場景分析工做。
三、遷移需求分析
在對業務場景作好必要的分析工做後，咱們還須要針對遷移需求作更多細緻的工做。這裏包括：
1）硬件環境
業務系統使用的資源狀況（CPU、MEM、STORAGE等）這些信息，一方面可用來爲遷移後的技術選型作必定參考；另外一方面在遷移階段也需作好對現有環境影響的評估。
2）網絡環境
業務系統的網絡配置和網絡隔離狀況，包括組網邏輯、帶寬、隔離狀況。這些對遷移實施，有着必定影響。
3）操做系統
業務系統使用的操做系統，是Linux仍是Windows，是32位仍是64位，其使用的文件系統是什麼？
4）安全策略
業務系統的特殊安全要求，例如開放哪些端口、訪問權限。
5）應用系統
應用系統是採用商用的仍是自研的，使用什麼開發語言、版本是什麼，接入類型（JDBC、ODBC等）？是否有專有的開發工具開發？是否使用了非標準接口？
6）數據規模
包括總體的數據規模及設計最大規格，單體對象的最大規模（行、列）。數據特徵（結構化 or 非結構化）、數據類型等。
7）數據安全指標
RTO、RPO等。
8）性能指標
MBPS、IOPS、RT等。
四、遷移難點
1）數據安全
數據是數據遷移的基本需求，如何在整個數據遷移操做過程當中，保證數據的安全性是一項不小的挑戰。除了考慮在遷移前必要的數據備份外，還要考慮清楚遷移過程當中數據增量問題，以及出現異常問題後的安全回退等。
2）兼容性
兼容性是整個數據遷移方案得以實施的前提。這裏談到的兼容性，不只包括與原有業務應用系統的兼容，也包括與原有基礎平臺（監控、預警、備份）及其餘數據平臺的兼容。如存在不兼容之處，須要考慮以前的規避措施或作必要的調整。
3）停機時間
也就是業務遷移時間窗，這也經常是客戶最關心的話題，不少狀況下客戶都是要求在線遷移。隨着數據量日益擴大和業務的逐漸複雜，每次遷移中止和啓動業務都須要消耗數小時時間，因此每一次數據遷移都是一場與時間賽跑的遊戲，要求操做過程的全程可控。不只要對正常流程的可控，還要作到在異常狀況下的可控，保證即便出現各類異常，還可以正常時間內完成遷移或者回退。這裏也要與客戶充分的溝通，若是能使用離線遷移方式，仍是建議使用離線方式，畢竟這種方式的風險要小不少。
4）數據校驗
在整個的數據遷移過程當中，採用的遷移方式多種多樣。因爲誤操做或者遷移方案缺陷極有可能致使數據庫數據的不一致。在遷移的過程當中，應該制定嚴格的數據驗證過程。在遷移先後，要有充分的準備。避免因爲誤操做致使數據庫的數據庫準確性問題。建議客戶採用並行混跑方式，有較長的時間窗口能夠充分驗證新環境的數據準確性，避免出現發現異常而沒法回退的狀況。
5）性能保證
性能保證，也是客戶比較關心的一個問題。可否對遷移後環境性能變現有個準確的預期，對客戶來講尤其重要；但要作到準確的評估是比較困難的。通常建議在正式遷移以前，進行預遷移在全量數據環境下的模擬壓力測試，驗證性能表現。
2、遷移過程：事前篇
一、方案調研
在遷移以前，最爲重要的就是肯定遷移方案。針對數據遷移，能夠有不少類遷移方式，包括數據庫、存儲、虛擬機、卷、主機、網絡、應用等等。這裏須要根據咱們的要求，圈定採用哪類遷移方式；而後是明確具體的遷移方案，若是涉及到外部商用方案，還須要進行必要的POC測試；再次就是細化方案，肯定具體遷移步驟（含遷移、回退、驗證）等。下面描述下常見的這幾類遷移方案。
1）數據庫方案
若是是同種數據庫，能夠採用備份、還原方式；異構的話，能夠採用導入、導出方式。如今還有一種比較通用的方案，是消費源端的日誌，將其轉換成標準消息，而後對端消費應用。這種方式通用性較好，可實現同構、異構、跨平臺的遷移；增量部分，經過源端的日誌實時捕獲，也能夠實現。固然對於全量數據來講，仍是建議採起異步方式，集中處理，這樣效率比較高。
2）虛擬機方案
VMware、Hyper-V等虛擬化產品也都提供了在線替換遷移功能。虛擬機的在線遷移功能能夠實現無中斷的遷移，可是並非全部場景均可以使用這種方案進行遷移。所以虛擬機遷移須要首先覈對是否場景限制上可以知足。
3）操做系統方案
對於文件系統場景，因爲各個廠商的元數據結構不同，通常都須要經過文件遷移工具從文件層進行拷貝和複製，保留文件的屬性和權限，而不能從底層塊數據層進行遷移。因此文件系統相對簡單，常見的諸如Linux下Rsync工具，就是一個遠程數據同步工具，可經過 LAN或WAN 快速同步多臺主機間的文件。
4）卷方案
在大多數操做系統上都提供卷管理軟件，將SAN裸設備進行行聚合或者拆分後提供給上層應用使用，所以絕大多數應用數據都經過卷管理軟件進行管理，因此卷管理軟件自帶的鏡像和遷移功能經常成爲在線數據遷移方案的一種選擇。常見的如Linux下的LVM、Oracle自帶的ASM等，經過這些不一樣的卷管理軟件實現數據在線遷移到新的目標存儲。
5）網絡方案
虛擬化網關產品經過自帶的存儲虛擬化功能能夠實現遷移功能。好比筆者以前使用過的EMC Vplex系列等。這種方式首先是經過虛擬化網產品將源存儲接管，讓源存儲和業務主機之間的全部數據都經過網關產品進行傳遞，再經過網關產品將數據完整的從塊級別鏡像複製到目標新存儲。
這種方案具備很強的普適性，能夠在大部分的場景下使用。可是因爲鏡像複製只是實現了數據複製到目標新存儲，而原來的業務主機上的多路徑，卷管理，集羣和數據庫等軟件都是和源存儲進行綁定的，所以在數據同步到目標存儲的後，還須要將業務和源存儲的綁定關係替換爲目標存儲，這個過程是整個數據遷移過程當中最複雜的部分。
6）存儲方案
存儲設備自己也具有一些數據遷移功能，如LUN拷貝和遠程複製。LUN拷貝能夠把目標新存儲做爲一個服務器，首先將源存儲映射到目標新存儲，再將目標新存儲上的全部數據讀出來寫到目標存儲上。遠程複製能夠從數據塊層面將數據從一臺存儲同步到遠端的另外一套存儲，但通常要求源存儲和目標存儲都是來自一家的同平臺產品。此功能常常被用於存儲的跨地域數據遷移。
7）應用方案
應用方案，能夠說是萬能的方案，客戶可根據自身狀況定製遷移方案。其每每是最靈活的，固然也是複雜度相對較高的一種。經常使用的方法開發一個全量的遷移工具，進行數據遷移；增量部分，採用讀取源端日誌的方式補齊；此外配合必要的數據對比工具完成。在新舊系統數據基本同步後，斷掉舊系統，切換到新系統。這種方式能夠實現比較平滑的遷移，全程可控；但問題在於若是出現問題，還需考慮回退流程，最好能實現雙向同步，但這種複雜度有增大很多。
還有一種就是所謂的「雙寫法」，先利用數據同步工具完成初始的數據同步，對於增量部分採用應用雙寫的方式完成，這裏只要保證必要的數據冪等性便可。在切換流程上，一般採用六個階段。
-
第一階段，上線雙寫，即同時寫入新舊兩種系統數據；
-
第二階段，歷史數據離線搬遷，即離線將歷史存量數據從舊系統搬到新系統；
-
第三階段，切讀，即將讀請求部分或所有路由到新系統；
-
第四階段，切寫，即將寫請求部分或所有路由到新系統；
-
第五階段，所有切換至新系統，即讀寫請求都走新系統，此時雙寫並無中止，依然保證新舊兩邊的數據徹底一致，目前是爲了保證異常時可直接回切。視測試狀況，這個階段可保持較長時間，充分驗證新系統的數據準確性、性能表現等。
-
第六階段，停寫，即將舊系統的寫入中止，清理回收舊系統資源，所有流程結束。
二、方案測試
在明確了遷移方案後，需進行完備的方案測試；如涉及到自研部分，需儘早啓動開發工做。如要採購外部產品，也須要在此階段進行測試。這個階段的測試，主要目的是驗證方案可行性，特別是數據安全方面。對可能出現的風險，要充分評估，並將其歸入到後續方案細節中。
此外，也須要在此階段收集必要的性能數據，爲後續評估新系統配置、停機窗口等，作必要的準備。若有多種方案都可行，也能夠在測試階段具體比較其差別，找出最爲適合的一種。
3、遷移過程：事中篇
在總體遷移過程當中，通常遵循從規劃階段->準備階段->遷移階段->驗證階段->投產階段的順序。當在驗證階段出現問題時，可能須要回溯到規劃階段進行調整甚至放棄此方案；但投產階段出現問題是，須要退回到驗證階段從新評測優化。（下面的遷移方案中，按照最爲常見的數據庫遷移方案進行說明）。
一、規劃階段
1）整體規劃
整個遷移過程會涉及數據庫廠商、應用開發商、客戶等多個部門和組織的配合，爲了保證遷移項目的成功，每個環節都要仔細分析並充分驗證。整體規劃尤其重要，建議成立虛擬的指揮中心協調各方資源推動。
2）資源規劃
資源部分，主要是指遷移設計的硬件部分。包括硬件規劃、選型、評測、採購等。如涉及多種設備（主機、存儲、網絡等），還須要考慮之間的兼容適配問題。此外，與現有平臺的兼容能力也需考慮。若是涉及到國產化問題，還須要考慮上層軟件的適配問題。
3）遷移規劃
制定詳細周密的遷移計劃，包括整個後面「準備+遷移+驗證+投產」的全流程。細節要詳細到每一操做步驟，甚至要求所有腳本化，不能臨時敲命令處理。全部步驟的預期結果，須要明示。在出現以前未評估結果時，需啓動應急流程處理。此外，必定不要忽視回退計劃。
4）測試規劃
在遷移中的每一階段，都要制定測試計劃，作到步步可驗證。這裏的測試可從系統級、數據級、應用級、業務級多方面去考察，保證最後結果的正確性。
5）驗收規劃
在系統投產以後，須要有個標誌性的環節，就是「驗收」。這表明着本次遷移工做是否成功，能否將業務正式切換過來。通常建議，在系統上線投產後，一段時間以後再考慮。但須要在以前制定一個標準。
二、準備階段
1）硬件環境
各類硬件的上架、聯調，系統安裝、部署等。
2）角色受權
在遷移以前開通必要的安全通路，開啓可訪問線上通路。
3）業務準備
業務端作好必要的準備，例如掛公告等，爲正式遷移作好準備。
三、遷移階段
1）權限遷移
這裏包括用戶、角色、權限遷移。須要考慮的是，原有這部分是否作調整，是否拆分、整合，是否作隔離。切記避免出現，可訪問舊系統的狀況，形成數據污染，乃至沒法回退的狀況。
2）對象遷移
也叫元數據遷移。這部分涉及內容不少，也是最爲複雜的部分。常見包括如下一些方面：
①字段類型
若是是異構系統遷移，須要創建新舊系統的字段映射關係。對於沒法直接映射的部分，要考慮如何轉化實現。特別須要注意的是精度問題，不一樣數據庫產品的相同類型字段，其精度有可能有差別。此外，還有諸如符號位等問題。能夠提早作一個映射表，既方便查看，也方便研發人員對照。這部分也可利用一些工具輔助完成。
②約束字段
做爲常見的五大類約束（PK、FK、UK、NULL、CHECK），是否在新平臺所有原樣支持。此外有些平臺原生就不徹底支持，此時要考慮好解決對策。此外，若是應用使用了業務主鍵，也要考慮遷移後是否有影響。
③特殊字段
在源或目標端，有一些特殊字段須要在對象遷移階段給予關注。例如自增類型、分佈鍵、分區鍵等。這些須要特殊考慮，每每須要人工指定。
④字符集問題
爲避免出現導入後亂碼等問題，須要在這個階段就考慮。特別是若是目標端的字符集只能作到源端的子集的話，尤爲須要注意。
⑤其餘類型
其餘諸如臨時表、虛擬列、序列、視圖、存儲過程、函數、觸發器，索引等。這些在源端與目標端每每在實現上存在較大差別，主要注意甄別並解決。這也是對象遷移階段，工做量最大的部分。如部分確實沒法對應，可考慮在應用端實現相似的邏輯。
3）數據遷移
數據遷移包括全量和增量數據遷移。具體方法可參照以前說明。這裏重點談下遷移以後的數據校驗問題，在完成新數據平臺的搭建後，通常會和原有的數據平臺並行運行一段時間，一方面是爲了和原有平臺進行業務和數據的比對，確保業務的正確性和連續性；另外一方面，應用改造遷移是一個按部就班的過程，在全部應用遷移完成前，原有數據平臺仍是要承擔正常的業務訪問。通常的作法是經過相似灰度發佈的過程，開始的時候同時往兩個平臺寫入數據，但只有原有數據平臺對外提供業務訪問，天天經過數據校驗做業，比較兩個平臺的數據一致性。
通過一段時間，確認數據沒有問題後，再把對外訪問的流量切換到新的數據平臺，再通過一段時間撤除原有平臺上的做業。對比方案可有多種：比較簡單的如對比數據量，即分別統計出數據表的條數，而後進行比對。若是條數匹配，就認爲兩邊數據是一致的。這種方法的優勢是效率很高，缺點是不能徹底保證數據的一致性。也能夠採起對比數據條數加上關鍵字段校驗，但須要提早定義出關鍵字段。也能夠採起對全表作md5的方式，但這種方式只適合離線方式，且效率不高。
4）應用遷移
在完成上述過程後，可作應用遷移。若是是採起以前的混合新舊系統的方式，這個過程仍是比較複雜的。建議使用內部的DevOps平臺或自研小工具完成，方即可隨時查看對比及回退。
四、驗證階段
1）業務測試
遷移完成後，首選須要進行的業務測試，即功能性驗證。可採起全量回歸的方式，儘可能作到覆蓋所有。重點關注異常，並定位是不是有遷移數據異常致使。
2）性能測試
基於以前指定的性能指標，對遷移後的環境進行性能測試。這裏最好是能有一組基線數據方便對比，可在預遷移的環境準備基線。這樣新環境的種種性能指標，是能夠很容易評估是否有異常。
3）問題修復
遷移過程後，不免出現問題，須要在此階段快速修復。
4）性能優化
對於不知足性能要求的，可在線作性能優化。
5）培訓輔導
所有完成後，對客戶人員進行必要的培訓輔導。
五、投產階段
1）系統割接
當完成所有數據遷移並經過測試後，可正式作系統割接。系統割接並不表明遷移徹底成功，仍是建議業務並行混跑，或舊系統仍然保持全量實時數據，隨時可切換回去。這個過程是一個標誌，標誌從遷移階段過渡到後期維護階段。
2）運維保障
進入運維保障階段，仍是建議全體人員在崗，特別是在頭兩個業務高峯期。要密切觀察新系統的穩定性、性能等，並作好必要的記錄，方便後期作遷移總結及正式運維交接。
3）後期維護
在穩定運行一段時間後，會轉爲後期維護階段。可按期對新系統作健康巡檢，觀察是否符合以前的預期。
4、遷移過程：過後篇
遷移最後，須要針對這次遷移作個歸納性的盤點。針對新系統的表現，與以前的預期進行對比評估。對仍然存在的遺留問題，須要重點關注。