生産環境中一台 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。 Binlog dump 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 中有關複制的配置如下：
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 master
2 中有關複制的配置如下：
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=資料庫名”配置項（可以添加多個）來指定 要同步的資料庫
2、将 master1 設為 master2 的主伺服器 在 master1 主機上建立授權賬戶，允許在 master2(192.168.1.102)主機上連接配接
檢視 master1 的目前 binlog 狀态資訊
在 master2 上将 master1 設為自已的主伺服器并開啟 slave 功能。
檢視從的狀态，mysql>show slave status\G;以下兩個值必須為 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 的高可用性。 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 負責健康檢查，包括常見 的各種檢查方式。vrrp 子產品是來實作 VRRP 協定的。
二、keepalived 的安裝配置
1、在 master1 和 master2 上安裝軟體包 keepalived
安裝 keepalived 軟體包與服務控制
在編譯安裝 Keepalived 之前，必須先安裝核心開發包 kernel-devel 以及 openssl-devel、 popt-devel 等支援庫。
若沒有安裝則通過 rpm 或 yum 工具進行安裝
編譯安裝 Keepalived
注意：如不知道 keepalived 需要哪些依賴包，可到下載下傳後的源碼解壓目錄下檢視 INSTALL 文 件内容，+ 執行 make install 操作之後，會自動生成/etc/init.d/keepalived 腳本檔案，
Master2 主機也完成 keepalived 安裝，與 master1 一樣，安裝過程略
########################################################
（後邊有修改好的）
master1 主機上有關 keepalived.conf 檔案的具體配置如下：
啟動 keepalived 服務
#/etc/init.d/keepalived start
Master2 主機上的 keepalived.conf 檔案的修改：
可以使用 scp 指令把 server1 主機上配置好的 keepalived.conf 檔案拷貝到 server2 主機，隻要 做簡單修改即可，如下圖所示：
啟動 keepalived 服務
#/etc/init.d/keepalived start
3、#mkdir /etc/keepalived/bin
vi /etc/keepalived /bin/mysql.sh，内容如下：（根據需要輸入最後一行）
Master2 主機完成相同的操作
4、測試 在 master1 和 master2 分别執行 ip addr show dev eth0 指令檢視 master1 和 master2 對 VIP （群集虛拟 IP）的控制權。
Master1 主的檢視結果：
Master2 主的檢視結果：
從上圖可以看出 master1 是主伺服器，master2 為備用伺服器。
停止 MySQL 服務，看 keepaliv ed 健康檢查程式是否會觸發我們編寫的腳本 停止 master1 主機的 mysql 服務
Master2 主的檢視結果：
這說明在主服務上停止 MySQL 服務，觸發了我們編寫的腳本，進行自動故障切換。 MySQL 遠端登入測試
總結： 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 最 新版本，利用多線程複制的方式可以很大程度降低複制延遲；
轉載于:https://www.cnblogs.com/ljl1366136/p/9416341.html