DRS是啥你都不知道?不是吧，不是吧

前言

最近寫了很多數(shù)據(jù)庫(kù)相關(guān)的文章，大家基本上對(duì)數(shù)據(jù)庫(kù)也有了很多的了解，數(shù)據(jù)庫(kù)本身有所了解了，我們是不是應(yīng)該回歸業(yè)務(wù)本身呢？

大家去了解過自己企業(yè)數(shù)據(jù)庫(kù)的部署方式么？是怎么部署的，又是部署在哪里的？部署過程中可能會(huì)出現(xiàn)的問題有哪些？

是主從？還是雙主？有沒有分庫(kù)？大的表做了分表沒？等等...部署方式大概率也都是分庫(kù)的，表數(shù)量級(jí)超千萬基本上都開始分表了，考慮周全的企業(yè)，肯定也有數(shù)據(jù)庫(kù)的冷備，熱備，災(zāi)備，以及異地容災(zāi)等等。

我還記得我大學(xué)做項(xiàng)目，學(xué)校就是買了很多物理機(jī)，我們的項(xiàng)目和數(shù)據(jù)庫(kù)都是部署在自己內(nèi)部的服務(wù)器上的，那家伙一到夏天風(fēng)我嗡嗡嗡的吹，煩死了，機(jī)房還很熱。

但是我敢打賭，大家現(xiàn)在所在的企業(yè)，大概率都是使用了各種云服務(wù)廠商的服務(wù)部署方式，那就引入了今天的第一個(gè)思考。

為什么數(shù)據(jù)庫(kù)要上云呢？

我們公司的大多數(shù)服務(wù)以及數(shù)據(jù)庫(kù)都是在對(duì)應(yīng)的云服務(wù)廠商的，那問題就來了，為啥都要上云呢？

在思考這個(gè)問題的時(shí)候，我第一時(shí)間想到了反證法，不上云的壞處是啥？

相較于傳統(tǒng)服務(wù)器需要購(gòu)買、租用的方式，云服務(wù)器采用即用即收費(fèi)的方式，減少購(gòu)買成本，靈活擴(kuò)展的容量可以按自己需求來定，不用前期估量需要用多少。

我之前所在的電商活動(dòng)團(tuán)隊(duì)，每次到了大促我們就去租賃云服務(wù)廠商的流量機(jī)，等活動(dòng)結(jié)束就還回去，真的就是成本最大化了，而且還是根據(jù)你的使用流量計(jì)費(fèi)。

如果大家還是使用自己購(gòu)買的服務(wù)器，那這個(gè)時(shí)候難道去臨時(shí)采購(gòu)么？雖然我知道百度就是在某年春節(jié)活動(dòng)的時(shí)候采購(gòu)了N多物理機(jī)，但是性質(zhì)不一樣，他們是能最大化利用這些服務(wù)器的，他們甚至可以開發(fā)云服務(wù)自己做云服務(wù)廠商，實(shí)際上他們確實(shí)也這么做了。

云服務(wù)器實(shí)現(xiàn)了硬件上的隔離以及寬帶上的獨(dú)享，不受到地域、流量等的限制，可以持續(xù)的進(jìn)行業(yè)務(wù)交流，不會(huì)因中斷影響效果。

如果大家還是使用物理機(jī)，那去運(yùn)營(yíng)商遷專線的帶寬成本，還有物理機(jī)性能的問題也不一定能更上。

由于現(xiàn)在成本問題，你們公司買了很多低配的服務(wù)器，但是突然你們業(yè)務(wù)體量幾何增長(zhǎng)，怎么辦？繼續(xù)買高配的？顯然不是很合適。這誰頂?shù)米“。?/p>

云服務(wù)器可以實(shí)現(xiàn)遠(yuǎn)程同步管理，共享，各種業(yè)務(wù)的備份。傳統(tǒng)服務(wù)器需要在某一網(wǎng)絡(luò)區(qū)域內(nèi)，有可能受到網(wǎng)絡(luò)影響導(dǎo)致資料缺失。

上面我提到的冷備，熱備，災(zāi)備其實(shí)我們購(gòu)買的服務(wù)器都能做的，但是放著一個(gè)不知道什么時(shí)候才能用到的服務(wù)器在那，真的很浪費(fèi)。

而且也有他做不到的，比如災(zāi)備，如果你公司在震區(qū)，要是還用物理服務(wù)器，基本上等于自殺，發(fā)送自然災(zāi)害的時(shí)候全球的用戶都無法訪問你，交給服務(wù)廠商就不一樣了，他們選址很有講究的，并且在各個(gè)地方都建立自己的數(shù)據(jù)中心，保證了高可用。

