分布式數(shù)據(jù)庫(kù)已經(jīng)進(jìn)入了全面快速發(fā)展階段。這種發(fā)展是與時(shí)俱進(jìn)的，與人的需求分不開(kāi)，因?yàn)楝F(xiàn)在信息時(shí)代的高速發(fā)展，導(dǎo)致數(shù)據(jù)量和交易量越來(lái)越大。這種現(xiàn)象首先導(dǎo)致的就是存儲(chǔ)瓶頸，因?yàn)镸ySQL數(shù)據(jù)庫(kù)實(shí)質(zhì)上還是一個(gè)單機(jī)版本的數(shù)據(jù)庫(kù)，而只要是單機(jī)，就必然會(huì)遇到的一個(gè)問(wèn)題就是存儲(chǔ)問(wèn)題，因?yàn)榇鎯?chǔ)是硬需求，而CPU和內(nèi)存如果不夠的話，只是性能不好，并不會(huì)直接否定方案或者架構(gòu)。

?

存儲(chǔ)問(wèn)題的解決，其實(shí)我們每一家公司或者個(gè)人，都一直在努力著。解決方案大概有三個(gè)方面：

?

1、增大磁盤(pán)

?

這種方式應(yīng)該是最直接、最簡(jiǎn)單的方案了，因?yàn)榇疟P(pán)空間不足了，當(dāng)然加磁盤(pán)是手到病除，比如現(xiàn)在是800G，可以增加到2T，這是沒(méi)問(wèn)題的；如果現(xiàn)在已經(jīng)達(dá)到了2T，當(dāng)然，還是可以增加到5T的盤(pán)。但實(shí)際上，這個(gè)時(shí)候可能DBA就要捏把汗了，這么大數(shù)據(jù)量的MySQL實(shí)例，如何運(yùn)維？如果數(shù)據(jù)壞了，如何恢復(fù)呢？時(shí)間成本呢？

?

5T的數(shù)據(jù)量，已經(jīng)非常嚇人了，估計(jì)在業(yè)內(nèi)各大公司，沒(méi)有DBA會(huì)希望自己運(yùn)維的MySQL實(shí)例達(dá)到這個(gè)量級(jí)吧？

?

其實(shí)我個(gè)人認(rèn)為，這個(gè)已經(jīng)是不能接受的量了，最合適的是保持在1T以下，超過(guò)就要想辦法了。

?

當(dāng)然，數(shù)據(jù)量不宜達(dá)到這個(gè)大小的原因，可能會(huì)有人考慮到這是性能的問(wèn)題，其實(shí)不然，或者性能問(wèn)題很小。因?yàn)镮nnoDB采用的是B+樹(shù)的存儲(chǔ)方案，小表最壞情況下沒(méi)有查到數(shù)據(jù)是要找3層，也就是3個(gè)頁(yè)面的IO，而大表需要的是4個(gè)頁(yè)面的IO，影響不大。

?

2、數(shù)據(jù)壓縮

?

為了減少數(shù)據(jù)對(duì)磁盤(pán)空間的占用，我們通常也會(huì)將數(shù)據(jù)做壓縮處理，通過(guò)一個(gè)語(yǔ)句即可搞定，是InnoDB原生支持的一種方式。一般情況下，會(huì)將數(shù)據(jù)占用減少到原來(lái)的三分之一到一半不等，效果還是足夠明顯的，不過(guò)這樣處理之后的數(shù)據(jù)，在性能上會(huì)有所下降，對(duì)于響應(yīng)要求比較高的業(yè)務(wù)，可能需要謹(jǐn)慎考慮一下。

?

但這種方式還是治標(biāo)不治本，在數(shù)據(jù)量繼續(xù)增長(zhǎng)的情況下，過(guò)段時(shí)間之后，依然會(huì)面臨相同的問(wèn)題，這種情況下，就不能繼續(xù)使用這種方式來(lái)實(shí)現(xiàn)了。

?

3、數(shù)據(jù)分片

?

數(shù)據(jù)分片的解決方案，現(xiàn)在業(yè)內(nèi)用得也很多，這種方案已經(jīng)超出了MySQL本身，包括HBase、Redis等也都在使用這種方案，應(yīng)該說(shuō)這種方案是最具擴(kuò)展性的，并且可以稱得上是無(wú)限擴(kuò)展。而上面兩種方案，根本談不上擴(kuò)展性。所以這種方案在業(yè)內(nèi)成為主流，并且這種方案才能稱得上是分布式存儲(chǔ)，具體的實(shí)現(xiàn)也層出不窮。當(dāng)然，存在優(yōu)秀的分布式解決方案，也存在一些“偽”分布式方案了。

?

一、分布式解決方案需求

?

1、擴(kuò)展性

?

使用分布式，其實(shí)最主要的就是擴(kuò)展性，如果空間不足了，可以很方便容易的擴(kuò)展節(jié)點(diǎn)個(gè)數(shù)，并且將數(shù)據(jù)做新的平衡處理。這個(gè)過(guò)程要不影響業(yè)務(wù)使用，對(duì)業(yè)務(wù)透明。

?

2、支持事務(wù)

?

分布式數(shù)據(jù)庫(kù)，對(duì)于業(yè)務(wù)本身，使用方面與單機(jī)區(qū)別不大，也就是對(duì)業(yè)務(wù)透明，因?yàn)槭褂肕ySQL是支持事務(wù)的，那么MySQL變身為分布式之后，事務(wù)特性還是不能少的，所以整體上看來(lái)，還是要支持分布式事務(wù)。

