MySQL 高可用性keepalived+mysql雙主

防僞碼：明日復明日，明日何其多。

生產環境中一臺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：centos6.5 x86_64

Mysql 版本：mysql 5.5.38

Keepalived: keepalived-1.2.20

Mysql-vip:192.168.12.1

Mysql-master1:192.168.12.128

Mysql-master2:192.168.12.129

1、配置兩臺 mysql 主主同步

該過程的第一部分就是 master 記錄二進制日誌。在每一個事務更新數據完成以前，master 在

二日誌記錄這些改變。MySQL 將事務寫入二進制日誌。在事件寫入二進制日誌完成後，master

通知存儲引擎提交事務。

下一步就是 slave 將 master 的 binary log 拷貝到它本身的中繼日誌。首先，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 主機開啓了防火牆，須要關閉防火牆或建立規則。

一、修改 MySQL 配置文件

兩臺 MySQL 均要開啓 binlog 日誌功能，開啓方法：在 MySQL 配置文件[MySQLd]段中加上

log-bin=MySQL-bin 選項，兩臺 MySQL 的 server-ID 不能同樣，默認狀況下兩臺 MySQL 的

serverID 都是 1，需將其中一臺修改成 2 便可。

master1 中有關複製的配置以下：

log-bin = mysql-bin

binlog_format = mixed

server-id = 1

relay-log = relay-bin

relay-log-index = slave-relay-bin.index

auto-increment-increment = 2

auto-increment-offset = 1

重啓 mysqld 服務

#service mysqld restart

master2 中有關複製的配置以下：

log-bin = mysql-bin

binlog_format = mixed

server-id = 2

relay-log = relay-bin

relay-log-index = slave-relay-bin.index

auto-increment-increment = 2

auto-increment-offset = 2

重啓 mysqld 服務

#service mysqld restart

注：master1 和 master2 只有 server-id 不一樣和 auto-increment-offset 不一樣。

mysql 中有自增加字段，在作數據庫的主主同步時須要設置自增加的兩個相關配置：

auto_increment_offset 和 auto_increment_increment。

auto-increment-increment 表示自增加字段每次遞增的量，其默認值是 1。它的值應設爲整個

結構中服務器的總數，本案例用到兩臺服務器，因此值設爲 2。

auto-increment-offset 是用來設定數據庫中自動增加的起點(即初始值)，由於這兩能服務器都

設定了一次自動增加值 2，因此它們的起點必須得不一樣，這樣才能避免兩臺服務器數據同步

時出現主鍵衝突，

注：能夠在 my.cnf 文件中添加「binlog_do_db=數據庫名」配置項（能夠添加多個）來指定

要同步的數據庫

二、將 master1 設爲 master2 的主服務器

在 master1 主機上建立受權帳戶，容許在 master2(192.168.1.102)主機上鍊接

查看 master1 的當前 binlog 狀態信息

在 master2 上將 master1 設爲自已的主服務器並開啓 slave 功能。

查看從的狀態，如下兩個值必須爲 yes,表明從服務器能正常鏈接主服務器

Slave_IO_Running:Yes

Slave_SQL_Running:Yes

三、將 master2 設爲 master1 的主服務器

在 master2 主機上建立受權帳戶，容許在 master1(192.168.12.128)主機上鍊接

查看 master2 的當前 binlog 狀態信息

在 master1 上將 master2 設爲自已的主服務器並開啓 slave 功能。

查看從的狀態，如下兩個值必須爲 yes,表明從服務器能正常鏈接主服務器

Slave_IO_Running:Yes

Slave_SQL_Running:Yes

四、測試主主同步

在 master1 上建立要同步的數據庫如 test_db，並在 test_db 中建立一張測試表如 tab1

查看 master2 主機是否同步了 master1 上的數據變化

從上圖能夠看出 master2 同步了 master 的數據變化

在 master2 主機上向 tab1 表中插入數據

查看 master1 主機是否同步了 master2 上的數據變化

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

注：若主 MYSQL 服務器已經存在，只是後期才搭建從 MYSQL 服務器，在置配數據同步前應

