面試官：你經歷過數據庫遷移麼？有哪些注意點和難點？

前言

最近寫了不少數據庫相關的文章，你們基本上對數據庫也有了不少的瞭解，數據庫自己有所瞭解了，咱們是否是應該回歸業務自己呢？

你們去了解過本身企業數據庫的部署方式麼？是怎麼部署的，又是部署在哪裏的？部署過程當中可能會出現的問題有哪些？

是主從？仍是雙主？有沒有分庫？大的表作了分表沒？等等...部署方式大機率也都是分庫的，表數量級超千萬基本上都開始分表了，考慮周全的企業，確定也有數據庫的冷備，熱備，災備，以及異地容災等等。

我還記得我大學作項目，學校就是買了不少物理機，咱們的項目和數據庫都是部署在本身內部的服務器上的，那傢伙一到夏天風我嗡嗡嗡的吹，煩死了，機房還很熱。

可是我敢打賭，你們如今所在的企業，大機率都是使用了各類雲服務廠商的服務部署方式，那就引入了今天的第一個思考。

爲何數據庫要上雲呢？

咱們公司的大多數服務以及數據庫都是在對應的雲服務廠商的，那問題就來了，爲啥都要上雲呢？

在思考這個問題的時候，我第一時間想到了反證法，不上雲的壞處是啥？

1. 成本

相較於傳統服務器須要購買、租用的方式，雲服務器採用即用即收費的方式，減小購買成本，靈活擴展的容量能夠按本身需求來定，不用前期估量須要用多少。

我以前所在的電商活動團隊，每次到了大促咱們就去租賃雲服務廠商的流量機，等活動結束就還回去，真的就是成本最大化了，並且仍是根據你的使用流量計費。

若是你們仍是使用本身購買的服務器，那這個時候難道去臨時採購麼？雖然我知道百度就是在某年春節活動的時候採購了N多物理機，可是性質不同，他們是能最大化利用這些服務器的，他們甚至能夠開發雲服務本身作雲服務廠商，實際上他們確實也這麼作了。

2. 性能

雲服務器實現了硬件上的隔離以及寬帶上的獨享，不受到地域、流量等的限制，能夠持續的進行業務交流，不會因中斷影響效果。

若是你們仍是使用物理機，那去運營商遷專線的帶寬成本，還有物理機性能的問題也不必定能更上。

因爲如今成本問題，大家公司買了不少低配的服務器，可是忽然大家業務體量幾何增加，怎麼辦？繼續買高配的？顯然不是很合適。這誰頂得住啊？

3. 管理

雲服務器能夠實現遠程同步管理，共享，各類業務的備份。傳統服務器須要在某一網絡區域內，有可能受到網絡影響致使資料缺失。

上面我提到的冷備，熱備，災備其實咱們購買的服務器都能作的，可是放着一個不知道何時才能用到的服務器在那，真的很浪費。

並且也有他作不到的，好比災備，若是你公司在震區，要是還用物理服務器，基本上等於自殺，發送天然災害的時候全球的用戶都沒法訪問你，交給服務廠商就不同了，他們選址頗有講究的，而且在各個地方都創建本身的數據中心，保證了高可用。

4. 安全

爲了保證雲平臺的可靠性，雲服務平臺公司確定會投入大量的功夫，有一套可靠的安全保障系統，平臺使用者沒必要擔憂平臺穩定性、安全性問題。

物理機一旦高權限的全部者使壞，基本上都是不可恢復的災難，雖然雲服務也同樣，可是合理使用，和適當的權限收斂，徹底能夠作到更高級別的安全的。

微盟事件你們也知道，若是提早作好各類全量，增量備份其實就沒什麼大問題的，再者就是權限收斂問題，我司在對應的數據庫服務器上是禁用了rm -rf 、fdisk以及drop這樣的極端操做的。

全部數據庫的查詢更是本身的組件查詢，連update都沒法操做（只能靠代碼）。