?

3、SQL語(yǔ)句無(wú)限制

?

業(yè)務(wù)需求的多樣性，導(dǎo)致在SQL需求上面都是比較廣泛的，針對(duì)業(yè)務(wù)的透明性，如果某些SQL語(yǔ)句不支持，那這樣導(dǎo)致的問(wèn)題是，一方面限制了業(yè)務(wù)程序的功能和性能；另一方面導(dǎo)致業(yè)務(wù)程序與“分布式數(shù)據(jù)庫(kù)”的捆綁問(wèn)題。

?

4、性能足夠好

?

使用分布式數(shù)據(jù)庫(kù)，其實(shí)基本上是對(duì)性能的要求比較低的業(yè)務(wù)才會(huì)這樣選擇，即使是這樣，還是性能越高，越多人才會(huì)選擇這樣的分布式數(shù)據(jù)庫(kù)。

?

5、元數(shù)據(jù)變更透明性

?

元數(shù)據(jù)變更，在任何數(shù)據(jù)庫(kù)中都是存在的。在單點(diǎn)情況下，改表操作我們有多種友好的方法來(lái)實(shí)現(xiàn)。但到了分布式環(huán)境下，可能這種操作就成為了問(wèn)題，因?yàn)閿?shù)據(jù)的分片導(dǎo)致了元數(shù)據(jù)的變更需要多點(diǎn)修改，進(jìn)而很多問(wèn)題就來(lái)了，比如原子性、數(shù)據(jù)可見(jiàn)性、正確性等等，所以這是最基本的問(wèn)題。

?

6、底層數(shù)據(jù)庫(kù)的高可用性

?

話說(shuō)經(jīng)濟(jì)基礎(chǔ)決定上層建筑，在分布式數(shù)據(jù)庫(kù)中也是一樣的，如果底層數(shù)據(jù)庫(kù)的不穩(wěn)定，或者數(shù)據(jù)復(fù)制延遲，亦或出現(xiàn)數(shù)據(jù)不一致的問(wèn)題，則上層應(yīng)用的訪問(wèn)正確性就沒(méi)法保證，所以底層數(shù)據(jù)庫(kù)最基本的就是保證數(shù)據(jù)一致性（高可用）。

?

二、流行分布式數(shù)據(jù)庫(kù)解決方案

?

1、中間件分庫(kù)分表（偽分布式）

?

在MySQL界，一個(gè)存在很久的話題，就是“哪個(gè)中間件實(shí)現(xiàn)的分庫(kù)分表方案比較好？”

?

當(dāng)然對(duì)于同一個(gè)問(wèn)題，不同人有不同的理解，也都具有兩面性的特征，有人說(shuō)好，也有人說(shuō)不好，我們首先看一下這種方案是如何實(shí)現(xiàn)的。

?

?

MyCat的實(shí)現(xiàn)架構(gòu)大概如上圖所示，其實(shí)如果只看圖的話，這樣的架構(gòu)真是完美無(wú)缺，自動(dòng)分片、自動(dòng)聚合、分布均衡都實(shí)現(xiàn)的非常好。

?

但事實(shí)并非如此。

?

我們可以通過(guò)問(wèn)答的方式，一步步認(rèn)清楚這種方式的核心問(wèn)題：

?

問(wèn)題1：MyCat如何知道數(shù)據(jù)分片原理，或者說(shuō)是如何決定路由路徑的？

?

這個(gè)問(wèn)題，在圖上面是看不出來(lái)的。

?

MyCat是如何定義或者決定一條SQL語(yǔ)句的執(zhí)行方式，或者如何決定去哪里取數(shù)據(jù)及寫(xiě)入到哪里的？解決這樣的問(wèn)題是需要某一個(gè)地方來(lái)存儲(chǔ)的，它的做法是——schema.xml配置文件，竟然用配置文件來(lái)搞定。

?

那這樣問(wèn)題就多了，修改分庫(kù)分表規(guī)則之后，如何保證配置與數(shù)據(jù)同步更新？即使不使用schema.xml配置文件，而是用數(shù)據(jù)庫(kù)存儲(chǔ)，那配置規(guī)則的變更與數(shù)據(jù)節(jié)節(jié)點(diǎn)中數(shù)據(jù)的遷移，也是沒(méi)辦法保證統(tǒng)一的，勢(shì)必會(huì)對(duì)業(yè)務(wù)造成影響。

?

問(wèn)題2：如果需要擴(kuò)展節(jié)點(diǎn)了，并且需要做rebalance，如何來(lái)做？

?

很多用戶，基本都是重新準(zhǔn)備一套集群，或者先把數(shù)據(jù)一點(diǎn)點(diǎn)手動(dòng)導(dǎo)出導(dǎo)入，導(dǎo)到目標(biāo)節(jié)點(diǎn)之后，然后去手動(dòng)修改schema.xml配置文件，然后做一次reload操作，這樣就實(shí)現(xiàn)了重新路由，但這樣同樣會(huì)導(dǎo)致上面的結(jié)果。

?

并且這個(gè)過(guò)程，需要處理好多數(shù)據(jù)，處理完成之后各種檢查，并且占用空間需要兩倍，這樣折騰，一個(gè)DBA只要干一次，可能就有辭職的沖動(dòng)。