先將主 MYSQL 服務器的要同步的數據庫拷貝到從 MYSQL 服務器上（如先在主 MYSQL 上備

份數據庫，再用備份在從 MYSQL 服務器上恢復）

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

keepalived 是集羣管理中保證集羣高可用的一個軟件解決方案，其功能相似於 heartbeat，用

來防止單點故障

keepalived 是以 VRRP 協議爲實現基礎的，VRRP 全稱 Virtual Router 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 負責健康檢查，包括常見的

各類檢查方式(方式 1：tcp_check,工做第四層。方式 2：http_get,工做在第五層，向指定的

URL 執行 http 請求，將獲得的結果用 md5 加密並與指定的 md5 值比較看是否匹配，不匹配

則從服務器池中移除。方式 3：ssl_get:與 http_get 類似。方式 4：misc_check:用腳原本檢測。

方式 5：smtp_check:用來檢測郵件服務的 smtp)。vrrp 模塊是來實現 VRRP 協議的。

2、keepalived 的安裝配置

一、在 master1 和 master2 上安裝軟件包 keepalived

安裝 keepalived 軟件包與服務控制

在編譯安裝 Keepalived 以前，必須先安裝內核開發包 kernel-devel 以及 openssl-devel、

popt-devel 等支持庫。

若沒有安裝則經過 rpm 或 yum 工具進行安裝

編譯安裝 Keepalived

使用指定的 linux 內核位置對 keepalived 進行配置，並將安裝路徑指定爲根目錄，這樣就無

需額外建立連接文件了，配置完成後，依次執行 make、make install 進行安裝。

注意：如不知道 keepalived 須要哪些依賴包，可到下載後的源碼解壓目錄下查看 INSTALL 文

件內容，安裝須要的依賴包，源碼安裝任何一個軟件都要養成查看源碼包文檔的習慣，好比

INSTALL，README,doc 等文檔，能夠得到不少有用的信息

注意：在 centos7.2 上安裝 keepalived 不須要添加--with-kernel-dir

[root@localhost keepalived-1.2.20]# ./configure --prefix=/ && make && make install

使用 keepalived 服務

執行 make install 操做以後，會自動生成/etc/init.d/keepalived 腳本文件，但還須要手動添加

爲系統服務，這樣就可使用 service、chkconfig 工具來對 keepalived 服務程序進行管理了。

Master2 主機也完成 keepalived 安裝，與 master1 同樣，安裝過程略

注：若開啓了防火牆，須要關閉防火牆或建立規則。

注：若是在 centos7.2 上安裝 keepalived 防火牆的規則配置以下：

[root@localhost ~]# firewall-cmd --permanent --add-rich-rule="rule family=ipv4 destination

address=224.0.0.18 protocol value=ip accept"

success

[root@localhost ~]# firewall-cmd --reload

二、修改 Keepalived 的配置文件

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

global_defs、vrrp_instance 和 virtual_server。

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

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

virtual_server：虛擬服務器定義

master1 主機上的 keepalived.conf 文件的修改：

vi /etc/keepalived/keepalived.conf:

! Configuration File for keepalived //!表示註釋

global_defs {

router_id MYSQL-1 //表示運行 keepalived 服務器的一個標識

}

vrrp_instance VI_1 {

state BACKUP //指定keepalived的角色,兩臺配置此處均是BACKUP,設爲BACKUP將根據

優先級決定主或從

interface eth0 //指定 HA 監測網絡的接口

virtual_router_id 51 //虛擬路由標識，這個標識是一個數字(取值在 0-255 之間,用來區分多個

instance 的 VRRP 組播)，同一個 vrrp 實例使用惟一的標識,確保和 master2 相同，同網內不一樣集羣此項必須不一樣,不然發生衝突。

priority 100 //用來選舉 master 的，要成爲 master，該項取值範圍是 1-255（在此範圍

以外會被識別成默認值 100）,此處 master2 上設置爲 50

advert_int 1 //發 VRRP 包的時間間隔，即多久進行一次 master 選舉（能夠認爲是健康查

檢時間間隔）

nopreempt //不搶佔，即容許一個 priority 比較低的節點做爲 master，即便有 priority 更高