為了保證云平臺(tái)的可靠性，云服務(wù)平臺(tái)公司肯定會(huì)投入大量的功夫，有一套可靠的安全保障系統(tǒng)，平臺(tái)使用者不必?fù)?dān)心平臺(tái)穩(wěn)定性、安全性問題。

物理機(jī)一旦高權(quán)限的所有者使壞，基本上都是不可恢復(fù)的災(zāi)難，雖然云服務(wù)也一樣，但是合理使用，和適當(dāng)?shù)臋?quán)限收斂，完全可以做到更高級(jí)別的安全的。

微盟事件大家也知道，如果提前做好各種全量，增量備份其實(shí)就沒什么大問題的，再者就是權(quán)限收斂問題，我司在對(duì)應(yīng)的數(shù)據(jù)庫(kù)服務(wù)器上是禁用了rm -rf 、fdisk以及drop這樣的極端操作的。

所有數(shù)據(jù)庫(kù)的查詢更是自己的組件查詢，連update都無法操作（只能靠代碼）。

如果還是使用物理機(jī)，就需要自己去維護(hù)，升級(jí)打補(bǔ)丁，很難保證不被黑客入侵，之前我就遇到過服務(wù)器補(bǔ)丁打遲了，導(dǎo)致被黑客攻擊，劫持拿去挖礦了，而云服務(wù)廠商的安全系統(tǒng)都是實(shí)時(shí)更新的。

小結(jié)：沒有特殊情況，能用云產(chǎn)品就直接用云產(chǎn)品，因?yàn)樵飘a(chǎn)品提供的不僅僅是產(chǎn)品能力，最關(guān)鍵的是關(guān)鍵時(shí)刻的容災(zāi)、應(yīng)急和服務(wù)能力，這些能力，并不是所有公司都能完整建設(shè)一套，甚至是很多公司想都想不到的。

到目前為止，雖然各大云廠商包括他們的產(chǎn)品，都還有這樣那樣的問題，但是從體系上，云仍然是最完善，最規(guī)范的，直接一點(diǎn)講，比99%的公司做的都要好。

上云需要考慮的問題

這里很有意思，我在寫這個(gè)文章的時(shí)候，我司正在做部分業(yè)務(wù)上云，以及云遷移這樣的業(yè)務(wù)，這讓我聯(lián)想到了很多有意思的事情。

我們現(xiàn)在是從某云遷移到華為云，我想大家也會(huì)與這樣的場(chǎng)景，但是這樣遷移會(huì)帶來一些什么樣的問題呢？不知道大家思考過沒？

其實(shí)從本地到云，或者從云到云，要思考的點(diǎn)估計(jì)是差多的，那我先拋出一些問題，看下這些問題華為云服務(wù)廠商是怎么解決的。

遷移失敗：數(shù)據(jù)遷移失敗怎么辦

數(shù)據(jù)丟失：怎么判斷遷移后數(shù)據(jù)是否完整

業(yè)務(wù)中斷：遷移到一半遇到不可抗力怎么辦

數(shù)據(jù)、傳輸加密：數(shù)據(jù)傳輸過程中怎么加密，防止被不法之徒中途獲取數(shù)據(jù)

熱切換：怎么做到不停服切換，以及數(shù)據(jù)源切換過程中的數(shù)據(jù)一致性

這些問題是我們不得不考慮的，大家是不是以為遷移多簡(jiǎn)單，那我想問一下，假如是訂單庫(kù)呢？大一點(diǎn)的電商每一秒，甚至是每一毫秒都是有訂單的，哪怕是凌晨，別問我為什么知道咳咳。

那你肯定不能停服去遷移數(shù)據(jù)庫(kù)，你需要一邊遷移一邊接受新的數(shù)據(jù)，這個(gè)時(shí)候就需要一些技巧了，不知道redis字典的rehash大家知道么？

rehash

在需要擴(kuò)容的時(shí)候，redis會(huì)新建一個(gè)hash字典，這個(gè)時(shí)候老的停止接收數(shù)據(jù)，新數(shù)據(jù)放到新的字典，同時(shí)慢慢把老數(shù)據(jù)拿過來，其實(shí)這個(gè)思想，在數(shù)據(jù)庫(kù)遷移也是可以用的，但是數(shù)據(jù)庫(kù)的操作，往往都是基于數(shù)據(jù)的，并不是都是增量。

那簡(jiǎn)單，做點(diǎn)取巧的操作也可以，那云廠商的已經(jīng)把我上面提到的所有問題都肯定考慮過了，我接觸的是華為云，華為云使用了DRS（Data Replication Service 數(shù)據(jù)復(fù)制服務(wù)）做數(shù)據(jù)庫(kù)遷移的事情，他怎么做的呢？