?

問(wèn)題3：全局表是什么東西？

?

MyCat支持一個(gè)所謂的全局表，用來(lái)解決跨節(jié)點(diǎn)數(shù)據(jù)聚合的問(wèn)題。實(shí)現(xiàn)方法是在每一個(gè)分片上面都創(chuàng)建這樣的全局表，它的定義是不怎么修改，查詢比較頻繁表可以定義為全局表，這樣的話在每一個(gè)分片節(jié)點(diǎn)上，只要用到這個(gè)表，就可以實(shí)現(xiàn)本地查詢連接等操作。

?

這樣的確是可以解決部分問(wèn)題，但問(wèn)題是如果分片多的話（假如分片100個(gè)），如何保證數(shù)據(jù)一致性？這么多節(jié)點(diǎn)的XA事務(wù)影響是什么？如果出現(xiàn)不一致或者訪問(wèn)錯(cuò)誤，引起的問(wèn)題就是數(shù)據(jù)結(jié)果錯(cuò)誤，這樣的結(jié)果肯定不是業(yè)務(wù)想要看到的吧？這還不是最關(guān)鍵的，一個(gè)數(shù)據(jù)庫(kù)集群，搞這么一個(gè)特殊處理的東西是何道理？

?

問(wèn)題4：MyCat究竟做了什么事情？

?

作為一個(gè)中間層，本職工作應(yīng)該是接收客戶端的SQL請(qǐng)求，通過(guò)語(yǔ)法分析，根據(jù)讀寫(xiě)原則確定一個(gè)集群中一個(gè)讀寫(xiě)節(jié)點(diǎn)即可，然后就等著結(jié)果集的返回。對(duì)于結(jié)果集本身，中間層并不需要去關(guān)心，只需要將結(jié)果集（或者異常）原原本本發(fā)回給客戶端即可。

?

而MyCat做的事情遠(yuǎn)比這個(gè)多，在語(yǔ)法分析之后，再做語(yǔ)義分析，拿到對(duì)應(yīng)數(shù)據(jù)庫(kù)表結(jié)構(gòu)，同時(shí)判斷這個(gè)表的分發(fā)路由規(guī)則，再找到語(yǔ)句中的數(shù)據(jù)及涉及到的列，再?zèng)Q定路由到哪個(gè)分片中。如果在分發(fā)時(shí)路由規(guī)則配置錯(cuò)誤或者程序計(jì)算錯(cuò)誤，會(huì)導(dǎo)致整個(gè)語(yǔ)句的結(jié)果出現(xiàn)不可預(yù)知的問(wèn)題。

?

請(qǐng)問(wèn)這前半部分，是一個(gè)中間層應(yīng)該做的事情么？竟然還要關(guān)心語(yǔ)句中涉及到的表結(jié)構(gòu)、主鍵、數(shù)據(jù)等信息，這其實(shí)都是數(shù)據(jù)庫(kù)要做的事情啊！實(shí)則是越俎代庖。

?

再請(qǐng)問(wèn)，所做的這些事情，能比一個(gè)專業(yè)數(shù)據(jù)庫(kù)做得更好么？

?

咱再看后半部分，等收到結(jié)果集之后，MyCat為了處理一些結(jié)果集的聚合計(jì)算，需要把各個(gè)節(jié)點(diǎn)本來(lái)已經(jīng)封裝好的結(jié)果集（二進(jìn)制MySQL協(xié)議流數(shù)據(jù)），解析出來(lái)，然后通過(guò)需要計(jì)算出來(lái)（這個(gè)計(jì)算有可能非常慢，并且不是所有的都可以搞定），計(jì)算完成之后，再打包成MySQL協(xié)議流數(shù)據(jù)，傳給客戶端。

?

請(qǐng)問(wèn)這樣的中間層，做了這么多事情，性能如何保證？而本身這些聚合計(jì)算Order By、Group By的處理，本身是數(shù)據(jù)庫(kù)的事情，實(shí)則還是越俎代庖。

?

問(wèn)題5：通過(guò)SQL語(yǔ)句的變換，實(shí)現(xiàn)分布式是不是有點(diǎn)困難？

?

MyCat這種中間層，代表了宣稱分布式數(shù)據(jù)庫(kù)的一類使用方式，但這種實(shí)現(xiàn)方法實(shí)際上都是通過(guò)在SQL語(yǔ)句上做文章，從客戶端拿到的是SQL語(yǔ)句，給后端數(shù)據(jù)庫(kù)的也是SQL語(yǔ)句，但這兩個(gè)SQL語(yǔ)句是經(jīng)過(guò)變換的。

?

當(dāng)然這種方法也只能這樣，因?yàn)楹蠖藬?shù)據(jù)庫(kù)只接收SQL語(yǔ)句。試問(wèn)，一個(gè)復(fù)雜的SQL語(yǔ)句查詢操作，通過(guò)SQL變換或重寫(xiě)，就能實(shí)現(xiàn)對(duì)不同分片數(shù)據(jù)庫(kù)的分布式查詢？

?

想想就清楚了，雖然SQL語(yǔ)句通用靈活，但可擴(kuò)展性或者重寫(xiě)的邏輯還是有點(diǎn)復(fù)雜的吧？當(dāng)然了，有人可能會(huì)說(shuō)，我們有兜底的啊，大不了把這個(gè)語(yǔ)句就改一下庫(kù)名表名然后其它保持不變分給每一個(gè)節(jié)點(diǎn)去執(zhí)行，這樣總沒(méi)問(wèn)題吧，是的，你說(shuō)的沒(méi)錯(cuò)。