若是仍是使用物理機，就須要本身去維護，升級打補丁，很難保證不被黑客入侵，以前我就遇到過服務器補丁打遲了，致使被黑客攻擊，劫持拿去挖礦了，而云服務廠商的安全系統都是實時更新的。

小結：沒有特殊狀況，能用雲產品就直接用雲產品，由於雲產品提供的不只僅是產品能力，最關鍵的是關鍵時刻的容災、應急和服務能力，這些能力，並非全部公司都能完整建設一套，甚至是不少公司想都想不到的。

到目前爲止，雖然各大雲廠商包括他們的產品，都還有這樣那樣的問題，可是從體系上，雲仍然是最完善，最規範的，直接一點講，比99%的公司作的都要好。

上雲鬚要考慮的問題

這裏頗有意思，我在寫這個文章的時候，我司正在作部分業務上雲，以及雲遷移這樣的業務，這讓我聯想到了不少有意思的事情。

咱們如今是從某雲遷移到華爲雲，我想你們也會與這樣的場景，可是這樣遷移會帶來一些什麼樣的問題呢？不知道你們思考過沒？

其實從本地到雲，或者從雲到雲，要思考的點估計是差多的，那我先拋出一些問題，看下這些問題華爲雲服務廠商是怎麼解決的。

1. 遷移失敗：數據遷移失敗怎麼辦
2. 數據丟失：怎麼判斷遷移後數據是否完整
3. 業務中斷：遷移到一半遇到不可抗力怎麼辦
4. 數據、傳輸加密：數據傳輸過程當中怎麼加密，防止被不法之徒中途獲取數據
5. 熱切換：怎麼作到不停服切換，以及數據源切換過程當中的數據一致性

這些問題是咱們不得不考慮的，你們是否是覺得遷移多簡單，那我想問一下，假如是訂單庫呢？大一點的電商每一秒，甚至是每一毫秒都是有訂單的，哪怕是凌晨，別問我爲何知道咳咳。

那你確定不能停服去遷移數據庫，你須要一邊遷移一邊接受新的數據，這個時候就須要一些技巧了，不知道redis字典的rehash你們知道麼？

rehash

在須要擴容的時候，redis會新建一個hash字典，這個時候老的中止接收數據，新數據放到新的字典，同時慢慢把老數據拿過來，其實這個思想，在數據庫遷移也是能夠用的，可是數據庫的操做，每每都是基於數據的，並非都是增量。

那簡單，作點取巧的操做也能夠，那雲廠商的已經把我上面提到的全部問題都確定考慮過了，我接觸的是華爲雲，華爲雲使用了DRS（Data Replication Service 數據複製服務）作數據庫遷移的事情，他怎麼作的呢？

DRS：數據複製服務(Data Replication Service，簡稱爲 DRS)是一種易用、穩定、高效，用於數據庫在線遷移和數據庫實時同步的雲服務。 DRS 圍繞雲數據庫，下降了數據庫之間數據流通的複雜性，有效地幫助您減小數據傳輸的成本。

你們可能會好奇，爲啥不本身去實現數據遷移，要用別人的組件呢？其實車輪子這個，若是你沒更好的思路你仍是用別人寫好的就行了，你能比得過專業團隊的研發結果嘛？

不過技術背後的實現，解決的問題仍是須要咱們去關心的，否則DRS什麼都幫咱們作了，咱們動動鼠標就解決了，你怎麼獲得收穫呢？這纔是今天探討的重點。

我說一下用車輪的好處吧：下降成本，下降技術門檻、下降風險

• 人力成本時間成本，都是很昂貴的，若是一個現成的東西都幫咱們作了，咱們還去開發幹嗎？再者，我相信大部分公司仍是沒專門的DBA的，可是車輪子在了，咱們開發也能去作遷移這樣的事情了，不是嘛？咱們傳統技術遷庫耗時耗力不說了，失敗率是真的高，還有數據對比等等，很頭疼，我以前東家數據庫遷移都是半夜，搞一夜，天亮都不必定搞好了，要是沒好，用戶上線了，還的暫停。