大家可能會(huì)好奇，為啥不自己去實(shí)現(xiàn)數(shù)據(jù)遷移，要用別人的組件呢？其實(shí)車輪子這個(gè)，如果你沒更好的思路你還是用別人寫好的就好了，你能比得過專業(yè)團(tuán)隊(duì)的研發(fā)結(jié)果嘛？

不過技術(shù)背后的實(shí)現(xiàn)，解決的問題還是需要我們?nèi)リP(guān)心的，不然DRS什么都幫我們做了，我們動(dòng)動(dòng)鼠標(biāo)就解決了，你怎么得到收獲呢？這才是今天探討的重點(diǎn)。

我說一下用車輪的好處吧：降低成本，降低技術(shù)門檻、降低風(fēng)險(xiǎn)

人力成本時(shí)間成本，都是很昂貴的，如果一個(gè)現(xiàn)成的東西都幫我們做了，我們還去開發(fā)干嘛？再者，我相信大部分公司還是沒專門的DBA的，但是車輪子在了，我們開發(fā)也能去做遷移這樣的事情了，不是嘛？我們傳統(tǒng)技術(shù)遷庫(kù)耗時(shí)耗力不說了，失敗率是真的高，還有數(shù)據(jù)對(duì)比等等，很頭疼，我之前東家數(shù)據(jù)庫(kù)遷移都是半夜，搞一晚上，天亮都不一定搞好了，要是沒好，用戶上線了，還的暫停。

不過即使是使用了工具，一個(gè)數(shù)據(jù)庫(kù)完整的遷移流程卻還是應(yīng)該很嚴(yán)謹(jǐn)?shù)模蠹铱赡軙?huì)疑惑再嚴(yán)謹(jǐn)能有多嚴(yán)謹(jǐn)？給你看個(gè)圖你就知道了：

華為云的DRS的在線遷移怎么做的呢？

可以看到，遷移圖中是使用到了VPN，這個(gè)的作用主要就是保住一個(gè)高速穩(wěn)定的傳輸，以及傳輸數(shù)據(jù)的加密，萬一你同步的過程被其他對(duì)手公司抓到，那？在文章后面，你可以看到華為云DRS是怎么做的網(wǎng)絡(luò)安全，我做了一次完整的遷移實(shí)戰(zhàn)，并且做了總結(jié)。

遷移實(shí)戰(zhàn)

他遷移很簡(jiǎn)單，都有教程，我用過一遍，大致步驟如下：

遷移作為一個(gè)特殊時(shí)期，業(yè)務(wù)配合、人為配合是最關(guān)鍵的，部分操作一定要規(guī)避，比如說常見的：

不能將源數(shù)據(jù)庫(kù)日志強(qiáng)制清理掉

不能將用于連接源數(shù)據(jù)庫(kù)的用戶密碼修改掉、或者刪除掉

不能將表長(zhǎng)時(shí)間鎖定，導(dǎo)致外部都無法查詢?cè)摫?/p>

他在遷移之前可以做一個(gè)遷移預(yù)檢查，從官方文檔來看，都是對(duì)過往遷移案例總結(jié)出來的檢查步驟，可以讓遷移成功有更好的保障，這點(diǎn)挺好可以在遷移前夕找出問題所在，我也失敗過，是因?yàn)榄h(huán)境問題，都給了很明確的指示。

大家不知道思考過沒，就是數(shù)據(jù)遷移了，但是如果數(shù)據(jù)庫(kù)的設(shè)置沒遷移那也是很麻煩的，如果一個(gè)遷移工具能夠做到把DBA設(shè)置的好的User權(quán)限遷移了，以及我們?cè)O(shè)置的各種觸發(fā)器，數(shù)據(jù)庫(kù)字符集設(shè)置都遷移了，那才是我理想的一個(gè)遷移工具，是的華為云DRS做了，這就是比較優(yōu)秀的點(diǎn)了，真的省了很多功夫。

特別是對(duì)于數(shù)據(jù)庫(kù)各種設(shè)置并沒那么了解的開發(fā)來說，這功能確實(shí)是很福利了，而且還有性能參數(shù)，類似各種buffer大小，cache大小等等他都能遷移，甚至可以做到流控，還可以隨時(shí)改變流控就更優(yōu)秀了：

遷移模式多樣化，這是我準(zhǔn)備開始遷移的第一感受，我上面提到過，如果不能增量遷移將毫無意義，DRS還是想到了，這讓我覺得好像有點(diǎn)暖，說著說著我的眼角又濕潤(rùn)了...