的節點啓動

authentication { //認證區域，認證類型有 PASS 和 HA（IPSEC），推薦使用 PASS（密碼

只識別前 8 位）

auth_type PASS

auth_pass 1111

}

virtual_ipaddress { //VIP 區域，指定 vip 地址

192.168.12.1

}

}

virtual_server 192.168.1.100 3306 { //設置虛擬服務器，須要指定虛擬 IP 地址和服務端口，

IP 與端口之間用空格隔開

delay_loop 2 //設置運行狀況檢查時間，單位是秒

lb_algo rr //設置後端調度算法，這裏設置爲 rr，即輪詢算法

lb_kind DR //設置 LVS 實現負載均衡的機制，有 NAT、TUN、DR 三個模式可選

persistence_timeout 60 //會話保持時間，單位是秒。這個選項對動態網頁是很是有用的，

爲集羣系統中的 session 共享提供了一個很好的解決方案。

有了這個會話保持功能，用戶的請求會被一直分發到某個服務節點，

直到超過這個會話的保持時間。

protocol TCP //指定轉發協議類型，有 TCP 和 UDP 兩種

real_server 192.168.1.101 3306 { //配置服務節點 1，須要指定 real server 的真實 IP 地址和

端口，IP 與端口之間用空格隔開

注：master2 上此處改成 192.168.12.128(即 master2 本機 ip)

weight 3 //配置服務節點的權值，權值大小用數字表示，數字越大，權值越高，設置權

值大小爲了區分不一樣性能的服務器

notify_down /etc/keepalived/bin/mysql.sh //檢測到 realserver 的 mysql 服務 down 後執行的

腳本

TCP_CHECK {

connect_timeout 3 //鏈接超時時間

nb_get_retry 3 //重連次數

delay_before_retry 3 //重連間隔時間

connect_port 3306 //健康檢查端口

}

}

}

master1 主機上有關 keepalived.conf 文件的具體配置以下：

啓動 keepalived 服務

#/etc/init.d/keepalived start

Master2 主機上的 keepalived.conf 文件的修改：

Master2 主機的 keepalived.conf 文件配置與 master1 基本相同，只是 router_id，priority，

real_server 三處不一樣，其餘配置都相同

可使用 scp 命令把 server1 主機上配置好的 keepalived.conf 文件拷貝到 server2 主機，只要。

啓動 keepalived 服務

#/etc/init.d/keepalived start

三、master1 和 master2 上都添加此檢測腳本，做用是當 mysql 中止工做時自動關閉本機的

keepalived，從而實現將故障機器踢出（因每臺機器上 keepalived 只添加了本機爲 realserver）.

當 mysqld 正常啓動起來後，要手動啓動 keepalived 服務。

#mkdir /etc/keepalived/bin

vi /etc/keepalived/bin/mysql.sh，內容以下：

Master2 主機完成相同的操做

四、測試

在 master1 和 master2 分別執行 ipaddr show dev eth0 命令查看 master1 和 master2 對 VIP

（羣集虛擬 IP）的控制權。

Master1 主的查看結果：

Master2 主的查看結果：

從上圖能夠看出 master1 是主服務器，master2 爲備用服務器。

中止 MySQL 服務，看 keepalived 健康檢查程序是否會觸發咱們編寫的腳本

中止 master1 主機的 mysql 服務

Master2 主的查看結果：

這說明在主服務上中止 MySQL 服務，觸發了咱們編寫的腳本，進行自動故障切換。

MySQL 遠程登陸測試

咱們找一臺安裝有 MySQL 客戶端，而後登陸 VIP，看是否能登陸，在登陸之兩臺 MySQL 服

務器都要受權容許從遠程登陸。例如：

在客戶端上測試登陸

上圖顯示說明在客戶端訪問 VIP 地址，由 master1 主機提供響應的，由於 master1 當前是主

服務器，將 master1 的 mysql 服務中止，在客戶端執行 show variables like‘server_id’;

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

總結：

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 最

新版本，利用多線程複製的方式能夠很大程度下降複製延遲；

謝謝觀看，真心的但願能幫到您！