MySQL數據庫--主主複製+keepalived高可用

              MySQL數據庫--主主複製+keepalived高可用mysql

以前咱們有學習過mysql的主從複製,主要是在工做環境當中防止數據庫讀寫在一臺數據庫上容易形成負載,實現讀寫分離就是爲了給服務器減輕工做壓力,就比如一我的的工做分紅了兩我的來作,那麼人也減輕了壓力。並且工做效率也提升了上去。可是要實現讀寫分離的前提就是主從複製對吧?linux

主服務器爲master;從服務器爲slave。而咱們今天帶來的和主從複製有點不同,多用與中小型公司,叫作主主複製。git

注:在生產環境中一臺MySQL從在單點故障的缺陷,若是一旦發生意外,那麼將會發生嚴重的後果,爲公司形成嚴重的損失github

那麼若是兩個的話那麼將會效果好一點;其中一臺宕掉,另外一臺會立刻接替。sql

既然知道了主主複製的背景了,那麼咱們來了解下MySQL主主複製的原理以及思路:數據庫

1)開啓二進制日誌文件bin_log、中繼日誌文件relay-log、server-id號、以及auto-increment-offset和auto-increment-increment(自動增加)centos

2)設置一個用戶而且賦予權限服務器

3)查看二進制文件和ID號,以便後續制定master服務器多線程

4)相互指定對方爲master服務器架構

5)開啓slave狀態,{start slave}

6)查看sql和i/o狀態爲yes便成功

以上屬於主主複製的基本思路;接下來咱們演示一下,讓你們看的更直觀一些:

 

 

準備環境:

兩臺mysql服務器: 版本5.7

master服務器< ip 192.168.1.10 >

master2服務器 < ip 192.168.1.20 >

wKioL1la4sWQRm25AABaCnI0xMw363.png-wh_50 

 

一:配置master的配置文件修改內容: vi /etc/my.cnf

wKioL1la4tiRR7SCAABi2dsQmbs929.png 

 

log-bin = mysql-bin===========開啓binlog日誌

binlog_format = mixed========基於混合模式

server-id = 1==========ID號爲1

relay-log = relay-bin==========開啓中繼日誌

relay-log-index = slave-relay-bin.index==========中繼日誌的索引文件

auto-increment-increment = 2 =========整個架構中的服務器臺數

auto-increment-offset = 1==========用來設定數據庫中自動增加的起點(即初始值)

完成後重啓MySQL服務

 

master2服務器也是如此:{需注意:}

 

wKioL1la4u-iGRjQAABzsNOs7Cw975.png 

以後重啓MySQL服務

 

 

二:設置一個用戶而且授予權限爲後續的連接使用:

首先在master上設置:

wKiom1la4wSQl-8OAAAh5R50ljQ398.png 

 

三:查看下master的當前binlog狀態信息:

wKiom1la4xjw-LhKAAAht0IA-88329.png-wh_50 

master2上面將master設置爲本身的主服務其而且開啓slave功能

wKioL1la4y3DM8YnAAA3XnD9STY040.png-wh_50 

四:查看下當前的狀態,一下兩個值必須爲yes,表明master2正常連接master服務器

Slave_IO_Running:Yes

Slave_SQL_Running:Yes

wKiom1la40mBnqShAACkTDPYVi4274.png-wh_50 

master2服務已經成功,

接下來對master服務器進行配置;

master2設置爲master的主服務器

master2上也進行一樣的配置;固然用戶能夠變動

 

wKiom1la41zx6GUIAAAg7vT1BU0115.png查看master2的binlog狀態;

 

wKiom1la422RtlIVAAAiS1_6_dc668.png-wh_50 

master服務器上將master2設置爲本身的主服務器而且開啓slave功能;

wKiom1la44CCMhP1AAAptbvfE7A704.png 

 

查看master服務器的狀態,一下兩個值必須爲yes,表明從服務器能夠連接主服務器

Slave_IO_Running:Yes

Slave_SQL_Running:Yes

wKiom1la45XwlwVSAACN7ebQbKM606.png-wh_50 

以上說明master服務器也成功了。

 

 

那麼接下來咱們來測試下主主同步

master上面建立要同步的數據庫tty,而且在tty當中建立一張表tb1

wKioL1la46eCnRGxAAApNHqpkaA958.png-wh_50 

 

那麼咱們來查看一下master2上面是否也會存在剛纔建立的數據庫和表呢?

wKiom1la47vCQ7LHAABOQdIxkkc492.png-wh_50 

 

經過結果咱們能夠得知在master上建立的庫和表能夠同步到master2上面,可是master2上的數據能夠同步到master上面去嗎?

 

咱們在master2上爲tty庫中的tb1表中插點數據來驗證一下:

