我在去年QCon和Gdevops廣州站的時候，講到MySQL和Oracle的現狀和發展時，簡單總結了下一個常見的使用誤區：把MySQL當Oracle用，或者把Oracle當做MySQL用。
在我們身邊這種情況太多，以至於很多重度依賴Oracle的人覺得MySQL太弱，MySQL的人覺得Oracle的方案擴充套件性不夠好。其實可以從幾個維度來看，我們今天就著重從MySQL的一些技術點來說起吧。
MySQL的高可用其實如果延展開來，可以從三個維度來考慮，應用層，資料庫層，系統層（包含網路層）。假設資料庫層面已經能夠做到最好了，資料層面可以保持資料業務的訪問，從網路層面來說，我們需要DNS的支援能夠滿足兩個層面的高可用，一個是同城機房（或者同機房）的DNS高可用，另外一個是跨機房（跨區域）的DNS高可用，從資料庫的業務訴求和網路規劃來說，使用的DNS是不對外服務的，所以可以理解是local DNS的角色，這樣一來，我們都不需要刻意去維護VIP的切換，網路層或者中介軟體層足夠強大，我們只需要格外關注資料庫服務的可用性和資料一致性就可以了。
如果往上層來看，就是應用層面，其實應用訪問資料庫服務使用域名，他壓根不需要知道對應的IP是什麼，就跟我們訪問谷歌只需要知道是google.com就可以了。如果有了網路層面的高可用，保證一個DNS的生效策略，比如10秒，1分鐘等，那麼應用層需要的改造就是短連線或者是應用重連機制，因為毫無疑問程式端會有一層快取，長連線很容易出現“迷失在過去狀態”的情況。
所以一個較為完整的方案應該是系統層，網路層，資料庫層和應用層來共同配合，才能保證一個基本的高可用方案。
如果要實現更為複雜的高可用，比如已經不侷限於容災，做雙活多活等，其實整個架構的複雜度會高很多。
我就拋磚引玉，來說說MySQL高可用方案的一些想法。
大家知道MHA是MySQL DBA非常喜歡用的高可用方案，因為確實非常經典，我看了下程式碼的實現，邏輯的部分是非常的完善的，很多我們沒有考慮到的點在程式碼層都做了校驗。所以說MHA是一個非常成熟的方案，在大家的各種應用場景中發展壯大起來了。如果是早一些的版本使用MHA就是一個標準動作，大家知道MHA後期也有一些變化，一個是自0.56的版本開始引入了binlog server,在這個基礎上有了0.57的版本，之後在github上就沒有了版本更新。如果大家細細看看0.56和0.57的改進，主要的改動就是在資料完整性上的一個補充，當然這種架構方式對已有的快捷恢復來說會有一定的侵入性。所以我們很多公司用MHA，其實還是沒有用binlog server的。MHA還有一個比較特別的地方就是對於網路異常的處理，其實0.56和0.57是有一些差別的，當然在細節測試的時候，其實碰到有些異常情況比較糾結，好像怎麼解釋都可以，所以以0.56和0.57為分水嶺，對於網路的處理的差異來看，我是更傾向於0.56版本的，所以我們迭代測試了0.56,0.57然後又折回來補充了0.56的場景。
當然這個過程的收穫是比較大的，也妝模作樣的看了下MHA的一些程式碼，理了一下思路。但是我發現一個問題，相信很多朋友都有類似的感覺，那就是MHA是perl寫的，實在是讓很多人感到非常的陌生和彆扭，因為perl語言本身的群體和易讀性上是存在一些落差的，所以我們其實更傾向於用Python來實現這個事情，當然用其他的語言也可以，至少群體要大一些。
其實我在調研MHA的細節時，是打算在年後做MHA的程式碼python化工作的，但是我理了下自己的思路，發現這個事情其實做起來很有技術價值，但是投入和付出的成本落差是很大的，一來改造的難度很大，我得把Perl搞明白，然後用Python重寫一遍或者理解了原來的邏輯，整理出缺點來，重新構建，我想了比較多的細節，對於MHA的缺點等等，這是技術上的投入，很大，而且很有難度，對個人成長是大有幫助的，但是從另外三個角度來說，我覺得可能實踐意義不是很大了，第一是目前的技術方案MHA其實已經沒有明顯的優勢了，第二我改造的版本如果足夠好，公司內怎麼推行，如果跑起來一直不出問題，那麼實踐意義其實不夠大；第三我推廣到社群裡，大家是否能夠接受，因為我面對的不是很多年前的一個狀態，如何保證我寫的足夠好，或者說寫正確了，這不是個拍腦袋的問題，一定是大量的細緻測試才有說服力。
所以很多大公司其實在很早之前就把這個事情做了，當然可能只是不對外而已。當然對於MySQL的高可用，雙活方案其實一直以來大家都有很多的解決方案，或者看起來行得通的經驗。
比如雙主，漏斗形的架構設計，其實在很多公司早期確實是這麼幹的，看起來這個方案沒有特別的難點，但是處理這些臨界點的問題的時候，還是要投入不小的功夫。這個方案我不打算多說，更多是在異常的處理上。
然後來說說MGR，其實完整說來，應該是InnoDB Cluster,我非常看好這個方案，可能很多人對此比較陌生，其實最先大家熟悉的是MGR, 如果把InnoDB Cluster比作三駕馬車，那麼是由MySQL Shell, MySQL Router,MySQL Group Replication三個元件共同組成，其中的核心元件就是MGR了。他的基因是真正的分散式，基於paxos協議。當然從資料架構的角度來說，基於複製的方案，可用性和完整性是有保證的，但是效能上是要衰減的，所以MGR乾脆就限制了節點個數。這個和傳統關係型資料庫的節點的概念就不同了。
如果你留意下Windows安裝版本的話，你會發現InnoDB Cluster已經打包成為了預設的安裝服務了，裡面提供了全面的安裝配置過程，可以參考如下的連結：
一種快速安裝InnoDB Cluster的方法
有很多人說InnoDB Cluster的方案要落入生產實踐還有待考驗，這個絕對沒錯，但是從方向上來說，他已經對早期的方案是一個很好的補充和改進了。他的三大元件，其實MySQL Router目前是一個短板，但是一旦這個短板不成為瓶頸，有了sharding等功能，那對於MySQL開源社群的影響是深遠的。所以方案可以改進，就如同技術發展一樣。我贊同那句話，沒有最好的方案，只有最合適的方案。