優酷土豆資深工程師：MySQL高可用之MaxScale與MHA

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

 

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

1、MySQL高可用方案

2、為什么選擇MHA

3、讀寫分離方案的尋找以及為什么選擇Maxscale

 

一、MySQL  Failover的方案

 

常見的Failover方案

 

• MMM

 

MMM缺點：

1. Monitor節點是單點，可以結合Keepalived實現高可用目前MySQL Failover 的方案

2. Keepalived會有腦裂的風險

3. 在讀寫繁忙的業務中可能丟數據

4. MHA + ssh -o 測試心跳 + masterMHA_secondary_check(兩次檢測)

 

• MHA

 

MHA優點：

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

2. 識別含有最新更新的Slave

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

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

5. 提升一個Slave為新的Master

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

7. MariaDB Replication Manager (MRM)

 

只支持MariaDB with GTID based replication topologies

 

二、MHA

 

今天主要說下MHA。MHA可以說是強一致的主從切換工具 ，而且切換間隔小於30s，非常適合在線上使用。

 

具體原理

 

 

 

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

2. 識別含有最新更新的Slave

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

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

5. 提升一個Slave為新的Master

6. 使其他的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：

1. MHA默認沒有arping，這個要自己加上，否則服務器會自動等到vip緩存失效，期間VIP會有一定時間的不可用

2. masterha_manager 命令行中加入--ignore_last_failover 否則再次切換會失敗，除非刪除app1.failover.complete文件

3. vip 我們沒有使用keepalive，是在兩個主機上插網線, 如eth1，將vip加到 master 的eth1上

4. 要將備主的對應網卡激活

5. report_script=/usr/bin/send_report  發郵件的功能要加上

6. slave不要延遲過長，延遲越久，切換也越久

7. 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)

8. grep -i 'change  master'  manager.log   可以找到change master to 語句 ，可以在切換后舊的主庫上執行

9. 設置 ignore_fail = 1 這樣即使slave 有錯誤，也會切換

10. 設置ssh 的 timeout 防止ssh連接慢時，MHA發生切換

 

7、MHA manager 管理多實例

 

 

 

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

 

Tips：

如果覺得MHA部署麻煩，還要自己寫腳本，可以使用MHA_helper

web:https://github.com/ovaistariq/MHA-helper

 

SQL-aware負載均衡器：

 

1. MySQL proxy：官方不維護了

2. MySQL Router：官方維護，比較簡單

3. MaxScale：插件式，定制靈活，自動檢測MySQL master failure

4. Amoeba：支持sql過濾，讀寫分離，sharding，不支持 MySQL Failover

5. Cobar：支持分庫，不支持分表

6. MyCat：基於Cobar的二次開發

7. TDDL(Taobao Distributed Data Layer)：阿里自研的基於client模式的讀寫分離的中間件

 

三、Maxscale

 

這里想要介紹的是Maxscale。

 

 

 

Maxscale有哪些優點呢，一句話，上面這些中間件有的優點，它基本都有。

 

1. 帶權重的讀寫分離(負載均衡)

2. SQL防火牆

3. 多種路由策略(Connection based， Statement based，Schema based)

4. 自動檢測MySQL master Failover (配合MHA或者MRM)

5. 檢測主從延時

6. 多租戶sharding架構

 

架構比較

 

大多數互聯網公司的db架構

 

 

隱患：一般的互聯網公司會使用MHA做Failover ， 然后使用LVS在讀庫上做負載均衡，但是LVS走的TCP協議，當read 庫掛掉，LVS也不會將其踢掉，另外LVS對長連接的應用支持的不好， 因為由於LVS的檢查時長一般在30s， 但是長連接的設置一般都是30分鍾，或者不設置timwout，這樣，當業務端 斷開連接后，LVS還認為它會死活着的， 所以 連接到db的thread卻並不減少。造成thead_connected 打滿，MySQL不可用。

 

使用Maxscale的db層架構

 

 

 

規避了使用LVS時候的長鏈接超時不斷開問題。

 

Maxscale配置很簡單

 

1. yum -y install Maxscale (只在Maxscale上執行)

2. cp MaxScale_template.cnf  Maxscale.cnf

3. 生成密碼：

   maxkeys /var/lib/maxscale/

   maxpasswd /var/lib/maxscale/ maven119

4. 修改配置文件

   需要的單獨找我吧，太長了配置文件……

 

通過管理命令，查看狀態

 

 

 

可以看到目前有兩台db，以及運行狀態

 

 

看到開啟了什么服務讀寫分離和client

 

下面來做一下結單的測試：

 

MySQL master節點：

 

 

 

4 rows in set (0.00 sec)

 

MySQL slave節點，多增加一條記錄。

 

 

 

發現讀打在了從庫。

 

如果想讓讀搭載主庫上 ，可以把select語句放到事務中。

 

 

 

具體的讀寫情況可以使用general_log觀察。

 

在 master 節點執行 ：

 

set global general_log=1;

 

在Maxscale節點執行 ：

 

 

發現寫打在了主庫上。

 

 

 

Tips:

1. 如果想要在master上讀

2. 可以把select語句放到事務中begin;select;commit

3. Maxscale會對每個slave做健康檢查，原理與pt-heartbeat一樣的。主庫插入時間戳，到slave與serevr時間對比。

4. gnoring secrets file /var/lib/maxscale/.secrets, invalid permissions .secrets的權限不對 chown maxscale:maxscale .secrets

5. 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這兩個不能配。

好書相送

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