前言
最近寫了很多資料庫相關的文章，大家基本上對資料庫也有了很多的了解，資料庫本身有所了解了，我們是不是應該回歸業務本身呢？
大家去了解過自己企業資料庫的部署方式么？是怎么部署的，又是部署在哪里的？部署程序中可能會出現的問題有哪些？
是主從？還是雙主？有沒有分庫？大的表做了分表沒？等等...部署方式大概率也都是分庫的，表數量級超千萬基本上都開始分表了，考慮周全的企業，肯定也有資料庫的冷備，熱備，災備，以及異地容災等等，
我還記得我大學做專案，學校就是買了很多物理機，我們的專案和資料庫都是部署在自己內部的服務器上的，那家伙一到夏天風我嗡嗡嗡的吹，煩死了，機房還很熱，
但是我敢打賭，大家現在所在的企業，大概率都是使用了各種云服務廠商的服務部署方式，那就引入了今天的第一個思考，
為什么資料庫要上云呢？
我們公司的大多數服務以及資料庫都是在對應的云服務廠商的，那問題就來了，為啥都要上云呢？
在思考這個問題的時候，我第一時間想到了反證法，不上云的壞處是啥？
成本
相較于傳統服務器需要購買、租用的方式，云服務器采用即用即收費的方式，減少購買成本，靈活擴展的容量可以按自己需求來定，不用前期估量需要用多少，
我之前所在的電商活動團隊，每次到了大促我們就去租賃云服務廠商的流量機，等活動結束就還回去，真的就是成本最大化了，而且還是根據你的使用流量計費，
如果大家還是使用自己購買的服務器，那這個時候難道去臨時采購么？雖然我知道百度就是在某年春節活動的時候采購了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的一個背景和技術，主要是希望跟大家跟我一起做一次完整資料遷移，一起去探討技術背后的場景，以及場景背后我們應該有技術思考，
不過這次體驗真的，讓我不得不感慨技術的便捷性，以前資料庫遷移都是團隊開發以及測驗一個團隊熬夜守著資料庫遷移，最后驗證測驗才能走的，所有人拖著疲憊的身軀看著升起的太陽，眼角都濕了...
現在我自己看看教程動動手指就完成了一場大規模的資料庫遷移演練，在享受技術給我帶來方便的同時，也讓我對技術背后的具體實作和人生的意義陷入了深深的思考，
或許這就是技術的價值吧，或許這就是這么多工程師日日夜夜辛苦的意義吧，或許...
我是敖丙，你知道的越多，你不知道的越多，我們下期見！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/146911.html
標籤：Java