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

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

 

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

一、MySQL高可用方案

二、爲何選擇MHA

三、讀寫分離方案的尋找以及爲何選擇Maxscale

 

1、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

 

2、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

 

一、管理節點

 

 

 

二、數據節點

 

 

 

三、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:

一、下降數據丟失風險

innodb_flush_log_at_trx_commit=1

innodb_support_xa=1

sync_binlog =1

gtid

半同步複製或者5.7的加強半同步

binlog_format 爲RBR

 

二、主從一致檢測

pt-table-checksum 

pt-table-sync

pt-online-schema-change 雖然5.6 支持ddl online ,我仍是建議使用pt-osc ,可是注意：若是binlog_format爲SBR , 使用pt-osc 會有主鍵衝突的風險

 

四、MHA配置

 

1）ssh 配置

ansible 來作

 

2）安裝MHA

yum install -y --nogpgcheck MHA4MySQL-*(已經下載好了) 在每一個節點都執行

 

3）編輯文件

 

 

 

 

 

4）清理relay log

 

slave上的relay_log_purge是關閉的，在MHA環境中，failover時，會用到relay log來對比差別日誌，將差別日誌發送到其餘slave上，進行回放

 

 

 

五、MHA環境監測

 

檢查MHA環境

 

 

 

啓動MHA manager

 

 

六、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發生切換

 

七、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模式的讀寫分離的中間件

 

3、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這兩個不能配。

好書相送

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