分佈式數據存儲 - MySQL主從複製高可用方案

   前面幾篇文章說道MySQL數據庫的高可用方案主從複製、主從複製的延遲產生緣由、延遲檢測及延遲解決方案(並未從根本上解決)，這種主從複製方案保證數據的冗餘的同時能夠作讀寫分離來分擔系統壓力可是並不是是高可用方案，由於主從節點中主節點仍然是單點的，一旦主節點宕機會致使應用中寫失敗。雙主複製雖然很好的避免主節點的單點故障，可是未提供統一訪問入口來實現負載均衡，若是其中master宕掉的話須要手動切換到另一個master，而不能自動進行切換。本篇文章就來剖析主從複製的高可用。

1、基礎概念介紹                                                                                            

• Keepalived/heartbeat

       是一個基於VRRP（虛擬路由冗餘協議）可用來實現服務高可用性的軟件方案，避免出現單點故障。Keepalived通常用來實現輕量級高可用性，且不須要共享存儲，通常用於兩個節點之間，常見有LVS+Keepalived、Nginx+Keepalived組合。

• MHA/MMM

       MHA是一套MySQL故障切換方案，來保證數據庫系統的高可用。在宕機的時間內（一般10—30秒內），完成故障切換，部署MHA，可避免主從一致性問題，易安裝，不改變現有部署。 還支持在線切換，從當前運行master切換到一個新的master上面，只須要很短的時間（0.5-2秒內），此時僅僅阻塞寫操做，並不影響讀操做，便於主機硬件維護。 在有高可用，數據一致性要求的系統上，MHA 提供了有用的功能，幾乎無間斷的知足維護須要。