?

問(wèn)題6：在同一個(gè)事務(wù)中要修改不同節(jié)點(diǎn)的數(shù)據(jù)是如何處理的？

?

這個(gè)問(wèn)題就是我們通常所說(shuō)的分布式事務(wù)了。究竟是怎么回事呢？MyCat下面對(duì)的是MySQL Server，也就是說(shuō)MyCat只能用SQL語(yǔ)句與MySQL Server交流，這樣就是局限于MySQL的SQL語(yǔ)句的功能了。

?

那在分布式實(shí)現(xiàn)上面，MySQL XA本身有多少人用？MyCat如果實(shí)現(xiàn)一個(gè)跨節(jié)點(diǎn)的數(shù)據(jù)更新，不用MySQL XA，還能用其它什么？

?

別無(wú)他選。本身依賴一個(gè)沒(méi)有太多人用、并且可能存在很多問(wèn)題，包括性能、Bug的功能，這樣上層MyCat乃至應(yīng)用程序的可靠性如何保證？

?

當(dāng)然基于這些問(wèn)題，有些方案選擇不用XA，如果某些節(jié)點(diǎn)失敗了，選擇忽略不解決，這當(dāng)然也可以，妥協(xié)嘛——不需要底線的。

?

問(wèn)題7：MyCat后端數(shù)據(jù)庫(kù)的架構(gòu)是什么，如何保證穩(wěn)定可靠高可用？

?

這個(gè)據(jù)某些文章宣傳說(shuō)，之前可以選擇主從復(fù)制，現(xiàn)在可以選擇Galera Cluster，或者也可以選擇更新的MGR。

?

當(dāng)然不得不說(shuō)，從前到后，可能確實(shí)保證了更好的可靠性，但有一個(gè)很大的問(wèn)題是，Galera的門(mén)檻比較高，遇到問(wèn)題的話，很少人能解決掉。再到MGR，本身還得等，能用還要比較長(zhǎng)的時(shí)間，這問(wèn)題還是要回到主從復(fù)制，這是老問(wèn)題了，主從復(fù)制的一致性很難保證，MyCat如果通過(guò)讀寫(xiě)分離策略將讀打到從上面，而這個(gè)正好有延遲，這樣產(chǎn)生的后果可能是整個(gè)應(yīng)用程序的計(jì)算結(jié)果是錯(cuò)誤的。

?

當(dāng)然可以說(shuō)有延遲檢查，那問(wèn)題是，延遲檢查的話，是不是還有一個(gè)參數(shù)可以配置呢？如果延遲超過(guò)100秒的話就去查主庫(kù)？

?

沒(méi)錯(cuò)，不過(guò)100秒難道就不是延遲了？那可以設(shè)置為0，看到的0，你以為真的是0？其實(shí)還是主從復(fù)制的劣根性。所以問(wèn)題還是回到了起點(diǎn)，經(jīng)濟(jì)基礎(chǔ)決定上層建筑，基礎(chǔ)不好，上層如何是好？

?

問(wèn)題8：分片多了的情況下，性能是如何保證損失最小的？

?

這個(gè)問(wèn)題，我并不知道MyCat有沒(méi)有做過(guò)優(yōu)化，比如10個(gè)分片，如果一個(gè)語(yǔ)句的執(zhí)行會(huì)涉及到這十個(gè)分片，那在每個(gè)分片上重寫(xiě)語(yǔ)句之后，就要分別在這十個(gè)分片上執(zhí)行對(duì)應(yīng)的語(yǔ)句了。

?

執(zhí)行時(shí)是串行，還是并行？串行的話，性能必然會(huì)下降10倍以上，所以做得好點(diǎn)的話，就是并行了，但并行的實(shí)現(xiàn)方法是，在MyCat這個(gè)連接上面，創(chuàng)建10個(gè)線程，去處理這十個(gè)節(jié)點(diǎn)的執(zhí)行情況。那這樣的連接多了，MyCat產(chǎn)生的對(duì)系統(tǒng)的沖擊就非常大了，性能還是不行。

?

當(dāng)然也可以說(shuō)，這里做了連接池，沒(méi)錯(cuò)，是可以的，但MyCat是這樣做的么？這樣做了性能又如何呢？如果有一個(gè)超時(shí)，整個(gè)訪問(wèn)就失敗了。

?

問(wèn)題9：配置文件或者配置庫(kù)出問(wèn)題，整個(gè)集群會(huì)出現(xiàn)什么情況？

?

前面已經(jīng)說(shuō)了，MyCat用的是schema.xml來(lái)配置的分庫(kù)分表策略，這是一個(gè)配置文件，MyCat本身的高可用，如果配置多套的話，他們的同步問(wèn)題，是如何解決的？如果沒(méi)有同步（或者同步出問(wèn)題，或者延遲等），某一個(gè)MyCat掛了，業(yè)務(wù)切換到其它的MyCat時(shí)，此時(shí)的情況就是：故障……故障……

?

因?yàn)閿?shù)據(jù)都亂了。

?

