mysql高可用方案MHA介紹

標籤：

mysql高可用方案MHA介紹 概述 MHA是一位日本MySQL大牛用Perl寫的一套MySQL故障切換方案，來保證資料庫系統的高可用.在宕機的時間內（通常10—30秒內），完成故障切換，部署MHA，可避免主從一致性問題，節約購買新伺服器的費用，不影響伺服器效能，易安裝，不改變現有部署。    還支援線上切換，從當前運行master切換到一個新的master上面，只需要很短的時間（0.5-2秒內），此時僅僅阻塞寫操作，並不影響讀操作，便於主機硬體維護。 在有高可用，資料一致性要求的系統上，MHA 提供了有用的功能，幾乎無間斷的滿足維護需要。  優點 1        master自動監控和容錯移轉   在當前已存在的主從複製環境中，MHA可以監控master主機故障，並且故障自動轉移。 即使有一些slave沒有接受新的relay log events，MHA也會從最新的slave自動識別差異的relay log events，並apply差異的event到其他slaves。因此所有的slave都是一致的。MHA秒層級容錯移轉（9-12秒監測到主機故障，任選7秒鐘關閉電源主機避免腦裂，接下來apply差異relay logs，註冊到新的master，通常需要時間10-30秒即total downtime）。另外，在設定檔裡可以配置一個slave優先成為master。因為MHA修複了slave之間的一致性，dba就不用去處理一致性問題。      當遷移新的master之後，並行恢複其他slave。即使有成千上萬的slave,也不會影響恢複master時間，slave也很快完成。       DeNA公司在150+主從環境中用MHA。當其中一個master崩潰，MHA4秒完成容錯移轉，這是主動/被動叢集解決方案無法完成的。 2        互動(手動)master容錯移轉  MHA可以用來只做容錯移轉，而不監測master，MHA只作為容錯移轉的互動。 3        非互動式容錯移轉  非互動容錯移轉也提供（不監控master，自動容錯移轉）。這個特性很有用，特別是你已經安裝了其他軟體監控master。比如，用Pacemaker(Heartbeat)監測master故障和vip接管，用MHA容錯移轉和slave提升。 4        線上切換master到不同主機  在很多情況下，有必要將master轉移到其他主機上（如替換raid控制器，提升master機器硬體等等）。這並不是master崩潰，但是計劃維護必須去做。計劃維護導致downtime，必須儘可能快的恢複。快速的master切換和優雅的阻塞寫操作是必需的，MHA提供了這種方式。優雅的master切換， 0.5-2秒內阻塞寫操作。在很多情況下0.5-2秒的downtime是可以接受的，並且即使不在計劃維護視窗。這意味著當需要更換更快機器，升級高版本時，dba可以很容易採取動作。 5        master crash不會導致主從資料不一致性     當master crash後，MHA自動識別slave間relay logevents的不同，然後應用與不同的slave，最終所有slave都同步。結合通過半同步一起使用，幾乎沒有任何資料丟失。 其他高可用方案 6        MHA部署不影響當前環境設定 MHA最重要的一個設計理念就是儘可能使用簡單。使用與5.0+以上主從環境，其他HA方案需要改變mysql部署設定，MHA不會讓dba做這些部署配置，同步和半同步環境都可以用。啟動/停止/升級/降級/安裝/卸載 MHA都不用改變mysql主從（如啟動/停止）。 當你需要升級MHA到新版本時，不需要停止mysql，僅僅更新HMA版本，然後重新啟動MHAmanger即可。    MHA 支援包含5.0/5/1/5.5(應該也支援5.6，翻譯文檔時MHA開發人員沒更新對於5.6版本)。有些HA方案要求特定的mysql版本（如mysqlcluster，mysql with global transaction id 等）,而且你可能不想僅僅為了MasterHA而遷移應用。很多情況下，公司已經部署了許多傳統的mysql應用，開發或dba不想花太多時間遷移到不同的儲存引擎或新的特性（newer bleeding edge distributions 不知道這個是否該這麼翻譯）。 7        不增加伺服器費用 MHA 包含MHA Manager和MHA node。MHA node運行在每台mysql伺服器上，Manager可以單獨部署一台機器，監控100+以上master，總伺服器數量不會有太大增加。需要注意的是Manager也可以運行在slaves中的一台機器上。 8        效能無影響 當監控master，MHA只是幾秒鐘（預設3秒）發送ping包，不發送大的查詢。主從複製效能不受影響 9        適用任何儲存引擎 Mysql不僅僅適用於事務安全的innodb引擎，在主從中適用的引擎，MHA都可以適用。即使用遺留環境的mysiam引擎，不進行遷移，也可以用MHA。    與其他HA方案比較 Doing everything manuallyMysql replication 是同步或半同步。當master崩潰時，很有可能一些slave還沒有接受最新的relay log events，這意味著每一個slave都相互處在不同的狀態。人為修複一致性問題顯得不再平凡。沒有一致性問題，主從也可能不會啟動（如duplicate key error）。花費1個多小時重新啟動主從複製顯得不同尋常。   Single master and single slave在單一主從情況下，一些slave 落後與其他slave的情況將不會發生。其中一個master崩潰，可以輕鬆的讓應用轉移到一個新的master上面，提供對外服務，故障遷移很簡單。   Master, one candidate master, and multiple slaves雙主多從雙主多從的架構也很常見。主master掛掉，備用master將接替主master提供服務。某些情況配置為多主架構。   M(RW)-----M2(R)                      M(RW), promoted from M2        |                                          |   +----+----+          --(master crash)-->   +-x--+--x-+  S(R)     S2(R)                             S(?)      S(?)                                           (Fromwhich position should S restart replication?) 但是這並不作為master容錯移轉方案。當前master掛掉，剩餘slave不一定接受全部relay log events，修複資料一致性還是問題。   這種架構使用廣泛，但是不是所有人都能深刻理解上述問題。當前master掛掉，slave變得不統一或者slave不能從新的master複製資料。 也許雙master，其中一個master唯讀，每個master都至少有一個slave也許可能解決問題。          M(RW)--M2(R)          |      |        S(R)   S2(R)  Pacemaker + DRBDPecemaker(Heartbeat)+DRBD+Mysql是一個通用方案。但是這個方案也有以下問題 1 費用問題，特別是跑大量主從環境。Pecemaker+DRBD是主動/被動的解決方案，因此需要一台被動伺服器對外不提供任何應用服務。基本的需要四台mysql伺服器，one active master，one passive master，two slaves。 2 宕機時間(downtime)。Pacemaker+DRBD是主備叢集，主master掛掉，備用master啟用。這可能花費長的時間，特別是沒有用innodb plugin。即使用innodb plugin，花費幾分鐘開始在備用master上接受串連也不尋常。另外，因為備用master上資料/檔案快取是空的，恢復，熱身(填充資料到data buffer pool)花費不可忽視的時間。實踐中，需要一台或更多slave提供足夠的讀服務。在熱身時間內，空緩衝導致寫效能降低 3 寫問題下降或一致性問題。為了讓主動/被動叢集真正的工作，每次提交(commit)後，必須重新整理交易記錄(binary log和innodb log)，也就是必須設定innodb-flush-log-at-trx-commit=1,sync-binlog=1。設定sync-binlog=1會降低寫效能，因為fsync()函數被序列化(sync-binlog=1，group commit失效)。大部分案例中，不設定sync-binlog=1.如果沒有設定sync-binlog=1，活動master crash，新的master(先前被動伺服器)可能會丟失一些已經發送到slave的binary log events。假如 master 掛掉，slave A接受到mysqld-bin.000123,位置1500。binlog data重新整理到硬碟的位置在1000，那麼新的master資料也只能mysqld-bin.000123的1000處，然後在啟動時建立一個新的binary log mysqld-bin.000124。如果發生這種情況，slave A不能繼續複製，因為新的master 沒有mysqld-bin.000123位置1500.  4 複雜。對多數人來說，安裝/初始化pacemake和DRBD不是容易的事情。相對於其他案例，初始化DRBD需要重新建立系統磁碟分割也不容易。要求dba在DRBD和linux核心層有足夠的技能。如果dba執行了一個錯誤命令（如執行drbdadm–overwrite-data-of-peer primary 在被動節點），那麼將會損壞活動的資料。重要的是另外一旦硬碟io層出現問題，多數dba處理這種問題不是容易的。 MySQL ClusterMysql cluster是真正的高可用解決方案，但是必須得用NDB儲存引擎。如果你用innodb，將不能發揮mysql cluster叢集優勢。 Semi-Synchronous Replication半同步複製大大降低了binlog event僅僅存在於崩潰master上的這種風險。這非常有用的能避免資料丟失。但是半同步不能解決所有一致性問題，只能保證一個（不是所有）slave接受到master端的commit的binlog events，其他slave也許還沒有接受全部的binlog events。不能apply不同的binlog events 從新的slave到 其他slave上，也不能保證相互一致性 Global Transaction IDGlobalTransaction ID所要達到的目的跟MHA相同，但它覆蓋更多。MHA只是兩級複製，但是global transaction id覆蓋任何層級的複製環境，即使第兩級複製失敗，dba也能覆蓋第三級。Check Google‘sglobal transaction id project for details。

mysql高可用方案MHA介紹