本文根據DBAplus社群第67期線上分享整理而成

本次分享主要包括以下內容：

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，非常適合在線上使用。

具體原理

從宕機崩潰的Master保存二進制日志事件(binlogevent)

識別含有最新更新的Slave

應用差異的中繼日志(relaylog)到其他Slave

應用從Master保存的二進制日志事件

提升一個Slave為新的Master

使其他的Slave連接新的Master進行復制

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 管理多實例

這樣就完成多實例的部署。

Tips：

如果覺得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節點執行 ：

發現寫打在了主庫上。

Tips:

如果想要在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這兩個不能配。

好書相送

在本文微信評論區留下足以引起共鳴的真知灼見，

總結

以上是生活随笔為你收集整理的优酷土豆资深工程师：MySQL高可用之MaxScale与MHA的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。