MySQL 高可用性—keepalived+mysql雙主（有詳細步驟和所有配置項解釋）

博主QQ：819594300

博客地址：http://zpf666.blog.51cto.com/

有什麼疑問的朋友能夠聯繫博主，博主會幫大家解答，謝謝支持！

前言：生產環境中一臺mysql主機存在單點故障，因此咱們要確保mysql的高可用性，即兩臺MySQL服務器若是其中有一臺MySQL服務器掛掉後，另一臺能立馬接替其進行工做。

MySQL的高可用方案通常有以下幾種：

keepalived+雙主，MHA，PXC，MMM，Heartbeat+DRBD等，比較經常使用的是keepalived+雙主，MHA和PXC。

本節主要介紹了利用 keepalived 實現 MySQL 數據庫的高可用。

Keepalived+mysql雙主來實現MySQL-HA，咱們必須保證兩臺MySQL數據庫的數據徹底同樣，基本思路是兩臺MySQL互爲主從關係，經過Keepalived配置虛擬IP，實現當其中的一臺MySQL數據庫宕機後，應用可以自動切換到另一臺MySQL數據庫，保證系統的高可用。

拓撲環境：

OS：centos7.2x86_64

Mysql版本：mysql5.7.13

Keepalived: keepalived-1.2.20

Mysql-vip:192.168.1.150

Mysql-master1:192.168.1.100

Mysql-master2:192.168.1.200

1、   配置兩臺mysql主主同步

該過程的第一部分就是master記錄二進制日誌。在每一個事務更新數據完成以前，master在二日誌記錄這些改變。MySQL將事務寫入二進制日誌。在事件寫入二進制日誌完成後，master通知存儲引擎提交事務。

下一步就是slave將master的binarylog拷貝到它本身的中繼日誌。首先，slave開始一個工做線程——I/O線程。I/O線程在master上打開一個普通的鏈接，而後開始binlog dump process。Binlog dump process從master的二進制日誌中讀取事件，若是已經同步了master，它會睡眠並等待master產生新的事件。I/O線程將這些事件寫入中繼日誌。

SQL slave thread（SQL從線程）處理該過程的最後一步。SQL線程從中繼日誌讀取事件，並重放其中的事件而更新slave的數據，使其與master中的數據一致。只要該線程與I/O線程保持一致，中繼日誌一般會位於OS的緩存中，因此中繼日誌的開銷很小。

主主同步就是兩臺機器互爲主的關係，在任何一臺機器上寫入都會同步。

若mysql主機開啓了防火牆，須要關閉防火牆或建立規則。

實驗具體過程以下：

1、修改MySQL配置文件

注意：mysql1和mysql只有server-id不一樣和auto-increment-offset不一樣,其餘必須相同。

部分配置項解釋以下：

binlog_format= mixed：指定mysql的binlog日誌的格式，mixed是混合模式。

relay-log：開啓中繼日誌功能

relay-log-index：中繼日誌清單

auto-increment-increment= 2：表示自增加字段每次遞增的量，其默認值是1。它的值應設爲整個結構中服務器的總數，本案例用到兩臺服務器，因此值設爲2。

auto-increment-offset= 2：用來設定數據庫中自動增加的起點(即初始值)，由於這兩能服務器都設定了一次自動增加值2，因此它們的起點必須得不一樣，這樣才能避免兩臺服務器數據同步時出現主鍵衝突。

注：另外還能夠在my.cnf配置文件中，添加「binlog_do_db=數據庫名」配置項（能夠添加多個）來指定要同步的數據庫。若是配置了這個配置項，若是沒添加在該配置項後面的數據庫，則binlog不記錄它的事件。

2、將mysql1設爲mysql2的主服務器

在mysql1主機上建立受權帳戶，容許在mysql2(192.168.1.200)主機上鍊接

查看mysql1的當前binlog狀態信息：

在mysql2上將mysql1設爲自已的主服務器並開啓slave功能：

下面看一看mysql2的狀態：

在mysql1防火牆上開啓3306/tcp例外：

順道把mysql2的防火牆也開啓3306/tcp例外，反正後面實驗仍是要開，那就如今一道開了吧：

再次查看mysql2的狀態：

