前言
最近寫了很多資料庫相關的文章，大家基本上對資料庫也有了很多的瞭解，資料庫本身有所瞭解了，我們是不是應該回歸業務本身呢？
大家去了解過自己企業資料庫的部署方式麼？是怎麼部署的，又是部署在哪裡的？部署過程中可能會出現的問題有哪些？
是主從？還是雙主？有沒有分庫？大的表做了分表沒？等等...部署方式大概率也都是分庫的，表數量級超千萬基本上都開始分表了，考慮周全的企業，肯定也有資料庫的冷備，熱備，災備，以及異地容災等等。
我還記得我大學做專案，學校就是買了很多物理機，我們的專案和資料庫都是部署在自己內部的伺服器上的，那傢伙一到夏天風我嗡嗡嗡的吹，煩死了，機房還很熱。
但是我敢打賭，大家現在所在的企業，大概率都是使用了各種雲服務廠商的服務部署方式，那就引入了今天的第一個思考。
為什麼資料庫要上雲呢？
我們公司的大多數服務以及資料庫都是在對應的雲服務廠商的，那問題就來了，為啥都要上雲呢？
在思考這個問題的時候，我第一時間想到了反證法，不上雲的壞處是啥？
成本
相較於傳統伺服器需要購買、租用的方式，雲伺服器採用即用即收費的方式，減少購買成本，靈活擴充套件的容量可以按自己需求來定，不用前期估量需要用多少。
我之前所在的電商活動團隊，每次到了大促我們就去租賃雲服務廠商的流量機，等活動結束就還回去，真的就是成本最大化了，而且還是根據你的使用流量計費。
如果大家還是使用自己購買的伺服器，那這個時候難道去臨時採購麼？雖然我知道百度就是在某年春節活動的時候採購了N多物理機，但是性質不一樣，他們是能最大化利用這些伺服器的，他們甚至可以開發雲服務自己做雲服務廠商，實際上他們確實也這麼做了。
效能
雲伺服器實現了硬體上的隔離以及寬頻上的獨享，不受到地域、流量等的限制，可以持續的進行業務交流，不會因中斷影響效果。
如果大家還是使用物理機，那去運營商遷專線的頻寬成本，還有物理機效能的問題也不一定能更上。
由於現在成本問題，你們公司買了很多低配的伺服器，但是突然你們業務體量幾何增長，怎麼辦？繼續買高配的？顯然不是很合適。這誰頂得住啊？
管理
雲伺服器可以實現遠端同步管理，共享，各種業務的備份。傳統伺服器需要在某一網路區域內，有可能受到網路影響導致資料缺失。
上面我提到的冷備，熱備，災備其實我們購買的伺服器都能做的，但是放著一個不知道什麼時候才能用到的伺服器在那，真的很浪費。
而且也有他做不到的，比如災備，如果你公司在震區，要是還用物理伺服器，基本上等於自殺，傳送自然災害的時候全球的使用者都無法訪問你，交給服務廠商就不一樣了，他們選址很有講究的，並且在各個地方都建立自己的資料中心，保證了高可用。
安全
為了保證雲平臺的可靠性，雲服務平臺公司肯定會投入大量的功夫，有一套可靠的安全保障系統，平臺使用者不必擔心平臺穩定性、安全性問題。
物理機一旦高許可權的所有者使壞，基本上都是不可恢復的災難，雖然雲服務也一樣，但是合理使用，和適當的許可權收斂，完全可以做到更高階別的安全的。
微盟事件大家也知道，如果提前做好各種全量，增量備份其實就沒什麼大問題的，再者就是許可權收斂問題，我司在對應的資料庫伺服器上是禁用了rm -rf 、fdisk以及drop這樣的極端操作的。
所有資料庫的查詢更是自己的元件查詢，連update都無法操作（只能靠程式碼）。
如果還是使用物理機，就需要自己去維護，升級打補丁，很難保證不被黑客入侵，之前我就遇到過伺服器補丁打遲了，導致被黑客攻擊，劫持拿去挖礦了，而云服務廠商的安全系統都是實時更新的。
小結：沒有特殊情況，能用雲產品就直接用雲產品，因為雲產品提供的不僅僅是產品能力，最關鍵的是關鍵時刻的容災、應急和服務能力，這些能力，並不是所有公司都能完整建設一套，甚至是很多公司想都想不到的。
到目前為止，雖然各大雲廠商包括他們的產品，都還有這樣那樣的問題，但是從體系上，雲仍然是最完善，最規範的，直接一點講，比99%的公司做的都要好。
上雲需要考慮的問題
這裡很有意思，我在寫這個文章的時候，我司正在做部分業務上雲，以及雲遷移這樣的業務，這讓我聯想到了很多有意思的事情。
我們現在是從某雲遷移到華為雲，我想大家也會與這樣的場景，但是這樣遷移會帶來一些什麼樣的問題呢？不知道大家思考過沒？
其實從本地到雲，或者從雲到雲，要思考的點估計是差多的，那我先丟擲一些問題，看下這些問題華為雲服務廠商是怎麼解決的。
遷移失敗：資料遷移失敗怎麼辦 資料丟失：怎麼判斷遷移後資料是否完整 業務中斷：遷移到一半遇到不可抗力怎麼辦 資料、傳輸加密：資料傳輸過程中怎麼加密，防止被不法之徒中途獲取資料 熱切換：怎麼做到不停服切換，以及資料來源切換過程中的資料一致性
這些問題是我們不得不考慮的，大家是不是以為遷移多簡單，那我想問一下，假如是訂單庫呢？大一點的電商每一秒，甚至是每一毫秒都是有訂單的，哪怕是凌晨，別問我為什麼知道咳咳。
那你肯定不能停服去遷移資料庫，你需要一邊遷移一邊接受新的資料，這個時候就需要一些技巧了，不知道redis字典的rehash大家知道麼？
rehash
在需要擴容的時候，redis會新建一個hash字典，這個時候老的停止接收資料，新資料放到新的字典，同時慢慢把老資料拿過來，其實這個思想，在資料庫遷移也是可以用的，但是資料庫的操作，往往都是基於資料的，並不是都是增量。
那簡單，做點取巧的操作也可以，那雲廠商的已經把我上面提到的所有問題都肯定考慮過了，我接觸的是華為雲，華為雲使用了DRS（Data Replication Service 資料複製服務）做資料庫遷移的事情，他怎麼做的呢？
DRS：資料複製服務(Data Replication Service，簡稱為 DRS)是一種易用、穩定、高效，用於資料庫線上遷移和資料庫實時同步的雲服務。 DRS 圍繞雲資料庫，降低了資料庫之間資料流通的複雜性，有效地幫助您減少資料傳輸的成本。
大家可能會好奇，為啥不自己去實現資料遷移，要用別人的元件呢？其實車輪子這個，如果你沒更好的思路你還是用別人寫好的就好了，你能比得過專業團隊的研發結果嘛？
不過技術背後的實現，解決的問題還是需要我們去關心的，不然DRS什麼都幫我們做了，我們動動滑鼠就解決了，你怎麼得到收穫呢？這才是今天探討的重點。
我說一下用車輪的好處吧：降低成本，降低技術門檻、降低風險
人力成本時間成本，都是很昂貴的，如果一個現成的東西都幫我們做了，我們還去開發幹嘛？再者，我相信大部分公司還是沒專門的DBA的，但是車輪子在了，我們開發也能去做遷移這樣的事情了，不是嘛？我們傳統技術遷庫耗時耗力不說了，失敗率是真的高，還有資料對比等等，很頭疼，我之前東家資料庫遷移都是半夜，搞一晚上，天亮都不一定搞好了，要是沒好，使用者上線了，還的暫停。
不過即使是使用了工具，一個資料庫完整的遷移流程卻還是應該很嚴謹的，大家可能會疑惑再嚴謹能有多嚴謹？給你看個圖你就知道了：
華為雲的DRS的線上遷移怎麼做的呢？
可以看到，遷移圖中是使用到了VPN，這個的作用主要就是保住一個高速穩定的傳輸，以及傳輸資料的加密，萬一你同步的過程被其他對手公司抓到，那？在文章後面，你可以看到華為雲DRS是怎麼做的網路安全，我做了一次完整的遷移實戰，並且做了總結。
遷移實戰
他遷移很簡單，都有教程，我用過一遍，大致步驟如下：
遷移作為一個特殊時期，業務配合、人為配合是最關鍵的，部分操作一定要規避，比如說常見的：
不能將源資料庫日誌強制清理掉 不能將用於連線源資料庫的使用者密碼修改掉、或者刪除掉 不能將表長時間鎖定，導致外部都無法查詢該表
他在遷移之前可以做一個遷移預檢查，從官方文件來看，都是對過往遷移案例總結出來的檢查步驟，可以讓遷移成功有更好的保障，這點挺好可以在遷移前夕找出問題所在，我也失敗過，是因為環境問題，都給了很明確的指示。
大家不知道思考過沒，就是資料遷移了，但是如果資料庫的設定沒遷移那也是很麻煩的，如果一個遷移工具能夠做到把DBA設定的好的User許可權遷移了，以及我們設定的各種觸發器，資料庫字符集設定都遷移了，那才是我理想的一個遷移工具，是的華為雲DRS做了，這就是比較優秀的點了，真的省了很多功夫。
特別是對於資料庫各種設定並沒那麼瞭解的開發來說，這功能確實是很福利了，而且還有效能引數，類似各種buffer大小，cache大小等等他都能遷移，甚至可以做到流控，還可以隨時改變流控就更優秀了：
遷移模式多樣化，這是我準備開始遷移的第一感受，我上面提到過，如果不能增量遷移將毫無意義，DRS還是想到了，這讓我覺得好像有點暖，說著說著我的眼角又溼潤了...
因為大部分的場景我們都是線上業務的不停服遷移，在遷移過程中，還是不斷的有增量資料在湧入的，敖丙之前所經歷過的資料庫遷移基本上也都是全量+增量的遷移模式，全量的場景只存在內部系統，或者離線資料等。
其實這裡的技術核心就在於怎麼去保證增量的資料也能保證不丟失正確的遷移，我猜是通過binlog同步的，我看了下他的文件，日誌，果然被我猜對了。
DRS是通過全量遷移過程完成歷史資料遷移至目標資料庫後，增量遷移階段通過捕抓日誌，應用日誌等技術，將源端和目標端資料庫保持資料一致，這裡的保持一致後面也會提到，他提供了完整的資料對比功能。
遷移過程很簡單，進度完全可以看到，資料的延遲也可以很直觀的看到：
遷移結束之後，DRS提供了資料對比，其實資料對比以前我做遷移的時候，我們都是通過對比資料庫行數去做的，因為沒這樣的遷移工具，我發現了很暖心的一點就是內容對比，這一點讓我很驚喜，因為行數的對比還是不夠嚴謹，修改的日誌如果缺失行數的對比也是沒用的。
等待對比完成，點選“檢視對比報表”，可以瞭解對比詳情，詳情頁面如圖所示：
上面提到的網路安全問題，我也在DRS找到了答案，他們會使用特定的加密協議進行資料傳輸，還可以用特定的VPN掛載網路傳輸：
DRS還做了遷移監控，可以看到實時進度，讓整個遷移進度比較視覺化，中間的異常也一目瞭然，說實話工具真的就是香，以前想都不敢想，我們熬夜就生怕一個環節出錯，而且經常還是後知後覺的，視覺化的流程會你對遷移有一種掌控感。
遷移完成：
從我開始遷移到結束，整個流程其實不到2小時，這個放在以前是不敢想的，這波體驗我是很滿意的，讓我一個開發就做到了以前DBA才能做的事情，說著說了旁邊的DBA的眼角也溼潤了....
小結
整個體驗我覺得是很不錯的，我總結幾個我覺得DRS獨特的設計和使用場景：
遷移限速，根據限定時間段設定遷移速度上限
應用場景:
有些流量型app，比如遊戲廠商等客戶， 遷移時源資料庫的公網、VPN不能打滿（打滿將影響其對外業務，或者影響共用VPN 頻寬）
有些業務負載較重，或著客戶無法接受 業務時間應用程式因為遷移帶來額外負載
使用者遷移(許可權、密碼、 definer)，完整繼承源許可權體系
應用場景:
市面上的遷移產品均不支援使用者的遷移， 也就是說如果使用者沒有注意，或者不懂使用者遷移，那麼遷移後業務必然報錯， DRS提供了全套的使用者許可權繼承設計， 可以將許可權、密碼、definer保留遷移至目標資料庫，確保遷移後許可權安全、業務穩定，可以讓不熟悉資料庫的客戶遷移時，仍然可以完成一場精細的、高質量的資料庫遷移。
引數對比，遷移後業務穩定
應用場景:
市面上的遷移產品均不支援引數的遷移，而資料庫引數不一樣，這將直接導致業務程式 執行報錯(舉個簡單例子session數遷移後變小了)，DRS選定了業務和效能強相關關鍵的引數，避免了這些引數後續因為沒有繼承源環境設定，而導致業務報錯或效能下降， 可以讓不熟悉資料庫的客戶遷移時，仍然可以完成一場精細的、高質量的資料庫遷移。
資料校對平臺，割接好幫手
應用場景:
市面上的遷移產品均不支援資料的對比，校對工作留給使用者測，DRS提供了豐富的對比功能:
物件對比
資料級對比
對比可定時，可取消
利用對比定時任務，可以選擇凌晨等業務低峰期 進行資料一致性對比，第二天可以檢視資料對比結果，對於遷移情況做到完全掌握。 可以讓不熟悉資料庫的客戶遷移時，仍然可以完成一場精細的、高質量的資料庫遷移。
觸發器、事件的遷移
應用場景:
市面上的遷移產品均不支援觸發器、事件的遷移，精通遷移的使用者關注這些細節，因 為觸發器和事件也是資料庫的一部分，觸發器和事件存在關鍵的業務邏輯，這些物件 不支援遷移，業務必然報錯，甚至造成不可挽回的損失。 可以讓不熟悉資料庫的客戶遷移時，仍然可以完成一場精細的、高質量的資料庫遷移。
注：【部分圖片來源網路 侵刪】
總結
其實給大家介紹這樣DRS的一個背景和技術，主要是希望跟大家跟我一起做一次完整資料遷移，一起去探討技術背後的場景，以及場景背後我們應該有技術思考。
不過這次體驗真的，讓我不得不感慨技術的便捷性，以前資料庫遷移都是團隊開發以及測試一個團隊熬夜守著資料庫遷移，最後驗證測試才能走的，所有人拖著疲憊的身軀看著升起的太陽，眼角都溼了...
現在我自己看看教程動動手指就完成了一場大規模的資料庫遷移演練，在享受技術給我帶來方便的同時，也讓我對技術背後的具體實現和人生的意義陷入了深深的思考。
或許這就是技術的價值吧，或許這就是這麼多工程師日日夜夜辛苦的意義吧，或許...
我是敖丙，你知道的越多，你不知道的越多，我們下期見！