不過即便是使用了工具，一個數據庫完整的遷移流程卻仍是應該很嚴謹的，你們可能會疑惑再嚴謹能有多嚴謹？給你看個圖你就知道了：

華爲雲的DRS的在線遷移怎麼作的呢？

能夠看到，遷移圖中是使用到了VP*，這個的做用主要就是保住一個高速穩定的傳輸，以及傳輸數據的加密，萬一你同步的過程被其餘對手公司抓到，那？在文章後面，你能夠看到華爲雲DRS是怎麼作的網絡安全，我作了一次完整的遷移實戰，而且作了總結。

遷移實戰

他遷移很簡單，都有教程，我用過一遍，大體步驟以下：

遷移做爲一個特殊時期，業務配合、人爲配合是最關鍵的，部分操做必定要規避，好比說常見的：

• 不能將源數據庫日誌強制清理掉
• 不能將用於鏈接源數據庫的用戶密碼修改掉、或者刪除掉
• 不能將表長時間鎖定，致使外部都沒法查詢該表

他在遷移以前能夠作一個遷移預檢查，從官方文檔來看，都是對過往遷移案例總結出來的檢查步驟，可讓遷移成功有更好的保障，這點挺好能夠在遷移前夕找出問題所在，我也失敗過，是由於環境問題，都給了很明確的指示。

你們不知道思考過沒，就是數據遷移了，可是若是數據庫的設置沒遷移那也是很麻煩的，若是一個遷移工具可以作到把DBA設置的好的User權限遷移了，以及咱們設置的各類觸發器，數據庫字符集設置都遷移了，那纔是我理想的一個遷移工具，是的華爲雲DRS作了，這就是比較優秀的點了，真的省了不少功夫。

特別是對於數據庫各類設置並沒那麼瞭解的開發來講，這功能確實是很福利了，並且還有性能參數，相似各類buffer大小，cache大小等等他都能遷移，甚至能夠作到流控，還能夠隨時改變流控就更優秀了：

遷移模式多樣化，這是我準備開始遷移的第一感覺，我上面提到過，若是不能增量遷移將毫無心義，DRS仍是想到了，這讓我以爲好像有點暖，說着說着個人眼角又溼潤了...

由於大部分的場景咱們都是線上業務的不停服遷移，在遷移過程當中，仍是不斷的有增量數據在涌入的，敖丙以前所經歷過的數據庫遷移基本上也都是全量+增量的遷移模式，全量的場景只存在內部系統，或者離線數據等。

其實這裏的技術核心就在於怎麼去保證增量的數據也能保證不丟失正確的遷移，我猜是經過binlog同步的，我看了下他的文檔，日誌，果真被我猜對了。

DRS是經過全量遷移過程完成歷史數據遷移至目標數據庫後，增量遷移階段經過捕抓日誌，應用日誌等技術，將源端和目標端數據庫保持數據一致，這裏的保持一致後面也會提到，他提供了完整的數據對比功能。

遷移過程很簡單，進度徹底能夠看到，數據的延遲也能夠很直觀的看到：

遷移結束以後，DRS提供了數據對比，其實數據對比之前我作遷移的時候，咱們都是經過對比數據庫行數去作的，由於沒這樣的遷移工具，我發現了很暖心的一點就是內容對比，這一點讓我很驚喜，由於行數的對比仍是不夠嚴謹，修改的日誌若是缺失行數的對比也是沒用的。

等待對比完成，點擊「查看對比報表」，能夠了解對比詳情，詳情頁面如圖所示：

上面提到的網絡安全問題，我也在DRS找到了答案，他們會使用特定的加密協議進行數據傳輸，還能夠用特定的VP*掛載網絡傳輸：