wKiom1la486DzKXjAAApIGZH2IQ979.png 

 

咱們來查看一下在master上面是否會有剛纔在master2上面插入的兩條數據呢?

wKioL1la4-OAAVMOAAAWvxmK8cc980.png-wh_50 

 

因而可知當前咱們的數據庫主主複製是成功的,

 

 

總結一下;

主主複製是兩臺MySQL服務互相讀寫同步,互相備份的結果

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

 

二:上面咱們介紹了mysql的主主複製,可是若是這兩臺服務器其中有一臺忽然宕機了該怎麼辦呢?這就須要咱們的下一個要講述的環節了,也就是keepalived,實現這兩臺數據庫的負載均衡。若是有其中的一臺忽然宕機以後那麼另外的一臺將會接替,保證服務的不間斷性。

 

Keepalived的原理;

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

keepalived是以VRRP協議爲實現基礎的,VRRP全稱Virtual Router Redundancy Protocol,即虛擬路由冗餘協議

 

基於ARP協議進行組播 發送的,即將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協議的

介紹完keepalived的功能以及模塊,接下來咱們開始在兩臺mysql上都配置keepalived

安裝keepalived軟件包與服務控制

在編譯安裝Keepalived以前,必須先安裝內核開發包kernel-devel以及openssl-devel、popt-devel等支持庫。

在這裏經過yum安裝:

Yum -y install kernel-devel  openssl-devel popt-devel

wKioL1la4_vgMmVxAAAN3xHj2RE260.png 

編譯安裝Keepalived

wKiom1la5A3hleg6AABaGyx90Bg401.png 

 

注意:在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服務程序進行管理了。

wKiom1la5CDDH6ODAAA7OHwreaE198.png-wh_50 

 

 

Master 和master2 安裝keepalived的過程均如上圖所示,沒有任何差異,

注:若是在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:虛擬服務器定義

Master{keepalived}的主配置文件

wKioL1la5Eew7UPyAAA9lNTLxNI566.png-wh_50wKioL1la5F7j8EMQAABGkgE0Ni4109.png-wh_50 

 

 

啓動keepalived服務

#/etc/init.d/keepalived start

wKiom1la5HazT1MrAAAWlP-hkXw975.png 

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

Master2主機的keepalived.conf文件配置與master1基本相同,只是router_idpriority,real_server三處不一樣,其餘配置都相同

可使用scp命令把server1主機上配置好的keepalived.conf文件拷貝到server2主機,只要作簡單修改便可,以下圖所示:

wKiom1la5ImBt7GFAABwD9oT26c836.png 

Master2{keepalived}主配置文件

wKioL1la5J2zD-zKAABBo_CMN_E490.png-wh_50 

wKiom1la5K-AFLkPAABJ-3-jYro720.png-wh_50 

啓動keepalived服務

#/etc/init.d/keepalived start

wKioL1la5MCw6S9DAAAiWlhkt_k441.png 

 

 

在上面當中在notify_down指定腳本的路徑能夠在不使用keepalived的時候殺死keepalived的進程;

wKiom1la5NHjz6KXAAAUV00bqRg033.png-wh_50 

以後給腳本一個x的執行權限

Chmod +x /etc/keepalived/bin/mysql.sh

 

 

這些工做完成以後能夠驗證咱們以前的mysql+keepalived有沒有成功呢?

首先查看下vrrp的虛擬IP

wKioL1la5OSw0Dj4AACQI4f_bDY642.png-wh_50 

那麼master2上面呢?

wKiom1la5PPxS_ntAACLOgtL5Tc801.png-wh_50 

 

在這裏咱們模擬master忽然宕機以後看一看master2是否會接替master上面的vrrp漂移ip呢?

 

首先使用咱們的腳本執行如下;

wKioL1la5QKTA0ITAAALVbxyPsc138.png-wh_50 

以後呢在查看下master上面的vrrp漂移ip是否存在

wKiom1la5Rmwh9DTAACenqV-s9o710.png-wh_50 

能夠看得出啦vrrp的漂移ip已經再也不master服務器上面了,那麼master2上面呢?

 

wKiom1la5SmjARsrAACJHe_eoGk087.png-wh_50 

能夠看到master2成功的接替了master上面的vrrp的漂移ip了,說明咱們的高可用服務是成功的

 

 

在這裏keepalived+mysql服務就講解到這裏,可是呢在前面就曾說過,keepalived使用與小型的公司,在配置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最新版本,利用多線程複製的方式能夠很大程度下降複製延遲;

此次爲你們帶來的是小型公司對mysql主要使用架構方案;下次爲你們帶來的是中大型公司使用的架構MMM,相信你們也有所瞭解,具體等下次咱們細說

相關文章
相關標籤/搜索