mysql高可用+keepalived
MYSQL的高可用方案一般有
Keepalived+雙主，MHA,PXC,MMM,Heartbeat+DRBD等 比較常用的是keepalived+雙主MHA和PXC
這次主要介紹利用keepalived實現MYSQL數據庫的高可用。
基本思路：倆臺MYSQL互為主從關系（雙主），通過keepalived配置配置虛擬IP，實現當其中一臺mysql掛機後，應用能夠自動切換到另外一臺MYSQL數據庫，保證系統的高可用。
操作系統 Centos7.2
MYSQL版本 5.7
Keepalived：keepalived-1.2
Mysql-vip：192.168.0.100
Mysql-master1：192.168.0.7
Mysql-slave1：192.168.0.6
該過程的第一部分就是master記錄著二進制日誌。在每個事務更新數據完成之前，master在二日誌記錄這些改變。Mysql將事務寫入二進制日誌，在事件寫入二進制日誌完成後，master通知存儲引擎提交事務。
下一步就是slave將master的binary log拷貝到它自己的中繼日誌。首先，slave開始一個工作線程--I/O線程。I/O線程在master上打開一個普通的連接，然後開始binlog dump process
Binlog dump process 從master的二進制日誌中讀取事件。 I/O線程將這些事件寫入中繼日誌。
SQL slave thread （SQL 從線程） 處理該過程的最後一步。SQL線程從中繼日誌讀取事件，並重放其中的事件而更新slave的數據，使其與master中的數據一致。只要該進程與I/O線程保持一致，中繼日誌通常位於OS緩存中，所以中繼日誌的開銷很小。
主主同步就是倆臺機器互為主從關系，在任何一臺機器上寫入都會同步。
1：修改MYSQL配置文件
倆臺mysql均要開啟binlog 日誌功能，開啟方法：在MYSQL配置文件加上
Log-bin=MYSQL-bin選項，倆臺mysql的
一：master1中有關配置如下
basedir = /usr/local/mysql datadir = /usr/local/mysql/data server_id = 1 socket = /usr/local/mysql/mysql.sock log-error = /usr/local/mysql/data/mysqld.err log-bin=mysql-bin binlog_format=mixed relay-log=relay-bin relay-log-index=slave-relay-bin.index auto-increment-increment=2 auto-increment-offset=1
重啟mysql服務
Master2中有關復制配置如下
[mysqld] basedir = /usr/local/mysql datadir = /usr/local/mysql/data server_id = 2 socket = /usr/local/mysql/mysql.sock log-error = /usr/local/mysql/data/mysqld.err log-bin=mysql-bin binlog_format=mixed relay-log=relay-bin relay-log-index=slave-relay-bin.index auto-increment-increment=2 auto-increment-offset=2
重啟mysqld服務
二：將master1設為master2的主服務器
在master1主機上創建授權賬戶，允許在master2（192.168.0.6）主機上連接
mysql> grant replication slave on *.* to '[email protected]' identified by '123456'; Query OK, 0 rows affected, 1 warning (0.01 sec)
查看master1的當前binlog狀態信息
在slave上將master設為自己的主服務器並開啟slave功能
mysql>change,master,to,master_host='192.168.0.6',master_user='rep',master_password='123456',master_log_file='mysql-bin.000004',master_log_pos=451; Query OK, 0 rows affected, 2 warnings (0.04 sec)
mysql> start slave; Query OK, 0 rows affected (0.01 sec)
查看從的狀態，以下倆個值必須為yes，代表從服務器能正常連接主服務器
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
mysql> show slave status\G;
三，將master2設為master1的主服務器
在slave主機上創建授權賬戶，允許在master（192.168.0.6）主機上連接
mysql> grant replication slave on *.* to 'rep'@'192.168.0.6' identified by '123456'; Query OK, 0 rows affected, 1 warning (0.00 sec)
查看slave的當前binlog狀態信息
mysql> show master status;
在master上將slave設為自己的主服務器並開啟slave功能
mysql>change,master,to ,master_host='192.168.0.7',master_user='rep',master_password='123456',master_log_file='mysql-bin.000003',master_log_pos=154; Query OK, 0 rows affected, 2 warnings (0.03 sec)
查看從的狀態下，以下倆個值必須為yes代表從服務器能正常連接主服務器
四：測試主主同步
在master上創建數據庫 chai 看看slave是否同步
主的服務器
從的服務器驗證已經同步過來
現在任何一臺MYSQL上更新數據同步到另一臺mysql 同步完成
註意：若主MYSQL服務器已經存在，只是後期才搭建從MYSQL服務器，在配置數據同步前應先主MYSQL服務器的要同步的數據庫拷貝到從MYSQL服務器上(如先在主MYSQL上備份數據庫，再用備份在從MYSQL服務器上恢復
接著完成keepalived的高可用性
Keepalived是集群管理中保證集群高可用的一個軟件解決方案，其功能類似與heartbeat 用來防止單點故障
keepalived的工作原理是VRRP（Virtual Router Redundancy Protocol）虛擬路由冗余協議。
在VRRP中有兩組重要的概念：VRRP路由器和虛擬路由器，主控路由器和備份路由器。
VRRP路由器是指運行VRRP的路由器，是物理實體，虛擬路由器是指VRRP協議創建的，是邏輯概念。一組VRRP路由器協同工作，共同構成一臺虛擬路由器。 Vrrp中存在著一種選舉機制，用以選出提供服務的路由即主控路由，其他的則成了備份路由。當主控路由失效後，備份路由中會重新選舉出一個主控路由，來繼續工作，來保障不間斷服務。
二 keepalived安裝配置
1 在master和slave上安裝軟件包keepalived
安裝keepalived軟件包和服務控制
在編譯安裝keepalived之前，必須安裝內核開發包 kernel-devel 以及 openssl-devel popt-devel 等支持
若沒有安裝通過rom或者yum工具安裝
編譯安裝keepalived
使用指定的linux內核位置對keepalived進行配置，並將安裝路徑制定為根目錄，這樣就無需額外創建連接文件，配置完成 依次執行make make install 進行安裝
使用keepalived服務
執行make install操作之後 會自動生成/etc/init.d/keepalived腳本文件，但是需要手動添加為系統服務，這樣就可以使用server chkconfig 工具對keepalived服務進程管理了
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.0.100
}
}
virtual_server 192.168.0.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 與端口之間用空格隔開
註：slave 上此處改為 192.168.0.7(即 slave 本機 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//健康檢查端口
}
}
}
啟動 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，內容如下：
4、測試
在 master 和 slave 分別執行 ipaddr show dev eno16777736 命令查看 master和 slave 對 VIP
（群集虛擬 IP）的控制權。
Master1 主的查看結果：
Slave查看結果 並在master停止mysql 查看IP地址是否飄逸
總結：
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 最
新版本，利用多線程復制的方式可以很大程度降低復制延遲；
mysql高可用+keepalived