因?yàn)榇蟛糠值膱?chǎng)景我們都是線上業(yè)務(wù)的不停服遷移，在遷移過程中，還是不斷的有增量數(shù)據(jù)在涌入的，敖丙之前所經(jīng)歷過的數(shù)據(jù)庫(kù)遷移基本上也都是全量+增量的遷移模式，全量的場(chǎng)景只存在內(nèi)部系統(tǒng)，或者離線數(shù)據(jù)等。

其實(shí)這里的技術(shù)核心就在于怎么去保證增量的數(shù)據(jù)也能保證不丟失正確的遷移，我猜是通過binlog同步的，我看了下他的文檔，日志，果然被我猜對(duì)了。

DRS是通過全量遷移過程完成歷史數(shù)據(jù)遷移至目標(biāo)數(shù)據(jù)庫(kù)后，增量遷移階段通過捕抓日志，應(yīng)用日志等技術(shù)，將源端和目標(biāo)端數(shù)據(jù)庫(kù)保持?jǐn)?shù)據(jù)一致，這里的保持一致后面也會(huì)提到，他提供了完整的數(shù)據(jù)對(duì)比功能。

遷移過程很簡(jiǎn)單，進(jìn)度完全可以看到，數(shù)據(jù)的延遲也可以很直觀的看到：

遷移結(jié)束之后，DRS提供了數(shù)據(jù)對(duì)比，其實(shí)數(shù)據(jù)對(duì)比以前我做遷移的時(shí)候，我們都是通過對(duì)比數(shù)據(jù)庫(kù)行數(shù)去做的，因?yàn)闆]這樣的遷移工具，我發(fā)現(xiàn)了很暖心的一點(diǎn)就是內(nèi)容對(duì)比，這一點(diǎn)讓我很驚喜，因?yàn)樾袛?shù)的對(duì)比還是不夠嚴(yán)謹(jǐn)，修改的日志如果缺失行數(shù)的對(duì)比也是沒用的。

等待對(duì)比完成，點(diǎn)擊“查看對(duì)比報(bào)表”，可以了解對(duì)比詳情，詳情頁(yè)面如圖所示：

上面提到的網(wǎng)絡(luò)安全問題，我也在DRS找到了答案，他們會(huì)使用特定的加密協(xié)議進(jìn)行數(shù)據(jù)傳輸，還可以用特定的VPN掛載網(wǎng)絡(luò)傳輸：

DRS還做了遷移監(jiān)控，可以看到實(shí)時(shí)進(jìn)度，讓整個(gè)遷移進(jìn)度比較可視化，中間的異常也一目了然，說實(shí)話工具真的就是香，以前想都不敢想，我們熬夜就生怕一個(gè)環(huán)節(jié)出錯(cuò)，而且經(jīng)常還是后知后覺的，可視化的流程會(huì)你對(duì)遷移有一種掌控感。

遷移完成：

從我開始遷移到結(jié)束，整個(gè)流程其實(shí)不到2小時(shí)，這個(gè)放在以前是不敢想的，這波體驗(yàn)我是很滿意的，讓我一個(gè)開發(fā)就做到了以前DBA才能做的事情，說著說了旁邊的DBA的眼角也濕潤(rùn)了....

小結(jié)

整個(gè)體驗(yàn)我覺得是很不錯(cuò)的，我總結(jié)幾個(gè)我覺得DRS獨(dú)特的設(shè)計(jì)和使用場(chǎng)景：

遷移限速，根據(jù)限定時(shí)間段設(shè)置遷移速度上限

應(yīng)用場(chǎng)景:

有些流量型app，比如游戲廠商等客戶， 遷移時(shí)源數(shù)據(jù)庫(kù)的公網(wǎng)、VPN不能打滿（打滿將影響其對(duì)外業(yè)務(wù)，或者影響共用VPN 帶寬）

有些業(yè)務(wù)負(fù)載較重，或著客戶無法接受 業(yè)務(wù)時(shí)間應(yīng)用程序因?yàn)檫w移帶來額外負(fù)載

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

應(yīng)用場(chǎng)景:

市面上的遷移產(chǎn)品均不支持用戶的遷移， 也就是說如果用戶沒有注意，或者不懂用戶遷移，那么遷移后業(yè)務(wù)必然報(bào)錯(cuò)， DRS提供了全套的用戶權(quán)限繼承設(shè)計(jì)， 可以將權(quán)限、密碼、definer保留遷移至目標(biāo)數(shù)據(jù)庫(kù)，確保遷移后權(quán)限安全、業(yè)務(wù)穩(wěn)定，可以讓不熟悉數(shù)據(jù)庫(kù)的客戶遷移時(shí)，仍然可以完成一場(chǎng)精細(xì)的、高質(zhì)量的數(shù)據(jù)庫(kù)遷移。