有可能造成的問(wèn)題是，寫(xiě)入了錯(cuò)誤的位置，進(jìn)而導(dǎo)致整個(gè)集群的數(shù)據(jù)被寫(xiě)壞。感覺(jué)比直接被刪了還嚴(yán)重。

?

同樣的問(wèn)題，感覺(jué)MyCat可能會(huì)優(yōu)化這點(diǎn)，也許會(huì)改為將其集中存儲(chǔ)在某一個(gè)數(shù)據(jù)庫(kù)中，這樣集中管理的話就不需要同步了，想法是好的，但這相當(dāng)于是把雞蛋放在一個(gè)籃子里面了，如果這個(gè)配置庫(kù)出問(wèn)題了，業(yè)務(wù)何去何從？

?

問(wèn)題10：DDL如何進(jìn)行？

?

這個(gè)問(wèn)題也許是每個(gè)人都關(guān)心的事情了，MyCat把數(shù)據(jù)都分而不相關(guān)的分片MySQL節(jié)點(diǎn)了，這樣很多在單點(diǎn)上的改表策略都不能用了，而DDL又是一個(gè)必須要保證每個(gè)節(jié)點(diǎn)同時(shí)完成的事情，那在分布式上面是如何保證的呢？

?

根據(jù)我的調(diào)研，好像現(xiàn)在使用MyCat的人，都是通過(guò)“同一時(shí)刻啟動(dòng)在每一個(gè)節(jié)點(diǎn)上更新表結(jié)構(gòu)”這樣的方法來(lái)做的，當(dāng)然還得選擇是半夜，當(dāng)然我個(gè)人覺(jué)得也是可行的，因?yàn)楫吘挂呀?jīng)使用了它，而沒(méi)有更好的辦法來(lái)解決這個(gè)問(wèn)題。

?

當(dāng)然咱再說(shuō)后果，如果做不到無(wú)縫原子修改，那對(duì)業(yè)務(wù)的影響不是一星半點(diǎn)，可能會(huì)有很多SQL會(huì)報(bào)表不存在的問(wèn)題。如果一個(gè)語(yǔ)句和另一個(gè)語(yǔ)句修改完成時(shí)間相差比較多的話，兩個(gè)相減的時(shí)間就是故障時(shí)間了。

?

問(wèn)題11：據(jù)我調(diào)研，MyCat還實(shí)現(xiàn)了自動(dòng)故障切換的功能，請(qǐng)問(wèn)這個(gè)靠譜么？

?

我們現(xiàn)在討論的是分布式架構(gòu)方案，而這個(gè)問(wèn)題講的情況是，某一個(gè)MyCat發(fā)現(xiàn)了后端數(shù)據(jù)庫(kù)連不上了，會(huì)自動(dòng)切換的功能。這就非常明顯了，我們要的是分布式，某“一個(gè)”MyCat節(jié)點(diǎn)認(rèn)為的問(wèn)題就真的是它所認(rèn)為的嗎？

?

也就是說(shuō)，一個(gè)節(jié)點(diǎn)并不能保證判斷的或者看到的現(xiàn)象是真實(shí)的，那這種情況下就存在誤切換的情況，而如果其它中間層節(jié)點(diǎn)還不知道這個(gè)情況，或者未及時(shí)收到切換的消息，就出現(xiàn)了多點(diǎn)寫(xiě)入的問(wèn)題，挺可怕的。

?

這不是自相矛盾嗎？

?

我們要的是分布式，結(jié)果又存在“獨(dú)斷”的環(huán)節(jié)，可靠性又下降了不少。關(guān)于分布式監(jiān)控切換的問(wèn)題，因?yàn)樵谌ツ膬河玫膍ysql-sentinel對(duì)Galera Cluster做的監(jiān)控，我對(duì)這點(diǎn)深有感觸，所以不得不在這里講一下。

?

問(wèn)題12：在MyCat上面?zhèn)浞菔侨绾巫龅?#xff1f;能做到恢復(fù)一個(gè)快照嗎？

?

說(shuō)起備份，做為數(shù)據(jù)庫(kù)使用者，應(yīng)該沒(méi)有一個(gè)不清楚，沒(méi)有一個(gè)人會(huì)覺(jué)得不重要吧？當(dāng)然，重要是重要，但這種事情屬于重要不緊急的工作，但沒(méi)有是不行的，這個(gè)連公司內(nèi)審這一關(guān)都過(guò)不了，也許我們每一個(gè)人都不會(huì)希望能用到它。

?

言歸正傳，這么重要的備份工作，在MyCat上又是什么情況呢？

?

可能了解一些基本原理的人都比較清楚，Xtrabackup、mysqldump等也都是可以用的，但備份完了之后可能心里還是感覺(jué)沒(méi)底，因?yàn)檫@樣的工具，只能對(duì)一個(gè)MySQL節(jié)點(diǎn)做備份。如果分10個(gè)分片（10個(gè)MySQL節(jié)點(diǎn)）的話，可以通過(guò)備份十次即可完成，但需要注意的是，備份了十次產(chǎn)生了十個(gè)備份集，而并不是一個(gè)備份集，這十個(gè)備份集之間是完完全全沒(méi)有關(guān)系的，此時(shí)我可能就提出一個(gè)比較極端的問(wèn)題來(lái)：

?

如果哪天（當(dāng)然我們都不希望有這樣的一天），整個(gè)機(jī)房掛了，當(dāng)然假如“幸運(yùn)”的是，有備份，那在這種情況下，如何恢復(fù)一個(gè)可用的數(shù)據(jù)一致及完整的集群快照呢？

