警惕MySQL運維陷阱：基於MyCat的偽分散式架構
分散式資料庫已經進入了全面快速發展階段。這種發展是與時俱進的，與人的需求分不開，因為現在資訊時代的高速發展，導致資料量和交易量越來越大。這種現象首先導致的就是儲存瓶頸，因為SQL/">MySQL資料庫實質上還是一個單機版本的資料庫，而只要是單機，就必然會遇到的一個問題就是儲存問題，因為儲存是硬需求，而CPU和記憶體如果不夠的話，只是效能不好，並不會直接否定方案或者架構。
儲存問題的解決，其實我們每一家公司或者個人，都一直在努力著。解決方案大概有三個方面：
1、增大磁碟
這種方式應該是最直接、最簡單的方案了，因為磁碟空間不足了，當然加磁碟是手到病除，比如現在是800G，可以增加到2T，這是沒問題的；如果現在已經達到了2T，當然，還是可以增加到5T的盤。但實際上，這個時候可能DBA就要捏把汗了，這麼大資料量的MySQL例項，如何運維？如果資料壞了，如何恢復呢？時間成本呢？
5T的資料量，已經非常嚇人了，估計在業內各大公司，沒有DBA會希望自己運維的MySQL例項達到這個量級吧？
其實我個人認為，這個已經是不能接受的量了，最合適的是保持在1T以下，超過就要想辦法了。
當然，資料量不宜達到這個大小的原因，可能會有人考慮到這是效能的問題，其實不然，或者效能問題很小。因為InnoDB採用的是B+樹的儲存方案，小表最壞情況下沒有查到資料是要找3層，也就是3個頁面的IO，而大表需要的是4個頁面的IO，影響不大。
2、資料壓縮
為了減少資料對磁碟空間的佔用，我們通常也會將資料做壓縮處理，通過一個語句即可搞定，是InnoDB原生支援的一種方式。一般情況下，會將資料佔用減少到原來的三分之一到一半不等，效果還是足夠明顯的，不過這樣處理之後的資料，在效能上會有所下降，對於響應要求比較高的業務，可能需要謹慎考慮一下。
但這種方式還是治標不治本，在資料量繼續增長的情況下，過段時間之後，依然會面臨相同的問題，這種情況下，就不能繼續使用這種方式來實現了。
3、資料分片
資料分片的解決方案，現在業內用得 也 很多，這種方案已經超出了MySQL本身，包括HBase、Redis等也都在使用這種方案，應該說這種方案是最具擴充套件性的，並且可以稱得上是無限擴充套件。而上面兩種方案，根本談不上擴充套件性。所以這種方案在業內成為主流，並且這種方案才能稱得上是分散式儲存，具體的實現也層出不窮。 當然，存在優秀的分散式解決方案，也存在一些“偽”分散式方案了。
一、分散式解決方案需求
1、擴充套件性
使用分散式，其實最主要的就是擴充套件性，如果空間不足了，可以很方便容易的擴充套件節點個數，並且將資料做新的平衡處理。這個過程要不影響業務使用，對業務透明。
2、支援事務
分散式資料庫，對於業務本身，使用方面與單機區別不大，也就是對業務透明，因為使用MySQL是支援事務的，那麼MySQL變身為分散式之後，事務特性還是不能少的，所以整體上看來，還是要支援分散式事務。
3、SQL語句無限制
業務需求的多樣性，導致在SQL需求上面都是比較廣泛的，針對業務的透明性，如果某些SQL語句不支援，那這樣導致的問題是，一方面限制了業務程式的功能和效能；另一方面導致業務程式與“分散式資料庫”的捆綁問題。
4、效能足夠好
使用分散式資料庫，其實基本上是對效能的要求比較低的業務才會這樣選擇，即使是這樣，還是效能越高，越多人才會選擇這樣的分散式資料庫。
5、元資料變更透明性
元資料變更，在任何資料庫中都是存在的。在單點情況下，改表操作我們有多種友好的方法來實現。但到了分散式環境下，可能這種操作就成為了問題，因為資料的分片導致了元資料的變更需要多點修改，進而很多問題就來了，比如原子性、資料可見性、正確性等等，所以這是最基本的問題。
6、底層資料庫的高可用性
話說經濟基礎決定上層建築，在分散式資料庫中也是一樣的，如果底層資料庫的不穩定，或者資料複製延遲，亦或出現數據不一致的問題，則上層應用的訪問正確性就沒法保證，所以底層資料庫最基本的就是保證資料一致性（高可用）。
二、流行分散式資料庫解決方案
1、中介軟體分庫分表（偽分散式）
在MySQL界，一個存在很久的話題，就是“哪個中介軟體實現的分庫分表方案比較好？”
當然對於同一個問題，不同人有不同的理解，也都具有兩面性的特徵，有人說好，也有人說不好，我們首先看一下這種方案是如何實現的。
MyCat的實現架構大概如上圖所示，其實如果只看圖的話，這樣的架構真是完美無缺，自動分片、自動聚合、分佈均衡都實現的非常好。
但事實並非如此。
我們可以通過問答的方式，一步步認清楚這種方式的核心問題：
問題1：MyCat如何知道資料分片原理，或者說是如何決定路由路徑的？
這個問題，在圖上面是看不出來的。
MyCat是如何定義或者決定一條SQL語句的執行方式，或者如何決定去哪裡取資料及寫入到哪裡的？解決這樣的問題是需要某一個地方來儲存的，它的做法是——schema.xml配置檔案，竟然用配置檔案來搞定。
那這樣問題就多了，修改分庫分表規則之後，如何保證配置與資料同步更新？即使不使用schema.xml配置檔案，而是用資料庫儲存，那配置規則的變更與資料節節點中資料的遷移，也是沒辦法保證統一的，勢必會對業務造成影響。
問題2： 如果需要擴充套件節點了，並且需要做rebalance，如何來做？
很多使用者，基本都是重新準備一套叢集，或者先把資料一點點手動匯出匯入，導到目標節點之後，然後去手動修改schema.xml配置檔案，然後做一次reload操作，這樣就實現了重新路由，但這樣同樣會導致上面的結果。
並且這個過程，需要處理好多資料，處理完成之後各種檢查，並且佔用空間需要兩倍，這樣折騰，一個DBA只要幹一次，可能就有辭職的衝動。
問題3： 全域性表是什麼東西？
MyCat支援一個所謂的全域性表，用來解決跨節點資料聚合的問題。實現方法是在每一個分片上面都建立這樣的全域性表，它的定義是不怎麼修改，查詢比較頻繁表可以定義為全域性表，這樣的話在每一個分片節點上，只要用到這個表，就可以實現本地查詢連線等操作。
這樣的確是可以解決部分問題，但問題是如果分片多的話（假如分片100個），如何保證資料一致性？這麼多節點的XA事務影響是什麼？如果出現不一致或者訪問錯誤，引起的問題就是資料結果錯誤，這樣的結果肯定不是業務想要看到的吧？這還不是最關鍵的，一個數據庫叢集，搞這麼一個特殊處理的東西是何道理？
問題4： MyCat究竟做了什麼事情？
作為一箇中間層，本職工作應該是接收客戶端的SQL請求，通過語法分析，根據讀寫原則確定一個叢集中一個讀寫節點即可，然後就等著結果集的返回。 對於結果集本身，中間層並不需要去關心，只需要將結果集（或者異常）原原本本發回給客戶端即可。
而MyCat做的事情遠比這個多，在語法分析之後，再做語義分析，拿到對應資料庫表結構，同時判斷這個表的分發路由規則，再找到語句中的資料及涉及到的列，再決定路由到哪個分片中。 如果在分發時路由規則配置錯誤或者程式計算錯誤，會導致整個語句的結果出現不可預知的問題。
請問這前半部分，是一箇中間層應該做的事情麼？竟然還要關心語句中涉及到的表結構、主鍵、資料等資訊，這其實都是資料庫要做的事情啊！實則是越俎代庖。
再請問，所做的這些事情，能比一個專業資料庫做得更好麼？
咱再看後半部分，等收到結果集之後，MyCat為了處理一些結果集的聚合計算，需要把各個節點本來已經封裝好的結果集（二進位制MySQL協議流資料），解析出來，然後通過需要計算出來（這個計算有可能非常慢，並且不是所有的都可以搞定），計算完成之後，再打包成MySQL協議流資料，傳給客戶端。
請問這樣的中間層，做了這麼多事情，效能如何保證？而本身這些聚合計算Order By、Group By的處理，本身是資料庫的事情，實則還是越俎代庖。
問題5： 通過SQL語句的變換，實現分散式是不是有點困難？
MyCat這種中間層，代表了宣稱分散式資料庫的一類使用方式，但這種實現方法實際上都是通過在SQL語句上做文章，從客戶端拿到的是SQL語句，給後端資料庫的也是SQL語句，但這兩個SQL語句是經過變換的。
當然這種方法也只能這樣，因為後端資料庫只接收SQL語句。試問，一個複雜的SQL語句查詢操作，通過SQL變換或重寫，就能實現對不同分片資料庫的分散式查詢？
想想就清楚了，雖然SQL語句通用靈活，但可擴充套件性或者重寫的邏輯還是有點複雜的吧？當然了，有人可能會說，我們有兜底的啊，大不了把這個語句就改一下庫名錶名然後其它保持不變分給每一個節點去執行，這樣總沒問題吧，是的，你說的沒錯。
問題6： 在同一個事務中要修改不同節點的資料是如何處理的？
這個問題就是我們通常所說的分散式事務了。究竟是怎麼回事呢？MyCat下面對的是MySQL Server，也就是說MyCat只能用SQL語句與MySQL Server交流，這樣就是侷限於MySQL的SQL語句的功能了。
那在分散式實現上面，MySQL XA本身有多少人用？MyCat如果實現一個跨節點的資料更新，不用MySQL XA，還能用其它什麼？
別無他選。本身依賴一個沒有太多人用、並且可能存在很多問題，包括效能、Bug的功能，這樣上層MyCat乃至應用程式的可靠性如何保證？
當然基於這些問題，有些方案選擇不用XA，如果某些節點失敗了，選擇忽略不解決，這當然也可以，妥協嘛——不需要底線的。
問題7： MyCat後端資料庫的架構是什麼，如何保證穩定可靠高可用？
這個據某些文章宣傳說，之前可以選擇主從複製，現在可以選擇Galera Cluster，或者也可以選擇更新的MGR。
當然不得不說，從前到後，可能確實保證了更好的可靠性，但有一個很大的問題是，Galera的門檻比較高，遇到問題的話，很少人能解決掉。再到MGR，本身還得等，能用還要比較長的時間，這問題還是要回到主從複製，這是老問題了，主從複製的一致性很難保證，MyCat如果通過讀寫分離策略將讀打到從上面，而這個正好有延遲，這樣產生的後果可能是整個應用程式的計算結果是錯誤的。
當然可以說有延遲檢查，那問題是，延遲檢查的話，是不是還有一個引數可以配置呢？如果延遲超過100秒的話就去查主庫？
沒錯，不過100秒難道就不是延遲了？那可以設定為0，看到的0，你以為真的是0？其實還是主從複製的劣根性。所以問題還是回到了起點，經濟基礎決定上層建築，基礎不好，上層如何是好？
問題8： 分片多了的情況下，效能是如何保證損失最小的？
這個問題，我並不知道MyCat有沒有做過優化，比如10個分片，如果一個語句的執行會涉及到這十個分片，那在每個分片上重寫語句之後，就要分別在這十個分片上執行對應的語句了。
執行時是序列，還是並行？序列的話，效能必然會下降10倍以上，所以做得好點的話，就是並行了，但並行的實現方法是，在MyCat這個連線上面，建立10個執行緒，去處理這十個節點的執行情況。那這樣的連線多了，MyCat產生的對系統的衝擊就非常大了，效能還是不行。
當然也可以說，這裡做了連線池，沒錯，是可以的，但MyCat是這樣做的麼？這樣做了效能又如何呢？如果有一個超時，整個訪問就失敗了。
問題9： 配置檔案或者配置庫出問題，整個叢集會出現什麼情況？
前面已經說了，MyCat用的是schema.xml來配置的分庫分表策略，這是一個配置檔案，MyCat本身的高可用，如果配置多套的話，他們的同步問題，是如何解決的？如果沒有同步（或者同步出問題，或者延遲等），某一個MyCat掛了，業務切換到其它的MyCat時，此時的情況就是：故障……故障……
因為資料都亂了。
有可能造成的問題是，寫入了錯誤的位置，進而導致整個叢集的資料被寫壞。感覺比直接被刪了還嚴重。
同樣的問題，感覺MyCat可能會優化這點，也許會改為將其集中儲存在某一個數據庫中，這樣集中管理的話就不需要同步了，想法是好的，但這相當於是把雞蛋放在一個籃子裡面了，如果這個配置庫出問題了，業務何去何從？
問題10： DDL如何進行？
這個問題也許是每個人都關心的事情了，MyCat把資料都分而不相關的分片MySQL節點了，這樣很多在單點上的改表策略都不能用了，而DDL又是一個必須要保證每個節點同時完成的事情，那在分散式上面是如何保證的呢？
根據我的調研，好像現在使用MyCat的人，都是通過“同一時刻啟動在每一個節點上更新表結構”這樣的方法來做的，當然還得選擇是半夜，當然我個人覺得也是可行的，因為畢竟已經使用了它，而沒有更好的辦法來解決這個問題。
當然咱再說後果，如果做不到無縫原子修改，那對業務的影響不是一星半點，可能會有很多SQL會報表不存在的問題。如果一個語句和另一個語句修改完成時間相差比較多的話，兩個相減的時間就是故障時間了。
問題11： 據我調研，MyCat還實現了自動故障切換的功能，請問這個靠譜麼？
我們現在討論的是分散式架構方案，而這個問題講的情況是，某一個MyCat發現了後端資料庫連不上了，會自動切換的功能。這就非常明顯了，我們要的是分散式，某“一個”MyCat節點認為的問題就真的是它所認為的嗎？
也就是說，一個節點並不能保證判斷的或者看到的現象是真實的，那這種情況下就存在誤切換的情況，而如果其它中間層節點還不知道這個情況，或者未及時收到切換的訊息，就出現了多點寫入的問題，挺可怕的。
這不是自相矛盾嗎？
我們要的是分散式，結果又存在“獨斷”的環節，可靠性又下降了不少。關於分散式監控切換的問題，因為在去哪兒用的mysql-sentinel對Galera Cluster做的監控，我對這點深有感觸，所以不得不在這裡講一下。
問題12： 在MyCat上面備份是如何做的？能做到恢復一個快照嗎？
說起備份，做為資料庫使用者，應該沒有一個不清楚，沒有一個人會覺得不重要吧？當然，重要是重要，但這種事情屬於重要不緊急的工作，但沒有是不行的，這個連公司內審這一關都過不了，也許我們每一個人都不會希望能用到它。
言歸正傳，這麼重要的備份工作，在MyCat上又是什麼情況呢？
可能瞭解一些基本原理的人都比較清楚，Xtrabackup、mysqldump等也都是可以用的，但備份完了之後可能心裡還是感覺沒底，因為這樣的工具，只能對一個MySQL節點做備份。如果分10個分片（10個MySQL節點）的話，可以通過備份十次即可完成，但需要注意的是，備份了十次產生了十個備份集，而並不是一個備份集，這十個備份集之間是完完全全沒有關係的，此時我可能就提出一個比較極端的問題來：
如果哪天（當然我們都不希望有這樣的一天），整個機房掛了，當然假如“幸運”的是，有備份，那在這種情況下，如何恢復一個可用的資料一致及完整的叢集快照呢？
這個時候可能會有人很快地說，將十個備份集都恢復了啟動了即可。
但問題是這十個沒有關係，備份時間又不是同一時刻完成的，同一個表的十個分片，最新資料有的是8點的，有的是9點的，或者有的甚至是昨天的。這樣恢復出來的表，能用麼？基於這樣的表產生的查詢結果，靠譜麼？可想而知。
當然可能也有人會說，我們的資料不需要一致快照，或者更有甚者只需要備份元資料路由表或者配置檔案即可，那這樣就沒問題了，如果MyCat只是定位於用來儲存Zabbix監控資料或者日誌資料，可以丟失不要的資料、一文不值的資料，那我覺得沒毛病。
或許有人還會說，我們的機房不會掛，或者我們的儲存本來就是跨機房的，掛了的話直接切到另外的機房就行了。那此時又有問題了，如果切換的時候，有複製延遲，丟失了部分資料，那整個叢集又會出問題。因為只要有一個分片的資料出問題，整個叢集就有問題了。
或者另一個問題就是，假設你的機房真的不會掛，但我們經常會遇到的需求是，我要取前幾天某時刻的資料，那此時還是需要通過備份然後恢復一個快照，這個時候還有何話可說，你告訴我究竟如何做到？
可能還會有人有疑問，他會說我們是邏輯備份啊，這樣備份出來的是整個庫或者表的一致性快照，這不就解決問題了麼？
我很同意這位同學的看法，說得對極了，是可以很完美地解決一致性問題，但只要熟悉一點點MySQL的人都知道，類似mysqldump這樣的邏輯備份工具，是何其慢？現在都用分散式儲存了，那肯定是資料量非常大，這個時候還在使用這樣的邏輯備份？你是想幹哈？即使備份完成了，那有沒有試過邏輯資料的恢復？幾個G的資料要恢復多久，你算過沒有？想想都頭疼，一條不歸路……
問題13： 如果已經在使用MyCat了，發現它的風險確實太大了，我如何能下掉呢？
這個問題非常好，說明你已經在思考做為一個數據負責人，如何保證資料的可靠性和避免風險的問題了。MyCat風險確實高，但如果已經上了“賊船”並且想下掉的話，此時我可能想問一下（做一回事後諸葛亮），上這個架構的時候為什麼不多考慮一下呢？公司的資料就是金錢，你這樣想上就上，想下就下，來回折騰，能升值麼？萬一資料寫亂了，這個時候可沒有人賠你錢，還不如上雲呢。
不過既然上了，那咱就聊聊如何下掉的問題，我目前感覺最靠譜最穩妥的辦法，貌似只有一個，步驟如下：
第1步， 先停業務，將所有的寫業務都停止（也不用找深夜時間了，因為12小時根本搞不完）。
第2步， 通過上面所講的mysqldump做邏輯備份，將所有的庫匯出來，生成.sql檔案。
第3步， 然後找一個靠譜的MySQL架構（真正的分散式資料庫，或者磁碟足夠大的話可以不採用分散式，採用Share Nothing的方案即可，也許你需要的並不是分散式，只是被忽悠了），將.sql檔案匯入進去。
第4步， 再後就將讀業務遷移到新的資料庫架構上面去。
第5步， 將寫業務也遷移到新的資料庫架構上面去，然後啟動他們，這個時候應該是可以提供正常的資料庫服務了。
我們可以注意一下這個過程，從第1步，到第5步，需要多少時間？這個當然是硬時間，是要移動資料的，邏輯備份和恢復都那麼慢，我覺得時間的單位可以用天來統計了。
這個時候負責人就可以想想，我用MyCat是圖什麼啊，業務的免戰牌掛了好幾天，只是為了彌補當年的一個錯誤決定，追悔莫及。
當然也許有些人也會有其它辦法，但因為各個分片都是相互獨立的，還是存在上面的所說的在不停止業務的情況下的“一致性快照”的問題。
最後我想說的是，對公司的資料，一定要慎之又慎，要時刻保持負責的態度，折騰資料真的不能升值啊。
問題14： MyCat的配置複雜嗎？上手容易麼？
我們只需要看一個圖片就行了。你能想象這是它的配置檔案麼？看了之後我估計你也沒有任何使用它的慾望了，很多人在使用之後，是這樣評價的：
“MyCat這類，碰都不想碰”
配置檔案如下：
竟然是一個XML檔案，這個產品經理當時是如何想的？後面也沒有想著做個優化？
問題15： 最後一個問題，現在做分庫分表做得好的有哪些？
有哪些？一個都沒有，這是一條不歸路啊。
因為說白了，它是一種偽分散式方案，基礎是不好的，上層就做不好，所以永遠是在補各種坑，走得很累，累人累己。
現在可以回過頭來想一想，為什麼一些很強大知名的公司做的中介軟體產品，並沒有做這些事情，比如ProxySQL、Maxscale、MySQL Router等，為什麼呢？難道他們的技術不好？或者是沒有這樣的需求？
我還是覺得，需求是有的，人與人、業務與業務的需求，是一樣的，但解決方法可能就不一樣了，他們可能早就認為，這是一條錯誤的道路，所以就不會去選擇走，而MyCat這種方案，可能就要回過頭來想想未來的路了。
2、網際網路處理大規模線上訪問資料的做法
解耦思想充斥著網際網路技術棧的方方面面，為什麼這樣做？我想應該是大家都不想拖泥帶水，也不想牽一髮而動全身罷了。而在MySQL資料庫層面，使用了重量級的中間層之後，你會發現，大一統看起來是很不錯，但這樣牽一髮很可能動全身，這其實並不是好事情。
MySQL這種資料庫是在網際網路領域興起並被大規模使用的，在比如賬務、訂單、計費等關鍵業務上使用的也不在少數。
在大型網際網路公司，MySQL的使用一定是分庫分表的，通過各種垂直切分和水平切分，把一個數據庫變成一堆資料庫，也就是所說的資料庫叢集。但是很少看到在使用的MySQL的時候會在上面架設一層重量級的所謂分散式的中間層，這樣導致的就是緊耦合了，與網際網路的高效聯運相違背，網際網路的資料庫叢集都應該是物理上離散的，每一個例項可以自由的控制和遷移，也就是所謂的解耦。
解耦的好處可以讓你自由處理每一個獨立的例項或者叢集，方便根據實際情況應對業務帶來的變數，該升級的升級，該縮容的縮容，為每一個業務或者每一個業務的資料庫定義不同的維護等級，靈活掌握，隨機而變。
解耦的好處可以提升資料庫的絕對效能，資料從業務到磁碟，或者從磁碟到業務，經歷的路徑越短，其效率也就越高。很多使用MySQL的做法就是用一個簡單的中間層分發SQL，這樣的中間層功能清晰、結構簡單、靈活高效，一般不會損失太多效能，這就像MySQL出品的MySQL Router、MariaDB出品的Maxscale、Percona的ProxySQL，還有國內極數雲舟的Arkproxy，他們的行為，都為選擇使用中間層去實現資料架構指明瞭一個方向。
解耦的好處可以讓你的資料庫只幹資料庫最擅長的事情，它能保證你的資料安全儲存，它能保證你的資料高效存取，它能保證你資料併發處理，它能保證你的資料靈活接入，這還不夠嗎？
綜上所述，我們再次確信一個真理，MySQL因簡單而高效，因高效而流行，不要捨本逐末，聽信忽悠，誤入歧途。
當然如果不想在業務層做分庫分表來適配MySQL資料庫的架構，而想通過對業務透明的分散式資料庫來提供業務服務的話，我推薦真正意義的分散式資料庫解決方案，它能解決的是強大的儲存擴充套件能力、分散式運算、對業務讀寫透明以及友好的故障轉移等問題，這是它們的優勢，也是它們的初衷。
3、真正意義的分散式解決方案
真分散式方案，其實已經不用太多說了，達到上面所述的需求即可。並且目前也有比較成熟的方案，比較有代表性的產品有Google的Spanner&F1、以及國產資料庫SequoiaDB、TiDB等等。
對比之下，這種分散式資料庫對業務無侵入，MySQL資料實現了雲端儲存特徵，100%相容MySQL，擴充套件性非常好，天然支援分散式事務、資料節點及路由節點延遲非常小，通過一致性演算法來保證了資料的強一致性，如此種種，都是立足於一個正確的基點之上，來建立起高樓大廈，勢必將基於MyCat的偽分散式資料庫解決方案推入無人問津的深淵，直至淘汰與消亡。
三、總結
使用MyCat的使用者其實還是挺多的，現在在瞭解業界市場的情況下，我也是比較能理解他們，因為需求有，但真的是沒有解決方案，選擇使用，實則無奈之舉，畢竟他是開源的，罵歸罵，也無怨言，因為免費嘛，有的用還有什麼可言語的呢？我也推薦大家去試用一下，只有知道痛了，才會感覺現在有新的方案出現的美好。
本文所述的關於MyCat的一系列問題，主要目的是考慮到為了讓業內同學不要繼續採坑，所以做了一些總結，所述內容限於本人目前對MyCat的理解與認識，如果有紕漏或者不足的地方，歡迎指正或者給予補充，感謝。
作者：王竹峰
來源：開源資料庫論壇ODF訂閱號（ID： odf-pub ）
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]