防僞碼:既然選擇了遠方,那就只顧風雨兼程!
生產環境中一臺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.1.100
Mysql-master1:192.168.1.101
Mysql-master2:192.168.1.102
配置兩臺 mysql 主主同步
該過程的第一部分就是 master 記錄二進制日誌。在每個事務更新數據完成之前,master 在二進制日誌記錄這些改變。MySQL 將事務寫入二進制日誌。在事件寫入二進制日誌完成後,master通知存儲引擎提交事務。
下一步就是 slave 將 master 的 binary log 拷貝到它自己的中繼日誌。首先,slave 開始一個工作線程——I/O線程。I/O線程在master上打開一個普通的連接,然後開始binlog dump process。Binlogdump process 從 master 的二進制日誌中讀取事件,如果已經同步了 master,它會睡眠並等待 master 產生新的事件。I/O 線程將這些事件寫入中繼日誌。
SQL slave thread(SQL 從線程)處理該過程的最後一步。SQL 線程從中繼日誌讀取事件,並重放其中的事件而更新 slave 的數據,使其與 master 中的數據一致。只要該線程與 I/O 線程保持一致,中繼日誌通常會位於 OS 的緩存中,所以中繼日誌的開銷很小。
主主同步就是兩臺機器互爲主從的關係,在任何一臺機器上寫入都會同步。若 mysql 主機開啓了防火牆,需要關閉防火牆或創建規則。
1、修改 MySQL 配置文件
兩臺 MySQL 均要開啓 binlog 日誌功能,開啓方法:在 MySQL 配置文件[MySQLd]段中加上log- bin=MySQL-bin 選項,兩臺 MySQL 的 server-ID 不能一樣,默認情況下兩臺MySQL 的serverID 都是 1,需將其中一臺修改爲 2 即可。
master1 中有關複製的配置如下:
重啓 mysqld 服務
#service mysqld restart
master2 中有關複製的配置如下:
重啓 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=數據庫名”配置項(可以添加多個)來指定要同步的數據庫
2、將 master1 設爲 master2 的主服務器
在 master1 主機上創建授權賬戶,允許在 master2(192.168.1.102)主機上連接
查看 master1 的當前 binlog 狀態信息
在 master2 上將 master1 設爲自已的主服務器並開啓 slave 功能。
查看從的狀態,以下兩個值必須爲 yes,代表從服務器能正常連接主服務器
Slave_IO_Running:Yes
Slave_SQL_Running:Yes
3、將 master2 設爲 master1 的主服務器
在 master2 主機上創建授權賬戶,允許在 master1(192.168.1.101)主機上連接
查看 master2 的當前 binlog 狀態信息
在 master1 上將 master2 設爲自已的主服務器並開啓 slave 功能。
查看從的狀態,以下兩個值必須爲 yes,代表從服務器能正常連接主服務器
Slave_IO_Running:Yes
Slave_SQL_Running:Yes
4、測試主主同步
在 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 協議的。
二、keepalived 的安裝配置
1、在 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=ipaccept"
success
[root@localhost ~]# firewall-cmd --reload
2、修改 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.1.100
}
}
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,需要指定 realserver 的真實 IP 地址和
端口,IP 與端口之間用空格隔開
注:master2 上此處改爲 192.168.1.102(即 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
3、master1 和 master2 上都添加此檢測腳本,作用是當 mysql 停止工作時自動關閉本機的
keepalived,從而實現將故障機器踢出(因每臺機器上keepalived 只添加了本機爲 realserver).
當 mysqld 正常啓動起來後,要手動啓動 keepalived 服務。
#mkdir /etc/keepalived/bin
vi /etc/keepalived/bin/mysql.sh,內容如下:
Master2 主機完成相同的操作
4、測試
在 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 最新版本,利用多線程複製的方式可以很大程度降低複製延遲;