?

這個(gè)時(shí)候可能會(huì)有人很快地說(shuō)，將十個(gè)備份集都恢復(fù)了啟動(dòng)了即可。

?

但問(wèn)題是這十個(gè)沒(méi)有關(guān)系，備份時(shí)間又不是同一時(shí)刻完成的，同一個(gè)表的十個(gè)分片，最新數(shù)據(jù)有的是8點(diǎn)的，有的是9點(diǎn)的，或者有的甚至是昨天的。這樣恢復(fù)出來(lái)的表，能用么？基于這樣的表產(chǎn)生的查詢結(jié)果，靠譜么？可想而知。

?

當(dāng)然可能也有人會(huì)說(shuō)，我們的數(shù)據(jù)不需要一致快照，或者更有甚者只需要備份元數(shù)據(jù)路由表或者配置文件即可，那這樣就沒(méi)問(wèn)題了，如果MyCat只是定位于用來(lái)存儲(chǔ)Zabbix監(jiān)控?cái)?shù)據(jù)或者日志數(shù)據(jù)，可以丟失不要的數(shù)據(jù)、一文不值的數(shù)據(jù)，那我覺(jué)得沒(méi)毛病。

?

或許有人還會(huì)說(shuō)，我們的機(jī)房不會(huì)掛，或者我們的存儲(chǔ)本來(lái)就是跨機(jī)房的，掛了的話直接切到另外的機(jī)房就行了。那此時(shí)又有問(wèn)題了，如果切換的時(shí)候，有復(fù)制延遲，丟失了部分?jǐn)?shù)據(jù)，那整個(gè)集群又會(huì)出問(wèn)題。因?yàn)橹灰幸粋€(gè)分片的數(shù)據(jù)出問(wèn)題，整個(gè)集群就有問(wèn)題了。

?

或者另一個(gè)問(wèn)題就是，假設(shè)你的機(jī)房真的不會(huì)掛，但我們經(jīng)常會(huì)遇到的需求是，我要取前幾天某時(shí)刻的數(shù)據(jù)，那此時(shí)還是需要通過(guò)備份然后恢復(fù)一個(gè)快照，這個(gè)時(shí)候還有何話可說(shuō)，你告訴我究竟如何做到？

?

可能還會(huì)有人有疑問(wèn)，他會(huì)說(shuō)我們是邏輯備份啊，這樣備份出來(lái)的是整個(gè)庫(kù)或者表的一致性快照，這不就解決問(wèn)題了么？

?

我很同意這位同學(xué)的看法，說(shuō)得對(duì)極了，是可以很完美地解決一致性問(wèn)題，但只要熟悉一點(diǎn)點(diǎn)MySQL的人都知道，類似mysqldump這樣的邏輯備份工具，是何其慢？現(xiàn)在都用分布式存儲(chǔ)了，那肯定是數(shù)據(jù)量非常大，這個(gè)時(shí)候還在使用這樣的邏輯備份？你是想干哈？即使備份完成了，那有沒(méi)有試過(guò)邏輯數(shù)據(jù)的恢復(fù)？幾個(gè)G的數(shù)據(jù)要恢復(fù)多久，你算過(guò)沒(méi)有？想想都頭疼，一條不歸路……

?

問(wèn)題13：如果已經(jīng)在使用MyCat了，發(fā)現(xiàn)它的風(fēng)險(xiǎn)確實(shí)太大了，我如何能下掉呢？

?

這個(gè)問(wèn)題非常好，說(shuō)明你已經(jīng)在思考做為一個(gè)數(shù)據(jù)負(fù)責(zé)人，如何保證數(shù)據(jù)的可靠性和避免風(fēng)險(xiǎn)的問(wèn)題了。MyCat風(fēng)險(xiǎn)確實(shí)高，但如果已經(jīng)上了“賊船”并且想下掉的話，此時(shí)我可能想問(wèn)一下（做一回事后諸葛亮），上這個(gè)架構(gòu)的時(shí)候?yàn)槭裁床欢嗫紤]一下呢？公司的數(shù)據(jù)就是金錢(qián)，你這樣想上就上，想下就下，來(lái)回折騰，能升值么？萬(wàn)一數(shù)據(jù)寫(xiě)亂了，這個(gè)時(shí)候可沒(méi)有人賠你錢(qián)，還不如上云呢。

?

不過(guò)既然上了，那咱就聊聊如何下掉的問(wèn)題，我目前感覺(jué)最靠譜最穩(wěn)妥的辦法，貌似只有一個(gè)，步驟如下：

?

第1步，先停業(yè)務(wù)，將所有的寫(xiě)業(yè)務(wù)都停止（也不用找深夜時(shí)間了，因?yàn)?2小時(shí)根本搞不完）。

?

第2步，通過(guò)上面所講的mysqldump做邏輯備份，將所有的庫(kù)導(dǎo)出來(lái)，生成.sql文件。

?

第3步，然后找一個(gè)靠譜的MySQL架構(gòu)（真正的分布式數(shù)據(jù)庫(kù)，或者磁盤(pán)足夠大的話可以不采用分布式，采用Share Nothing的方案即可，也許你需要的并不是分布式，只是被忽悠了），將.sql文件導(dǎo)入進(jìn)去。

?

