MySQL高可用方式的一些思考

2024-07-24 12:31:54

字體：大中小

來源：轉載

供稿：網友

我在去年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開源社區的影響是深遠的。所以方案可以改進，就如同技術發展一樣。我贊同那句話，沒有最好的方案，只有最合適的方案。

（編輯：武林網）

上一篇：mysql+keepalived 雙主熱備高能用

下一篇：mysql安置出現 conflicts with mysql 的解決辦法