參數(shù)對(duì)比，遷移后業(yè)務(wù)穩(wěn)定

應(yīng)用場(chǎng)景:

市面上的遷移產(chǎn)品均不支持參數(shù)的遷移，而數(shù)據(jù)庫(kù)參數(shù)不一樣，這將直接導(dǎo)致業(yè)務(wù)程序 運(yùn)行報(bào)錯(cuò)(舉個(gè)簡(jiǎn)單例子session數(shù)遷移后變小了)，DRS選定了業(yè)務(wù)和性能強(qiáng)相關(guān)關(guān)鍵的參數(shù)，避免了這些參數(shù)后續(xù)因?yàn)闆]有繼承源環(huán)境設(shè)置，而導(dǎo)致業(yè)務(wù)報(bào)錯(cuò)或性能下降， 可以讓不熟悉數(shù)據(jù)庫(kù)的客戶遷移時(shí)，仍然可以完成一場(chǎng)精細(xì)的、高質(zhì)量的數(shù)據(jù)庫(kù)遷移。

數(shù)據(jù)校對(duì)平臺(tái)，割接好幫手

應(yīng)用場(chǎng)景:

市面上的遷移產(chǎn)品均不支持?jǐn)?shù)據(jù)的對(duì)比，校對(duì)工作留給用戶測(cè)，DRS提供了豐富的對(duì)比功能:

對(duì)象對(duì)比

數(shù)據(jù)級(jí)對(duì)比

對(duì)比可定時(shí)，可取消

利用對(duì)比定時(shí)任務(wù)，可以選擇凌晨等業(yè)務(wù)低峰期 進(jìn)行數(shù)據(jù)一致性對(duì)比，第二天可以查看數(shù)據(jù)對(duì)比結(jié)果，對(duì)于遷移情況做到完全掌握。 可以讓不熟悉數(shù)據(jù)庫(kù)的客戶遷移時(shí)，仍然可以完成一場(chǎng)精細(xì)的、高質(zhì)量的數(shù)據(jù)庫(kù)遷移。

觸發(fā)器、事件的遷移

應(yīng)用場(chǎng)景:

市面上的遷移產(chǎn)品均不支持觸發(fā)器、事件的遷移，精通遷移的用戶關(guān)注這些細(xì)節(jié)，因 為觸發(fā)器和事件也是數(shù)據(jù)庫(kù)的一部分，觸發(fā)器和事件存在關(guān)鍵的業(yè)務(wù)邏輯，這些對(duì)象 不支持遷移，業(yè)務(wù)必然報(bào)錯(cuò)，甚至造成不可挽回的損失。

可以讓不熟悉數(shù)據(jù)庫(kù)的客戶遷移時(shí)，仍然可以完成一場(chǎng)精細(xì)的、高質(zhì)量的數(shù)據(jù)庫(kù)遷移。

注：【部分圖片來源網(wǎng)絡(luò) 侵刪】

總結(jié)

其實(shí)給大家介紹這樣DRS的一個(gè)背景和技術(shù)，主要是希望跟大家跟我一起做一次完整數(shù)據(jù)遷移，一起去探討技術(shù)背后的場(chǎng)景，以及場(chǎng)景背后我們應(yīng)該有技術(shù)思考。

不過這次體驗(yàn)真的，讓我不得不感慨技術(shù)的便捷性，以前數(shù)據(jù)庫(kù)遷移都是團(tuán)隊(duì)開發(fā)以及測(cè)試一個(gè)團(tuán)隊(duì)熬夜守著數(shù)據(jù)庫(kù)遷移，最后驗(yàn)證測(cè)試才能走的，所有人拖著疲憊的身軀看著升起的太陽(yáng)，眼角都濕了...

現(xiàn)在我自己看看教程動(dòng)動(dòng)手指就完成了一場(chǎng)大規(guī)模的數(shù)據(jù)庫(kù)遷移演練，在享受技術(shù)給我?guī)矸奖愕耐瑫r(shí)，也讓我對(duì)技術(shù)背后的具體實(shí)現(xiàn)和人生的意義陷入了深深的思考。

或許這就是技術(shù)的價(jià)值吧，或許這就是這么多工程師日日夜夜辛苦的意義吧，或許...

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

數(shù)據(jù)庫(kù) Mysql Java

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。