第4步，再后就將讀業(yè)務(wù)遷移到新的數(shù)據(jù)庫(kù)架構(gòu)上面去。

?

第5步，將寫(xiě)業(yè)務(wù)也遷移到新的數(shù)據(jù)庫(kù)架構(gòu)上面去，然后啟動(dòng)他們，這個(gè)時(shí)候應(yīng)該是可以提供正常的數(shù)據(jù)庫(kù)服務(wù)了。

?

我們可以注意一下這個(gè)過(guò)程，從第1步，到第5步，需要多少時(shí)間？這個(gè)當(dāng)然是硬時(shí)間，是要移動(dòng)數(shù)據(jù)的，邏輯備份和恢復(fù)都那么慢，我覺(jué)得時(shí)間的單位可以用天來(lái)統(tǒng)計(jì)了。

?

這個(gè)時(shí)候負(fù)責(zé)人就可以想想，我用MyCat是圖什么啊，業(yè)務(wù)的免戰(zhàn)牌掛了好幾天，只是為了彌補(bǔ)當(dāng)年的一個(gè)錯(cuò)誤決定，追悔莫及。

?

當(dāng)然也許有些人也會(huì)有其它辦法，但因?yàn)楦鱾€(gè)分片都是相互獨(dú)立的，還是存在上面的所說(shuō)的在不停止業(yè)務(wù)的情況下的“一致性快照”的問(wèn)題。

?

最后我想說(shuō)的是，對(duì)公司的數(shù)據(jù)，一定要慎之又慎，要時(shí)刻保持負(fù)責(zé)的態(tài)度，折騰數(shù)據(jù)真的不能升值啊。

?

問(wèn)題14：MyCat的配置復(fù)雜嗎？上手容易么？

?

我們只需要看一個(gè)圖片就行了。你能想象這是它的配置文件么？看了之后我估計(jì)你也沒(méi)有任何使用它的欲望了，很多人在使用之后，是這樣評(píng)價(jià)的：

?

“MyCat這類，碰都不想碰”

?

配置文件如下：

?

?

竟然是一個(gè)XML文件，這個(gè)產(chǎn)品經(jīng)理當(dāng)時(shí)是如何想的？后面也沒(méi)有想著做個(gè)優(yōu)化？

?

問(wèn)題15：最后一個(gè)問(wèn)題，現(xiàn)在做分庫(kù)分表做得好的有哪些？

?

有哪些？一個(gè)都沒(méi)有，這是一條不歸路啊。

?

因?yàn)檎f(shuō)白了，它是一種偽分布式方案，基礎(chǔ)是不好的，上層就做不好，所以永遠(yuǎn)是在補(bǔ)各種坑，走得很累，累人累己。

?

現(xiàn)在可以回過(guò)頭來(lái)想一想，為什么一些很強(qiáng)大知名的公司做的中間件產(chǎn)品，并沒(méi)有做這些事情，比如ProxySQL、Maxscale、MySQL Router等，為什么呢？難道他們的技術(shù)不好？或者是沒(méi)有這樣的需求？

?

我還是覺(jué)得，需求是有的，人與人、業(yè)務(wù)與業(yè)務(wù)的需求，是一樣的，但解決方法可能就不一樣了，他們可能早就認(rèn)為，這是一條錯(cuò)誤的道路，所以就不會(huì)去選擇走，而MyCat這種方案，可能就要回過(guò)頭來(lái)想想未來(lái)的路了。

?

2、互聯(lián)網(wǎng)處理大規(guī)模在線訪問(wèn)數(shù)據(jù)的做法

?

解耦思想充斥著互聯(lián)網(wǎng)技術(shù)棧的方方面面，為什么這樣做？我想應(yīng)該是大家都不想拖泥帶水，也不想牽一發(fā)而動(dòng)全身罷了。而在MySQL數(shù)據(jù)庫(kù)層面，使用了重量級(jí)的中間層之后，你會(huì)發(fā)現(xiàn)，大一統(tǒng)看起來(lái)是很不錯(cuò)，但這樣牽一發(fā)很可能動(dòng)全身，這其實(shí)并不是好事情。

?

MySQL這種數(shù)據(jù)庫(kù)是在互聯(lián)網(wǎng)領(lǐng)域興起并被大規(guī)模使用的，在比如賬務(wù)、訂單、計(jì)費(fèi)等關(guān)鍵業(yè)務(wù)上使用的也不在少數(shù)。

?

在大型互聯(lián)網(wǎng)公司，MySQL的使用一定是分庫(kù)分表的，通過(guò)各種垂直切分和水平切分，把一個(gè)數(shù)據(jù)庫(kù)變成一堆數(shù)據(jù)庫(kù)，也就是所說(shuō)的數(shù)據(jù)庫(kù)集群。但是很少看到在使用的MySQL的時(shí)候會(huì)在上面架設(shè)一層重量級(jí)的所謂分布式的中間層，這樣導(dǎo)致的就是緊耦合了，與互聯(lián)網(wǎng)的高效聯(lián)運(yùn)相違背，互聯(lián)網(wǎng)的數(shù)據(jù)庫(kù)集群都應(yīng)該是物理上離散的，每一個(gè)實(shí)例可以自由的控制和遷移，也就是所謂的解耦。

?