更換mysql2的UUID號：

修改完UUID必須重啓mysqld服務才能生效：

此次再來查看mysql2的狀態：

3、如今反過來·，再將mysql2設爲mysql1的主服務器

在mysql2主機上建立受權帳戶，容許在mysql1(192.168.1.100)主機上鍊接

查看mysql2的當前binlog狀態信息：

在mysql1上將mysql2設爲自已的主服務器並開啓slave功能：

查看mysql1的狀態：

4、測試主主同步

在mysql1上建立要同步的數據庫如bdqn，並在bdqn中建立一張測試表叫it

查看mysql2主機是否同步了mysql1上的數據變化：

從上圖能夠看出mysql2同步了mysql1的數據變化

如今往mysql2主機上向it表中插入兩行數據：

查看mysql1主機是否同步了mysql2上的數據變化：

總結：至此如今任何一臺MySQL上更新數據都會同步到另外一臺MySQL，MySQL同步完成。

注意：若主MYSQL服務器已經存在，只是後期才搭建從MYSQL服務器，在置配數據同步前應先將主MYSQL服務器的要同步的數據庫拷貝到從MYSQL服務器上（如先在主MYSQL上備份數據庫，再用備份在從MYSQL服務器上恢復）

 

下面咱們就完成keepalived的高可用性：

說明：keepalived是集羣管理中保證集羣高可用的一個軟件解決方案，其功能相似於heartbeat，用來防止單點故障

keepalived是以VRRP協議爲實現基礎的，VRRP全稱VirtualRouter Redundancy Protocol，即虛擬路由冗餘協議。

虛擬路由冗餘協議，能夠認爲是實現路由器高可用的協議，即將N臺提供相同功能的路由器組成一個路由器組，這個組裏面有一個master和多個backup，master上面有一個對外提供服務的vip，master會發組播（組播地址爲224.0.0.18），當backup收不到vrrp包時就認爲master宕掉了，這時就須要根據VRRP的優先級來選舉一個backup當master，這樣的話就能夠保證路由器的高可用了。

keepalived主要有三個模塊，分別是core 、check和vrrp。core模塊爲keepalived的核心，負責主進程的啓動、維護以及全局配置文件的加載和解析。check負責健康檢查，包括常見的各類檢查方式。vrrp模塊是來實現VRRP協議的。

 

2、keepalived的安裝配置

1、在mysql1和mysql2兩臺服務器上安裝keepalived的幾個依賴包

注意：如不知道keepalived須要哪些依賴包，可到下載後的源碼解壓目錄下查看INSTALL 文件內容，安裝須要的依賴包，源碼安裝任何一個軟件都要養成查看源碼包文檔的習慣，好比INSTALL，README,doc等文檔，能夠得到不少有用的信息。

下面咱們來看一看keepalived的INSTALL文件：

2、在兩臺mysql上都開始解壓縮編譯安裝keepalived

注：若是你使用的是centos6.5版本，則配置編譯裝的時候要這樣寫,以下圖所示：

3、執行make install操做以後，會自動生成/etc/init.d/keepalived腳本文件，但還須要手動添加爲系統服務，這樣就可使用service、chkconfig工具來對keepalived服務程序進行管理了。

                                                  yum -y install ipvsadm

4、若開啓了防火牆，則須要關閉防火牆或者建富策略（現實生產環境中，都不容許關防火牆的，因此咱們仍是建富策略爲第一選擇）（兩臺mysql都須要操做）

5、修改keepalived的配置文件

說明：keepalived只有一個配置文件keepalived.conf，裏面主要包括如下幾個配置區域，分別是：

global_defs、vrrp_instance和virtual_server。

• global_defs：主要是配置故障發生時的通知對象以及機器標識。

• vrrp_instance：用來定義對外提供服務的VIP區域及其相關屬性。

• virtual_server：虛擬服務器定義

看不清截圖的能夠看下面的粘貼的文字：

! Configuration File for keepalived

 

global_defs {

  router_id mysql-1

}

 

vrrp_instance VI_1 {

   state BACKUP

   interface eno16777736

   virtual_router_id 51

   priority 100

   advert_int 1

   nopreempt

   authentication {

       auth_type PASS

       auth_pass 1111

   }

   virtual_ipaddress {

       192.168.1.150

   }

}

 

