MySQL在互聯(lián)網(wǎng)應用中已經(jīng)遍地開花，但是在銀行系統(tǒng)中，還在生根發(fā)芽的階段。本文記錄的是根據(jù)某生產(chǎn)系統(tǒng)實際需求，對數(shù)據(jù)庫高可用方案從需求、各高可用技術特點對比、實施、測試等過程進行整理，完善Mysql高可用方案，同時為后續(xù)開展分布式數(shù)據(jù)庫相關測試做相應準備。
成都創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設、高性價比合江網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式合江網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設找我們，業(yè)務覆蓋合江地區(qū)。費用合理售后完善，十年實體公司更值得信賴。
存儲復制技術： 傳統(tǒng)IOE架構下，常用高可用方案，靠存儲底層復制技術實現(xiàn)數(shù)據(jù)的一致性，優(yōu)點數(shù)據(jù)安全性有保障，限制在于是依賴存儲硬件，實施成本較高。
keepalived+雙主復制： 兩臺MySQL互為主從關系，即雙主模式，通過Keepalived配置虛擬IP，實現(xiàn)當其中的一臺數(shù)據(jù)庫故障時，自動切換VIP到另外一臺MySQL數(shù)據(jù)庫，備機快速接管業(yè)務來保證數(shù)據(jù)庫的高可用。
MHA： MHA部署在每臺mysql服務器上，定時探測集群中的master節(jié)點，當master出現(xiàn)故障時，它可以自動將最新的slave提升為新的master，然后將所有其他的slave重新指向新的master，優(yōu)點在最大程度保證數(shù)據(jù)的一致性的前提下實現(xiàn)快速切換，最少需要3臺服務器，存在數(shù)據(jù)丟失的可能性。
PXC： Percona eXtra Cluster是Percona基于galera cluster封裝的集群方案。不同于普通多主復制，PXC保障強一致性和實時同步，故障切換更快。但是也需要3個節(jié)點，配置相對復雜，對性能也稍有影響。
除了上述方案外，還有MMM、Heartbeat+DRBD等高可用方案，此處不做詳細介紹。
綜合評估下，本次實施采用了 keepalived+mysql雙主實現(xiàn)數(shù)據(jù)庫同城雙機房的高可用。MySQL版本為： 5.7.21。操作系統(tǒng)：Red Hat Enterprise Linux Server 7.3。
配置過程如下：
Mysql-master1: IP地址1 --以下簡稱master1
Mysql-master2: IP地址2 --以下簡稱master2
Mysql-vip : VIP地址 --應用連接使用
Mysql復制相關概念描述：
1、 Mysql主從復制圖示：
2、 Mysql主從復制過程描述：
（1）master記錄二進制日志：在每個事務更新數(shù)據(jù)完成之前，master在二進制日志記錄這些改變。MySQL將事務寫入二進制日志。在事務寫入二進制日志完成后，master通知存儲引擎提交事務。
（2）slave將master的binarylog拷貝到自己的中繼日志：首先，slave開始一個工作線程——I/O線程。I/O線程在master上打開一個普通的連接，然后開始binlog dump process。Binlog dump process從master的二進制日志中讀取事務，如果已經(jīng)同步了master，它會睡眠并等待master產(chǎn)生新的事件。I/O線程將這些事務寫入中繼日志。
（3）SQL slave thread處理該過程的最后一步：SQL線程從中繼日志讀取事務，并重放其中的事務而更新slave的數(shù)據(jù)，使其與master中的數(shù)據(jù)一致。只要該線程與I/O線程保持一致，中繼日志通常會位于OS的緩存中，所以中繼日志的開銷很小。
主主同步就是兩臺機器互為主的關系，在任何一臺機器上寫入都會同步至備端。
為了便于后續(xù)數(shù)據(jù)庫服務器的擴展，且在整個復制環(huán)境中能夠自動地切換，降低運維成本，引入了當前主流的基于Mysql GTID的復制特性，工作原理及優(yōu)缺點簡介如下。
3、 GTID工作原理簡介：
（1） master更新數(shù)據(jù)時，會在事務前產(chǎn)生GTID，一同記錄到Binlog日志中。
（2） slave的I/O線程將變更的binlog寫入到本地的relay log中。
（3） slave的sql線程從relay log中獲取GTID，然后對比slave端的binlog是否有記錄。
（4） 如果有記錄說明該GTID的事務已經(jīng)執(zhí)行，slave會忽略。
（5） 如果沒有記錄，slave就會從relay log中執(zhí)行該GTID的事務，并記錄到binlog。
（6） 在解析的過程中會判斷是否有主鍵，如果有就用索引，如果沒有就用全部掃描。
4、 GTID優(yōu)點：
（1） 一個事務對應一個唯一的ID，一個GTID在一個服務器上 只會執(zhí)行一次。（2） GTID是用來替代傳統(tǒng)復制的方法，GTID復制與普通復制模式的最大不同就是不需要指定二進制文件名和位置。
（3） 減少手工干預和降低服務故障時間，當主機宕機之后會通過軟件從眾多的備機中提升一臺備機為新的master。
5、 GTID也存在一些限制：
（1） 不支持非事務引擎。
（2） 不支持create table … select 語句復制(主庫直接報錯)。
（3） 不允許一個sql同時更新一個事務引擎表和非事務引擎表。
（4） 在一個復制組中，必須要求統(tǒng)一開啟GTID或者是統(tǒng)一關閉GTID。
（5） 開啟GTID需要重啟(5.7版本除外)。
（6） 開啟GTID后，就不再使用原理的傳統(tǒng)復制方式。
（7） 不支持create temporary table 和 drop temporary table語句。
（8） 不支持sql_slave_skip_counter。
前置條件：
主備兩個節(jié)點使用行內(nèi)統(tǒng)一的安裝部署腳本安裝mysql5.7.21介質(略)
Master1端創(chuàng)建應用的數(shù)據(jù)庫(略)
1、 修改MySQL配置文件
參考相關配置規(guī)范，分別設置master1、master2的my點吸煙 f文件，
其中server-id參數(shù)設置為不同值;
由于后續(xù)keepalived會掛起VIP，應用通過VIP連接數(shù)據(jù)庫，為了避免應用程序無法通過VIP訪問，需將兩個節(jié)點的bind-address參數(shù)注釋掉；
2、 設置master1端自動半同步模式
Mysql的同步模式主要有如下3種：
a. 主從同步復制：數(shù)據(jù)完整性好，但是性能消耗略高；
b. 主從異步復制：性能消耗低，但容易出現(xiàn)不一致；
c. 主從半自動復制：介于上述兩種之間，既保持了數(shù)據(jù)的完整性，又提高了性能；
基于上述特性，建議采用半自動同步模式，由于后續(xù)要配置為雙主模式，因此任一節(jié)點其角色既為master又為slave，因此相關的master/slave插件要同時配置，過程如下。
（1） 首先查看庫是否支持動態(tài)加載(默認都支持)
（2） 主從庫上分別安裝插件
作為主庫，安裝插件semisync_master.so
作為從庫，安裝插件semisync_slave.so
（3） 安裝完成后，從plugin表中能夠看到剛剛安裝的插件
（4） 分別打開主從庫半同步復制
同時添加到各自的my點吸煙 f中，在后續(xù)數(shù)據(jù)庫實例重啟時自動加載該配置。
此時查看狀態(tài)還沒有啟動
（5） 兩個節(jié)點分別啟動IO進程
（6） 查看半同步狀態(tài)
3、 將master1設為master2的主服務器
（1）在master1主機上創(chuàng)建授權賬戶，允許在master2主機上連接
（2）將主庫master1數(shù)據(jù)導出
（3）將master.sql傳輸?shù)絤aster2上并導入
（4）在master2端將master1設置為自己的主庫，并開啟slave功能
在master2上查看slave狀態(tài)
至此master1到master2的主從復制關系已經(jīng)建立完成。
4、 將master2設為master1的主服務器
在master1上執(zhí)行
在master1上查看slave狀態(tài)
1、keepalived相關概念說明：
keepalived是集群管理中保證集群高可用的一個軟件解決方案，其功能類似于heartbeat，用來防止單點故障
keepalived是以VRRP協(xié)議為實現(xiàn)基礎的，VRRP全稱VirtualRouter Redundancy Protocol，即虛擬路由冗余協(xié)議。
虛擬路由冗余協(xié)議，可以認為是實現(xiàn)路由器高可用的協(xié)議，即將N臺提供相同功能的路由器組成一個路由器組，這個組里面有一個master和多個backup，master上面有一個對外提供服務的vip，master會發(fā)組播（組播地址為224.0.0.18），當backup收不到vrrp包時就認為master宕掉了，這時就需要根據(jù)VRRP的優(yōu)先級來選舉一個backup當master，這樣的話就可以保證路由器的高可用了。
keepalived主要有三個模塊，分別是core 、check和vrrp。core模塊為keepalived的核心，負責主進程的啟動、維護以及全局配置文件的加載和解析。check負責 健康 檢查，包括常見的各種檢查方式。vrrp模塊是來實現(xiàn)VRRP協(xié)議的。同時為了避免出現(xiàn)腦裂，應關閉防火墻或者開啟防火墻但允許接收VRRP協(xié)議。
2、keepalived的安裝配置
（1）配置本地yum源，在master1和master2兩臺服務器上安裝keepalived的相關依賴包Kernel-devel/openssl-devel/popt-devl等
配置指向rhel-7.5.iso的yum本地源，步驟略
注意：如不知道keepalived需要哪些依賴包，可到下載后的源碼解壓目錄下查看INSTALL 文件內(nèi)容，安裝需要的依賴包，源碼安裝任何一個軟件都要養(yǎng)成查看源碼包文檔的習慣，比如INSTALL，README,doc等文檔，可以獲得很多有用的信息。
（2）在兩臺mysql上解壓縮并編譯安裝keepalived
（3）master1、master2上分別配置keepalived.conf
注意上圖紅色字體中兩個節(jié)點配置相同處及差異。
說明：keepalived只有一個配置文件keepalived.conf，里面主要包括以下幾個配置區(qū)域：
· global_defs：主要是配置故障發(fā)生時的通知對象以及機器標識。
· vrrp_instance：用來定義對外提供服務的VIP區(qū)域及其相關屬性。
· virtual_server：虛擬服務器定義
（4）同時兩個節(jié)點上都需要添加檢測腳本
作用：是當mysql停止工作時自動關閉本機的keeplived服務，從而實現(xiàn)將故障主機踢出熱備組，因每臺機器上keepalived只添加了本機為realserver，所以當mysqld正常啟動后，我們還需要手動啟動keepalived服務。
（5）分別啟動兩個節(jié)點的keepalived服務
檢查兩個節(jié)點keepalived啟動進程
檢查兩個節(jié)點的vip掛載情況
（6）主備機故障切換測試
停止master2的mysql服務，看keepalived 健康 檢查程序是否會觸發(fā)腳本，自動進行故障切換，步驟略
查看master1節(jié)點的VIP掛載情況，驗證是否實現(xiàn)了自動切換，步驟略
說明在master2服務器的mysql服務發(fā)生故障時，觸發(fā)了腳本，自動完成了切換。
（7）現(xiàn)在我們把master2的mysql服務開起來，并且keepalived的服務也需要啟動。
即便master2的mysql服務和keepalived服務都重新開啟了，master1仍然是主master了，master2未對主master的權利進行搶奪，說明設置的nopreempt參數(shù)生效了，為了保證群集的穩(wěn)定性，生產(chǎn)環(huán)境不允許搶占配置，只有當master1的mysql服務壞掉的時候，master2才會再次成為主master，否則它永遠只能當master1的備份。（注：nopreempt一般是在優(yōu)先級高的mysql上設置）
Sysbench是一個模塊化的、跨平臺、多線程基準測試工具，可用于評估數(shù)據(jù)庫負載情況，通過sysbench命令配置IP地址、端口號、用戶名、密碼連接到指定的數(shù)據(jù)庫db1中，創(chuàng)建多個表，并快速插入指定條數(shù)的記錄，觀察主備庫同步效率
(1) 下載開源工具sysbench-0.4.12.14.tar.gz，放置在相應目錄下并解壓
(2) 使用iso配置本地yum源并安裝Sysbench如下的依賴包(步驟略)：autoconf/automake/cdbs/debhelper(=9)/docbook-xml/docbook-xsl/libmysqlclient15-dev/libtool/xsltproc
(3) 編譯sysbench
編輯配置文件/etc/ld.so.conf中添加mysql lib目錄/mysql/app/5.7.21/lib，并執(zhí)行命令ldconfig生效
(4) 執(zhí)行sysbench壓測
使用sysbench工具向主節(jié)點的db1數(shù)據(jù)庫中創(chuàng)建5張表，并且每張表分別插入10萬條記錄
同時觀察備機同步效率
幾個重要的參數(shù)說明：
B、半自動同步模式、異步模式切換測試
(1) 檢查主備同步狀態(tài)，及同步參數(shù)設置
rpl_semi_sync_master_enabled參數(shù)表示啟用半同步模式；
rpl_semi_sync_master_timeout參數(shù)單位為毫秒，表示主庫事務等待從庫返回commit成功信息超過10秒就降為異步模式，不再等待從庫，等探測到從庫io線程恢復后，再返回為半自動同步；
rpl_semi_sync_master_wait_no_slave參數(shù)表示事務提交后需要等待從庫返回確認信息；
(2) 將slave的io線程停止
(3) 使用sysbench向master寫入少量的數(shù)據(jù)，本例創(chuàng)建一張表，并插入10條記錄，命令包裝在1.sh測試腳本中
通過記錄的時間戳發(fā)現(xiàn)，master在等待了slave10秒無響應，自動切換為異步模式，將數(shù)據(jù)寫入本地。
(4) Slave啟動io線程，數(shù)據(jù)自動追平
至此MySQL主主復制配置完成，運行在半自動同步模式，通過keepalived實現(xiàn)Mysql的HA高可用。
上線后應符合統(tǒng)一的標準監(jiān)控策略，添加備份協(xié)議對數(shù)據(jù)進行周期備份并保存到帶庫中，以及定期的數(shù)據(jù)恢復測試。
由于是靠keepalived實現(xiàn)的高可用，還應將如下資源添加到監(jiān)控管理平臺：
1、 對每臺數(shù)據(jù)庫主機的3個keepalived進程進行監(jiān)控；
2、 對主備節(jié)點的io線程、sql線程工作狀態(tài)進行監(jiān)控；
1、準備三臺虛擬機，選擇兩臺mysql作為keepalived（一臺master 一臺backup），一臺做客戶端訪問用。
2、給兩臺mysql安裝keepalived制作高可用生成VIP
我這里用的是mysqld
yum安裝mysql
實施步驟：
一、mysql 主主同步 略
二、安裝keepalived---兩臺機器都操作
三添加庫用于測試
四 在任意一臺機器作為客戶端
測試的時候記得檢查mysql用戶的可不可以遠程登錄。
實現(xiàn)了VIP的漂移，實現(xiàn)了mysql的高可用。
什么是高可用？高可用其實就是可以實現(xiàn)自動故障轉移。當主節(jié)點掛了之后其他節(jié)點可以自動頂上，防止節(jié)點出現(xiàn)故障時MySQL不能對外提供服務。
MySQL的高可用解決方案其實有很多種（想了解自行百度），這里只說其中一種：MHA。這也是當前比較主流的方案。
在搭建MHA之前應該先保證已經(jīng)安裝配置好了MySQL的主從/集群。因為既然是高可用架構，那么針對的肯定是多臺設備，單機的話談不上高可用。
MySQL的主從搭建過程這里就不說了，可以看這里： MySQL搭建主從架構
本次搭建環(huán)境：centos7.8 + mysql5.7.31
現(xiàn)在的架構是 ：
101：主節(jié)點
102：從節(jié)點1
103：從節(jié)點2
手動將101的MySQL主節(jié)點關閉，在102的節(jié)點上查看VIP，發(fā)現(xiàn)配置的VIP：192.168.232.105已經(jīng)從101節(jié)點漂移到102節(jié)點了。
然后在103的節(jié)點上可以看到主節(jié)點確實已經(jīng)變成了 102
到此，MHA 搭建大功告成啦！
MHA 的切換過程,共包括以下的步驟：
最后說明一點，宕機的節(jié)點，重啟后由于MySQL機制問題不會自動加入到集群中，需要我們手動加入。
重慶分公司
重慶分公司