解耦的好處可以讓你自由處理每一個(gè)獨(dú)立的實(shí)例或者集群，方便根據(jù)實(shí)際情況應(yīng)對(duì)業(yè)務(wù)帶來(lái)的變數(shù)，該升級(jí)的升級(jí)，該縮容的縮容，為每一個(gè)業(yè)務(wù)或者每一個(gè)業(yè)務(wù)的數(shù)據(jù)庫(kù)定義不同的維護(hù)等級(jí)，靈活掌握，隨機(jī)而變。

?

解耦的好處可以提升數(shù)據(jù)庫(kù)的絕對(duì)性能，數(shù)據(jù)從業(yè)務(wù)到磁盤(pán)，或者從磁盤(pán)到業(yè)務(wù)，經(jīng)歷的路徑越短，其效率也就越高。很多使用MySQL的做法就是用一個(gè)簡(jiǎn)單的中間層分發(fā)SQL，這樣的中間層功能清晰、結(jié)構(gòu)簡(jiǎn)單、靈活高效，一般不會(huì)損失太多性能，這就像MySQL出品的MySQL Router、MariaDB出品的Maxscale、Percona的ProxySQL，還有國(guó)內(nèi)極數(shù)云舟的Arkproxy，他們的行為，都為選擇使用中間層去實(shí)現(xiàn)數(shù)據(jù)架構(gòu)指明了一個(gè)方向。

?

解耦的好處可以讓你的數(shù)據(jù)庫(kù)只干數(shù)據(jù)庫(kù)最擅長(zhǎng)的事情，它能保證你的數(shù)據(jù)安全存儲(chǔ)，它能保證你的數(shù)據(jù)高效存取，它能保證你數(shù)據(jù)并發(fā)處理，它能保證你的數(shù)據(jù)靈活接入，這還不夠嗎？

?

綜上所述，我們?cè)俅未_信一個(gè)真理，MySQL因簡(jiǎn)單而高效，因高效而流行，不要舍本逐末，聽(tīng)信忽悠，誤入歧途。

?

當(dāng)然如果不想在業(yè)務(wù)層做分庫(kù)分表來(lái)適配MySQL數(shù)據(jù)庫(kù)的架構(gòu)，而想通過(guò)對(duì)業(yè)務(wù)透明的分布式數(shù)據(jù)庫(kù)來(lái)提供業(yè)務(wù)服務(wù)的話，我推薦真正意義的分布式數(shù)據(jù)庫(kù)解決方案，它能解決的是強(qiáng)大的存儲(chǔ)擴(kuò)展能力、分布式運(yùn)算、對(duì)業(yè)務(wù)讀寫(xiě)透明以及友好的故障轉(zhuǎn)移等問(wèn)題，這是它們的優(yōu)勢(shì)，也是它們的初衷。

?

3、真正意義的分布式解決方案

?

真分布式方案，其實(shí)已經(jīng)不用太多說(shuō)了，達(dá)到上面所述的需求即可。并且目前也有比較成熟的方案，比較有代表性的產(chǎn)品有Google的Spanner&F1、以及國(guó)產(chǎn)數(shù)據(jù)庫(kù)SequoiaDB、TiDB等等。

?

對(duì)比之下，這種分布式數(shù)據(jù)庫(kù)對(duì)業(yè)務(wù)無(wú)侵入，MySQL數(shù)據(jù)實(shí)現(xiàn)了云存儲(chǔ)特征，100%兼容MySQL，擴(kuò)展性非常好，天然支持分布式事務(wù)、數(shù)據(jù)節(jié)點(diǎn)及路由節(jié)點(diǎn)延遲非常小，通過(guò)一致性算法來(lái)保證了數(shù)據(jù)的強(qiáng)一致性，如此種種，都是立足于一個(gè)正確的基點(diǎn)之上，來(lái)建立起高樓大廈，勢(shì)必將基于MyCat的偽分布式數(shù)據(jù)庫(kù)解決方案推入無(wú)人問(wèn)津的深淵，直至淘汰與消亡。

?

三、總結(jié)

?

使用MyCat的用戶其實(shí)還是挺多的，現(xiàn)在在了解業(yè)界市場(chǎng)的情況下，我也是比較能理解他們，因?yàn)樾枨笥?#xff0c;但真的是沒(méi)有解決方案，選擇使用，實(shí)則無(wú)奈之舉，畢竟他是開(kāi)源的，罵歸罵，也無(wú)怨言，因?yàn)槊赓M(fèi)嘛，有的用還有什么可言語(yǔ)的呢？我也推薦大家去試用一下，只有知道痛了，才會(huì)感覺(jué)現(xiàn)在有新的方案出現(xiàn)的美好。

?

本文所述的關(guān)于MyCat的一系列問(wèn)題，主要目的是考慮到為了讓業(yè)內(nèi)同學(xué)不要繼續(xù)采坑，所以做了一些總結(jié)，所述內(nèi)容限于本人目前對(duì)MyCat的理解與認(rèn)識(shí)，如果有紕漏或者不足的地方，歡迎指正或者給予補(bǔ)充，感謝。

?

文章來(lái)源于 ：??DBAplus社群? ?微信公眾號(hào)

文章鏈接：https://mp.weixin.qq.com/s/McWCXGE8JsgHAz1V2liFHw?

?

轉(zhuǎn)載于:https://www.cnblogs.com/keme/p/9774093.html

總結(jié)

以上是生活随笔為你收集整理的分享 ： 警惕MySQL运维陷阱：基于MyCat的伪分布式架构的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。