virtual_server 192.168.1.150 3306 {

   delay_loop 2

   lb_algo rr

   lb_kind DR

   persistence_timeout 60

   protocol TCP

 

   real_server 192.168.1.100 3306 {

       weight 3

       notify_down    /etc/keepalived/bin/mysql.sh

       TCP_CHECK {

            connect_timeout 3

            nb_get_retry 3

            delay_before_retry 3

            connect_port 3306

       }

   }

}

每一個配置項的解釋以下：

一樣的也須要修改mysql2的keepalived配置文件（下圖中綠色部分爲和mysql1不同的地方）

可使用scp命令把mysql1主機上配置好的keepalived.conf文件拷貝到server2主機，只須要改綠色部分便可:

6、啓動keepalived服務（兩臺都要啓動）

7、mysql1和mysql2上都須要添加檢測腳本

做用：是當mysql中止工做時自動關閉本機的keeplived，從而實現將故障主機踢出熱備組，因每臺機器上keepalived只添加了本機爲realserver，因此當mysqld正常啓動後，咱們還須要手動啓動keepalived服務。

8、給mysql.sh腳本賦予可執行權限（兩臺mysql都操做一樣的步驟）

9、在mysql1和mysql2上分別執行ip addr show dev eno16777736命令查看mysql1和mysql2對VIP（羣集虛擬IP）的控制權

從上圖能夠看出mysql1是master，mysql2是slave。

10、中止mysql1的mysql服務，看keepalived健康檢查程序是否會觸發了咱們編寫的腳本，進行自動故障切換

從上圖能夠說明在master服務器的mysql服務發生故障時，mysql1主機觸發了咱們編寫的腳本，發生了自動故障切換。

11、如今咱們把mysql1的mysql服務開起來，而且keepalived的服務也須要手動開啓

12、咱們再次在兩臺mysql服務器上用ip addr show dev eno16777736命令看一下

從上面兩張圖能夠看出，即使mysql1的mysql服務和keepalived服務都從新開啓了，mysql2仍然是master了，mysql1搶不回去master的權利了，說明咱們設置的nopreempt配置生效了，在生產環境中就須要添加不搶佔配置，保證了羣集穩定性，只有當mysql2的mysql服務壞掉的時候，mysql1纔會再次成爲master，不然它永遠只能當mysql2的備份。（注：nopreempt通常是在優先級高的mysql上設置）

13、咱們找一臺安裝有MySQL客戶端，而後登陸VIP，看是否能登陸，在登陸以前兩臺MySQL服務器都要受權容許從遠程登陸

在客戶端上登錄：

上圖顯示說明在客戶端訪問VIP地址，由mysql2主機提供響應的，由於mysql2當前是主服務器，將mysql2的mysql服務中止，在客戶端執行show  variables like‘server_id’;

上圖顯示說明在客戶端的查詢請求是由mysql1主機響應的，故障切換成功。

 

總結：

Keepalived+mysql雙主通常來講，中小型規模的時候，採用這種架構是最省事的。

在master節點發生故障後，利用keepalived的高可用機制實現快速切換到備用節點。

在這個方案裏，有幾個須要注意的地方：

1.採用keepalived做爲高可用方案時，兩個節點最好都設置成BACKUP模式，避免由於意外狀況下（好比腦裂）相互搶佔致使往兩個節點寫入相同數據而引起衝突；

2.把兩個節點的auto_increment_increment（自增步長）和auto_increment_offset（自增起始值）設成不一樣值。其目的是爲了不master節點意外宕機時，可能會有部分binlog未能及時複製到slave上被應用，從而會致使slave新寫入數據的自增值和原先master上衝突了，所以一開始就使其錯開；固然了，若是有合適的容錯機制能解決主從自增ID衝突的話，也能夠不這麼作；

3.slave節點服務器配置不要太差，不然更容易致使複製延遲。做爲熱備節點的slave服務器，硬件配置不能低於master節點；

4.若是對延遲問題很敏感的話，可考慮使用MariaDB分支版本，或者直接上線MySQL 5.7最新版本，利用多線程複製的方式能夠很大程度下降複製延遲；