• LVS

      (Linux Virtual Server)是一個高可用性虛擬的服務器集羣系統。其主要用於多服務器的負載均衡，做用於網絡層。LVS構建的服務器集羣系統中，前端的負載均衡層被稱爲Director Server；後端提供服務的服務器組層被稱爲Real Server。

      LVS有三種工做模式，分別是DR（Direct Routing 直接路由）、TUN(Tunneling IP隧道）、NAT（Network Address Translation 網絡地址轉換）。其中TUN模式可以支持更多的Real Server，但須要全部服務器支持IP隧道協議；DR也能夠支持至關的Real Server，但須要保證Director Server虛擬網卡與物理網卡在同一網段；NAT擴展性有限，沒法支持更多的Real Server，由於全部的請求包和應答包都須要Director Server進行解析再生，影響效率。 同時，LVS負載均衡有10中調度算法，分別是rr、wrr、lc、wlc、lblc、lblcr、dh、sh、sed、nq。

2、基於主從複製的高可用方案                                                                           

一、雙節點主從 + keepalived/heartbeat

    兩個節點能夠採用簡單的一主一從模式，或者雙主模式，而且放置於同一個VLAN中，在master節點發生故障後，利用keepalived/heartbeat的高可用機制實現快速切換到slave節點。

 

注意事項：

• 採用keepalived做爲高可用方案時，兩個節點最好都設置成BACKUP模式，避免由於意外狀況下（好比腦裂）相互搶佔致使往兩個節點寫入相同數據而引起衝突；
• 把兩個節點的auto_increment_increment（自增起始值）和auto_increment_offset（自增步長）設成不一樣值。其目的是爲了不master節點意外宕機時，可能會有部分binlog未能及時複製到slave上被應用，從而會致使slave新寫入數據的自增值和原先master上衝突了，所以一開始就使其錯開；固然了，若是有合適的容錯機制能解決主從自增ID衝突的話，也能夠不這麼作；
• slave節點服務器配置不要太差，不然更容易致使複製延遲。做爲熱備節點的slave服務器，硬件配置不能低於master節點；
• 若是對延遲問題很敏感的話，可考慮使用MariaDB分支版本，或者直接上線MySQL 5.7最新版本，利用多線程複製的方式能夠很大程度下降複製延遲；
• 對複製延遲特別敏感的另外一個備選方案，是採用semi sync replication（就是所謂的半同步複製）或者後面會提到的PXC方案，基本上無延遲，不過事務併發性能會有不小程度的損失，須要綜合評估再決定；
• keepalived的檢測機制須要適當完善，不能僅僅只是檢查mysqld進程是否存活，或者MySQL服務端口是否可通，還應該進一步作數據寫入或者運算的探測，判斷響應時間，若是超過設定的閾值，就能夠啓動切換機制；
• keepalived最終肯定進行切換時，還須要判斷slave的延遲程度。須要事先定好規則，以便決定在延遲狀況下，採起直接切換或等待何種策略。直接切換可能由於複製延遲有些數據沒法查詢到而重複寫入；
• keepalived或heartbeat自身都沒法解決腦裂的問題，所以在進行服務異常判斷時，能夠調整判斷腳本，經過對第三方節點補充檢測來決定是否進行切換，可下降腦裂問題產生的風險。

二、多節點主從+MHA/MMM

    多節點主從，能夠採用一主多從，或者雙主多從的模式。這種模式下，能夠採用MHA或MMM來管理整個集羣，目前MHA應用的最多，優先推薦MHA，最新的MHA也已支持MySQL 5.6的GTID模式了。

MHA架構：

1）Node

   MHA是基於MySQL Replication環境的，在該環境中，無論是Master角色，仍是Slave角色，都稱爲Node，是被監控管理的對象節點。Node服務器上須要安裝MHA Node包。

2）Manager

   Manager爲MHA架構中的管理者，建議部署在一臺獨立的服務器上，固然也可部署在某個Slave上，但該Slave永遠不要被選擇成爲新的Master，不然故障切換後的MHA架構就失去了高可用性。Manager服務器須要安裝MHA Manager包，並完善一個主配置文件。一個Manager可管理多套MySQL Replication環境。

MHA工做原理：

    MHA的目的在於維持MySQL Replication中Master庫的高可用性，其最大特色是能夠修復多個Slave之間的差別日誌，最終使全部Slave保持數據一致，而後從中選擇一個充當新的Master，並將其它Slave指向它。

基本工做流程大體以下：

1） Manager按期監控Master，監控時間間隔由參數ping_interval決定，缺省爲3秒鐘一次；可利用其自身的監控功能，也可調用第三方軟件來監控；MHA自身提供了兩種監控方式：SELECT（執行SELECT 1）和CONNECT（建立鏈接/斷開鏈接），因爲參數ping_type決定，缺省爲SELECT方式。

2） 當監測到Master故障時，調用SSH腳本對全部Node執行一次檢查，包括以下幾個方面：

• MySQL實例是否能夠鏈接；
• Master服務器是否能夠SSH連通；
• 檢查SQL Thread的狀態；
• 檢查哪些Server死掉了，哪些Server是活動的，以及活動的Slave實例；
• 檢查Slave實例的配置及複製過濾規則；
• 最後退出監控腳本並返回表明特殊意義代碼。

3） 開始Master故障切換，包括以下幾個子階段：

• 1: Configuration Check Phase

        在這個階段，若某個Slave實例的SQL Thread中止了，則會自動啓動它；並再次確認活動的Servers及Slaves。

• 2: Dead Master Shutdown Phase

        在這個階段，首先調用master_ip_failover_script，若HA是基於VIP實現的，則關閉VIP，如果基於目錄數據庫實現的，則修改映射記錄。而後調用shutdown_script腳本強制關閉主機，以免服務重啓時，發生腦裂。

• 3: Master Recovery Phase

        又包括以下3個子階段：

  3.1: Getting Latest Slaves Phase

             檢查各個Slave，獲取最近的和最舊的binary log file和position，並檢查各個Slave成爲Master的優先級，依賴於candidate_master、no_master、[server_xxx]順序、binary log差別量等因素。

  3.2: Saving Dead Master's Binlog Phase

            若dead master所在服務器依然能夠經過SSH連通，則提取dead master的binary log，提取日誌的起點就是上一步獲取的最新的binary log file和position，直到最後一條事件日誌，並在dead master本地的工做目錄（由參數remote_workdir決定）中建立文件保存這些提取到的日誌，而後將該文件拷貝到Manager服務器的工做目錄下（由參數manager_workdir決定）。固然，若dead master系統就沒法鏈接，也就不存在差別的binary log了。另外，MHA還要對各個Slave節點進行健康檢查，主要是SSH連通性。

  3.3: Determining New Master Phase

            接下來調用apply_diff_relay_logs命令恢復Slave的差別日誌，這個差別日誌指的是各個Slave之間的relay log。恢復完成後，全部的Slave數據是一致的，此時就能夠根據優先級選擇New Master了。

  3.4: New Master Diff Log Generation Phase

            這裏是生成dead master和new master之間的差別日誌，即將Phase 3.2保存的binary log拷貝到New Master的工做目錄中（remote_workdir）。

  3.5: Master Log Apply Phase

           將上一步拷貝的差別日誌恢復到New Master上，若發生錯誤，也可手動恢復。而後獲取New Master的binlog name和position，以便其它Slave從這個新的binlog name和position開始複製。最後會開啓New Master的寫權限，即將read_only參數設置爲0。

• 4: Slaves Recovery Phase

 4.1: Starting Parallel Slave Diff Log Generation Phase

      生成Slave與New Slave之間的差別日誌，並將該日誌拷貝到各Slave的工做目錄下，這部分日誌dead master和new master之間差別的那部分日誌，由於各個Slave在 3.3階段已經同步了。

 4.2: Starting Parallel Slave Log Apply Phase

      在各個Slave上應用這部分差別日誌，而後經過CHANGE MASTER TO命令將這些Slave指向新的New Master，最後開始複製(start slave)。

• 5: New master cleanup phase

        清理New Master其實就是重置slave info，即取消原來的Slave信息。

至此整個Master故障切換過程完成。

簡單的說，工做原理：

從宕機崩潰的master保存二進制日誌事件（binlog events）；

識別含有最新更新的slave；

應用差別的中繼日誌（relay log）到其餘的slave；

應用從master保存的二進制日誌事件（binlog events）；

提高一個slave爲新的master；

使其餘的slave鏈接新的master進行復制；

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也很快完成。當其中一個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，僅僅更新MHA版本，而後從新啓動MHAmanger便可。MHA 支持包含5.0/5/1/5.5/5.6。有些HA方案要求特定的mysql版本（如mysqlcluster，mysql withglobal transaction id 等）,並且你可能不想僅僅爲了MasterHA而遷移應用。
7）不額外增長服務器
    MHA 包含MHA Manager和MHA node。MHA node運行在每臺mysql服務器上，Manager能夠單獨部署一臺機器，監控100+以上master，總服務器數量不會有太大增長。須要注意的是Manager也能夠運行在slaves中的一臺機器上。
8）性能無影響
    當監控master，MHA只是幾秒鐘（默認3秒）發送ping包，不發送大的查詢。主從複製性能不受影響
9）適用任何mysql在主從中適用的存儲引擎
    Mysql不只僅適用於事務安全的innodb引擎，在主從中適用的引擎，MHA均可以適用。即便用遺留環境的mysiam引擎，不進行遷移，也能夠用MHA。

MHA的限制：

• 須要在各個節點間打通ssh信任，這對某些公司安全制度來講是個挑戰，由於若是某個節點被黑客攻破的話，其餘節點也會跟着遭殃；
• 自帶提供的腳本還須要進一步補充完善，固然了，通常的使用仍是夠用的。

MHA鏈接切換：

     一般有兩種解決方案：一是引入VIP，當數據庫切換時，VIP隨之切換；經常使用的HA軟件中，大可能是採用VIP實現的，好比Oracle RAC，SQL Server羣集、Heartbeat等。二是採用全局目錄數據庫，即將應用和數據庫之間的鏈接映射爲一個列表，當數據庫切換時，更改這個映射列表。MHA並不限制用戶使用那種方式，只是經過master_ip_failover_script配置參數提供了一個接口。 若採用VIP的方式來實現，可引入第三方軟件，好比Keplived等，也可自行編寫一個VIP切換腳本。 

三、多節點主從+zookeeper

    在大規模節點環境下，採用keepalived或者MHA做爲MySQL的高可用管理仍是有些複雜或麻煩。首先，這麼多節點若是沒有采用配置服務來管理，必然雜亂無章，線上切換時很容易誤操做。在較大規模環境下，建議採用zookeeper管理集羣，可實現快速檢測切換，以及便捷的節點管理。

 

 

 參考

傳送門LVS+Keepalived和MHA安裝配置：

http://bestvivi.com/2015/09/09/MySQL%E4%B8%BB%E4%B8%BB%E5%A4%8D%E5%88%B6+LVS+Keepalived%E5%AE%9E%E7%8E%B0MySQL%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7/

http://joelhy.github.io/2015/02/06/mysql-mha/