講師介紹
侯野優酷洋芋資深資料庫工程師
擅長orale、mysql故障診斷、性能調優，目前專注于mysql的高可用技術。
曾任職于大連東軟、清華紫光、觸控科技等公司，服務過華夏銀行、中國華能電力集團，擔任oracledba、oracle進階咨詢顧問。
本次分享主要包括以下内容：
1、mysql高可用方案
2、為什麼選擇mha
3、讀寫分離方案的尋找以及為什麼選擇maxscale
一、mysql failover的方案
常見的failover方案
mmm
mmm缺點：
monitor節點是單點，可以結合keepalived實作高可用目前mysql failover 的方案
keepalived會有腦裂的風險
在讀寫繁忙的業務中可能丢資料
mha + ssh -o 測試心跳 + mastermha_secondary_check(兩次檢測)
mha
mha優點：
從當機崩潰的master儲存二進制日志事件(binlogevent)
識别含有最新更新的slave
應用差異的中繼日志(relaylog)到其他slave
應用從master儲存的二進制日志事件
提升一個slave為新的master
使其他的slave連接配接新的master進行複制
mariadb replication manager (mrm)
隻支援mariadb with gtid based replication topologies
二、mha
今天主要說下mha。mha可以說是強一緻的主從切換工具 ，而且切換間隔小于30s，非常适合線上上使用。
具體原理
mha組成
rpm -ql mha4mysql-manager-0.56-0.el6.noarch
1、管理節點
2、資料節點
3、mysql的配置要點
安裝配置mha
1）mysql主從
mysql一主兩從(一個candidate_master)
master：
slave：
mysql主從搭建 (一主兩從)
1）mysql主從配置
建立使用者
備份
mysqldump --master-data=2 --single-transaction -a > bk.sql (我們生産上不允許使用函數和存儲過程)
tips：如果不是建立db，建議使用mydumper(slave)或者innobackupex(master) 備份
從庫執行
a.将bk.sql 在從庫恢複
b.執行
c.如果開啟gtid
tips:
1、降低資料丢失風險
innodb_flush_log_at_trx_commit=1
innodb_support_xa=1
sync_binlog =1
gtid
半同步複制或者5.7的增強半同步
binlog_format 為rbr
2、主從一緻檢測
pt-table-checksum
pt-table-sync
pt-online-schema-change 雖然5.6 支援ddl online ,我還是建議使用pt-osc ,但是注意：如果binlog_format為sbr , 使用pt-osc 會有主鍵沖突的風險
4、mha配置
1）ssh 配置
ansible 來做
2）安裝mha
yum install -y --nogpgcheck mha4mysql-*(已經下載下傳好了) 在每個節點都執行
3）編輯檔案
4）清理relay log
slave上的relay_log_purge是關閉的，在mha環境中，failover時，會用到relay log來對比差異日志，将差異日志發送到其他slave上，進行回放
5、mha環境監測
檢查mha環境
啟動mha manager
6、mha切換測試
1）模拟執行個體cresh
/etc/init.d/mysql stop
2）模拟主機cresh
echo a > /proc/sysrq-trigger
3）使用iptables
iptables -a input -p tcp -m iprange --src-range 192.168.10.1-192.168.10.241 --d port 3306 -j drop
ps.可以在master節點跑sysbench，在壓測的過程中來做以上測試
tips：
mha預設沒有arping，這個要自己加上，否則伺服器會自動等到vip緩存失效，期間vip會有一定時間的不可用
masterha_manager 指令行中加入--ignore_last_failover 否則再次切換會失敗，除非删除app1.failover.complete檔案
vip 我們沒有使用keepalive，是在兩個主機上插網線, 如eth1，将vip加到 master 的eth1上
要将備主的對應網卡激活
report_script=/usr/bin/send_report 發郵件的功能要加上
slave不要延遲過長，延遲越久，切換也越久
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.10.100 -s 192.168.10.101 --user=root --master_host=maven119 --master_ip=192.168.10.88 --master_port=3306 這樣隻有當兩個manager都ping不通才會切換，防止資料不一緻(注意修改masterha_secondary_check 中ssh的端口号，他是寫死的22)
grep -i 'change master' manager.log 可以找到change master to 語句 ，可以在切換後舊的主庫上執行
設定 ignore_fail = 1 這樣即使slave 有錯誤，也會切換
設定ssh 的 timeout 防止ssh連接配接慢時，mha發生切換
7、mha manager 管理多執行個體
這樣就完成多執行個體的部署。
如果覺得mha部署麻煩，還要自己寫腳本，可以使用mha_helper
web:https://github.com/ovaistariq/mha-helper
sql-aware負載均衡器：
mysql proxy：官方不維護了
mysql router：官方維護，比較簡單
maxscale：插件式，定制靈活，自動檢測mysql master failure
amoeba：支援sql過濾，讀寫分離，sharding，不支援 mysql failover
cobar：支援分庫，不支援分表
mycat：基于cobar的二次開發
tddl(taobao distributed data layer)：阿裡自研的基于client模式的讀寫分離的中間件
三、maxscale
這裡想要介紹的是maxscale。
maxscale有哪些優點呢，一句話，上面這些中間件有的優點，它基本都有。
帶權重的讀寫分離(負載均衡)
sql防火牆
多種路由政策(connection based， statement based，schema based)
自動檢測mysql master failover (配合mha或者mrm)
檢測主從延時
多租戶sharding架構
架構比較
大多數網際網路公司的db架構
隐患：一般的網際網路公司會使用mha做failover ， 然後使用lvs在讀庫上做負載均衡，但是lvs走的tcp協定，當read 庫挂掉，lvs也不會将其踢掉，另外lvs對長連接配接的應用支援的不好， 因為由于lvs的檢查時長一般在30s， 但是長連接配接的設定一般都是30分鐘，或者不設定timwout，這樣，當業務端 斷開連接配接後，lvs還認為它會死活着的， 是以 連接配接到db的thread卻并不減少。造成thead_connected 打滿，mysql不可用。
使用maxscale的db層架構
規避了使用lvs時候的長連結逾時不斷開問題。
maxscale配置很簡單
yum -y install maxscale (隻在maxscale上執行)
cp maxscale_template.cnf maxscale.cnf
生成密碼：
maxkeys /var/lib/maxscale/
maxpasswd /var/lib/maxscale/ maven119
修改配置檔案
需要的單獨找我吧，太長了配置檔案……
通過管理指令，檢視狀态
可以看到目前有兩台db，以及運作狀态
看到開啟了什麼服務讀寫分離和client
下面來做一下結單的測試：
mysql master節點：
4 rows in set (0.00 sec)
mysql slave節點，多增加一條記錄。
發現讀打在了從庫。
如果想讓讀搭載主庫上 ，可以把select語句放到事務中。
具體的讀寫情況可以使用general_log觀察。
在 master 節點執行 ：
set global general_log=1;
在maxscale節點執行 ：
發現寫打在了主庫上。
如果想要在master上讀
可以把select語句放到事務中begin;select;commit
maxscale會對每個slave做健康檢查，原理與pt-heartbeat一樣的。主庫插入時間戳，到slave與serevr時間對比。
gnoring secrets file /var/lib/maxscale/.secrets, invalid permissions .secrets的權限不對 chown maxscale:maxscale .secrets
maxscale 1.4版本做了很多的改進
重要概念dcb
從這種圖中可以看出來dcb的重要性了，callback 最後走到了 dcb.h
那麼什麼是dcb呢？
一個dcb（descriptor control block）表示一個在maxscale内部的連接配接的狀态，每個來自client的連接配接、到後端server的連接配接、以及每個listener都會被配置設定一個dcb，這些連接配接的狀态統計由這些dcb來完成。每個dcb并不會有特定的名字用于查詢，而是直接使用具有唯一性的記憶體位址。
maxscale的mha
官方推薦使用lsyncd或者corosync-pacemaker。
個人認為maxscale的一些想法是不錯的，包括percona也生成maxscale是目前最好的讀寫分離中間件。目前還不是很成熟，小項目可以試試。大型項目還是推薦tddl這種經過生産實踐的中間件。
maxscale與mha整合
maxscale與mha整合其實非常簡單，一般mha都會讓 開發使用vip。master宕掉後，slave接管，對前端是透明的。
在與maxscale結合的時候，maxscale.conf檔案不需要改變任何東西，隻需要在後端将mha部署上就可以。因maxscale可以監控mysql的主從變更。
總結：maxscale與mha整合，隻需要安裝mha即可。
寫在最後，對已有的mysql主從環境上mha和maxscale幾乎不需要更改任何配置。隻需要更改開發架構中的配置 ，把原ip和端口改寫為maxscale server的ip和端口即可。
q&a
q1：請問，這個10.10.111.1是部署maxscale伺服器的實體ip嗎，部署maxscale的伺服器是不是也需要兩台伺服器做ha？就一台伺服器的話要是意外當機豈不是會導緻整個應用癱瘓？還是說我了解錯了？
a1：官方推薦使用lsyncd或者corosync-pacemaker做maxscale的ha。
q2：監控系統是自主研發的還是采用開源的？都是以哪些為監控名額來監控性能和穩定性的？
a2：pt-heartbeat來實時監控主從狀态，pt-heartbeat可以一秒。
q3：一直不明白挺好的東西為啥不用，非要主從之間切來切去？
a3：可能場景不同,我們一般都會有4台db做master-slave，主要是需要擴容讀庫。優酷基本上是讀大于寫。
q4：slave-skip-errors = 1062,1032,1060這類配置你們用嗎？
a4：用。但是1062,1032這兩個不能配。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-07-29</b>