DRS還作了遷移監控，能夠看到實時進度，讓整個遷移進度比較可視化，中間的異常也一目瞭然，說實話工具真的就是香，之前想都不敢想，咱們熬夜就生怕一個環節出錯，並且常常仍是後知後覺的，可視化的流程會你對遷移有一種掌控感。

遷移完成：

從我開始遷移到結束，整個流程其實不到2小時，這個放在之前是不敢想的，這波體驗我是很滿意的，讓我一個開發就作到了之前DBA才能作的事情，說着說了旁邊的DBA的眼角也溼潤了....

小結

整個體驗我以爲是很不錯的，我總結幾個我以爲DRS獨特的設計和使用場景：

1. 遷移限速，根據限定時間段設置遷移速度上限

應用場景:

• 有些流量型app，好比遊戲廠商等客戶， 遷移時源數據庫的公網、VP不能打滿（打滿將影響其對外業務，或者影響共用VP 帶寬）

• 有些業務負載較重，或着客戶沒法接受 業務時間應用程序由於遷移帶來額外負載

2. 用戶遷移(權限、密碼、 definer)，完整繼承源權限體系

應用場景:

• 市面上的遷移產品均不支持用戶的遷移， 也就是說若是用戶沒有注意，或者不懂用戶遷移，那麼遷移後業務必然報錯， DRS提供了全套的用戶權限繼承設計， 能夠將權限、密碼、definer保留遷移至目標數據庫，確保遷移後權限安全、業務穩定，可讓不熟悉數據庫的客戶遷移時，仍然能夠完成一場精細的、高質量的數據庫遷移。

3. 參數對比，遷移後業務穩定

應用場景:

• 市面上的遷移產品均不支持參數的遷移，而數據庫參數不同，這將直接致使業務程序 運行報錯(舉個簡單例子session數遷移後變小了)，DRS選定了業務和性能強相關關鍵的參數，避免了這些參數後續由於沒有繼承源環境設置，而致使業務報錯或性能降低， 可讓不熟悉數據庫的客戶遷移時，仍然能夠完成一場精細的、高質量的數據庫遷移。

4. 數據校對平臺，割接好幫手

應用場景:

• 市面上的遷移產品均不支持數據的對比，校對工做留給用戶測，DRS提供了豐富的對比功能:

• 對象對比

• 數據級對比

• 對比可定時，可取消

  利用對比定時任務，能夠選擇凌晨等業務低峯期 進行數據一致性對比，次日能夠查看數據對比結果，對於遷移狀況作到徹底掌握。 可讓不熟悉數據庫的客戶遷移時，仍然能夠完成一場精細的、高質量的數據庫遷移。

5. 觸發器、事件的遷移

應用場景:

• 市面上的遷移產品均不支持觸發器、事件的遷移，精通遷移的用戶關注這些細節，因 爲觸發器和事件也是數據庫的一部分，觸發器和事件存在關鍵的業務邏輯，這些對象 不支持遷移，業務必然報錯，甚至形成不可挽回的損失。
• 可讓不熟悉數據庫的客戶遷移時，仍然能夠完成一場精細的、高質量的數據庫遷移。

注：【部分圖片來源網絡 侵刪】

總結

其實給你們介紹這樣DRS的一個背景和技術，主要是但願跟你們跟我一塊兒作一次完整數據遷移，一塊兒去探討技術背後的場景，以及場景背後咱們應該有技術思考。

不過此次體驗真的，讓我不得不感慨技術的便捷性，之前數據庫遷移都是團隊開發以及測試一個團隊熬夜守着數據庫遷移，最後驗證測試才能走的，全部人拖着疲憊的身軀看着升起的太陽，眼角都溼了...

如今我本身看看教程動動手指就完成了一場大規模的數據庫遷移演練，在享受技術給我帶來方便的同時，也讓我對技術背後的具體實現和人生的意義陷入了深深的思考。

或許這就是技術的價值吧，或許這就是這麼多工程師日日夜夜辛苦的意義吧，或許...

我是敖丙，你知道的越多，你不知道的越多，咱們下期見！