• 今日內容概述
• 今日內容詳細
  • 1.MHA高可用概述
  • 2.MHA的工作原理
    • MHA的組成
    • MHA自動故障切換的步驟
  • 3.MHA的優點總結
  • 4.GTID主從複製
    • 什麼是GTID主從複製？
    • GTID主從的原理
      • 1）一個GTID的生命週期
      • 2）圖解
  • 5.GTID主從複製的優缺點
    • GTID的優點
    • GTID的缺點
  • 6.GTID主從複製部署
    • 環境準備
    • 主庫配置
    • 從庫配置
    • 建立MHA管理使用者
    • 設定從庫可讀
    • 關閉MySQL自動清除relaylog的功能
  • 7.MHA部署
    • 配置免密登入（所有主機之間互做）
    • 安裝依賴包（所有機器都執行）
    • 然後再去manager主機安裝manager包
    • 配置MHA Manager
    • 修改配置
    • 檢測mha配置狀態
    • 啟動MHA

今日內容概述

1.MHA高可用概述
2.MHA的工作原理
3.MHA的優點總結
4.GTID主從複製
5.GTID主從複製的優缺點
6.GTID主從複製部署
7.MHA部署
 

今日內容詳細

1.MHA高可用概述

# MHA簡介
MHA（Master High Availability）是由日本人 yoshinorim（原就職於DeNA現就職於FaceBook）開發的一款成熟的、開源的 MySQL 的高可用程式。它為 MySQL 主從複製架構提供了自動故障切換（ automating master failover） 功能。 MHA 在監控到 master 節點故障時，會提升其中擁有最新資料的 slave 節點成為新的master 節點，在此期間，MHA 會通過於其它從節點獲取額外資訊來避免一致性方面的問題，從而在最大程度上保證資料的一致性，以達到真正意義上的高可用，而且整個故障轉移過程對應用程式完全透明。最值得稱讚的一點是：這一自動故障切換操作，MHA能在10~30秒之內完成。	# 然而對資料庫而言還是太久了

此外，MHA 還提供了 master 節點的線上切換功能，即按需切換 master/slave 節點，大概0.5-2秒內即可完成。

目前MHA主要支援一主多從的架構，要搭建MHA,要求一個複製叢集中必須最少有三臺資料庫伺服器，例如一主二從。因為至少需要三臺伺服器，出於機器成本的考慮，淘寶也在該基礎上進行了改造，目前淘寶的TMHA已經支援一主一從。
 

2.MHA的工作原理

MHA的組成

MHA由node和manager組成
1.MHA Node(資料節點:
相當於監控客戶端，所有機器都需要部署node

2.MHA Manager(管理節點)
Manager相當於服務端，MHA Manager會定時探測叢集中的master節點，當master出現故障時，它可以自動將最新資料的slave提升為新的master，然後將所有其他的slave重新指向新的master（如果原主庫恢復，只能當從庫）。

通常單獨部署在一臺獨立機器上管理多個master/slave叢集（組），每個master/slave叢集稱作一個 application，用來管理統籌整個叢集。

Manager應該儘量避免部署在主庫上，否則主庫一掛則全掛，不僅主庫完蛋了，負責自動遷移的Manager也完蛋了，也沒人負責自動故障遷移了，導致架構不可用了。

可以考慮部署在某一個slave上，此時這臺主機掛掉了，只是掛了一個slave，以及Manager需要注意的一點是：如果Manager部署在slave上，那麼該slave就無法被升級為主庫；

# 如下圖我們可以看出，每個複製組內部和Manager之間都需要ssh實現無密碼互聯，只有這樣，在Master出故障時，Manager才能順利的連線進去，實現主從切換。
 

MHA自動故障切換的步驟

1.Manager會每隔3秒鐘探測一次MASTER主庫	# 檢測主庫是否存活

2.如果Manager探測到MASTER主庫故障、無法訪問，Manager會執行下面操作：
從其他node發起ssh連線，檢查主庫是否能夠SSH上去
從其他node發起mysql連線，檢查MASTER庫是否能夠登陸

3.如果所有的Node節點ssh連線、mysql主庫連線均連線失敗，則開始故障轉移
簡單概括下步驟為：
	1.）找到資料最新的從庫（通過對比relay-log，檢視show slave status即可）
	2.）將最新的從庫上的新資料同步到其他從庫
	3.）提升一個從庫為主庫（一般情況提升資料最新的，二般情況提升我們指定的從庫為主庫）
	4.）通過原來主庫的binlog補全新的主庫資料
	5.）其他從庫以新的主庫為主做主從複製

3.MHA的優點總結

1. 自動的故障檢測與轉移，通常在10-30秒以內
2. MHA還提供線上主庫切換的功能，能夠安全地切換當前執行的主庫到一個新的主庫中(通過將從庫提升為主庫),大概0.5-2秒內即可完成。
3. 很好地解決了主庫崩潰資料的一致性問題。
4. 不需要對當前的mysql環境做重大修改。
5. 不需要在現有的複製框架中新增額外的伺服器，僅需要一個manager節點，而一個Manager能管理多套複製，所以能大大地節約伺服器的數量。
6. 效能優秀，可以工作在半同步和非同步複製框架，支援gtid，當監控mysql狀態時，僅需要每隔N秒向master傳送ping包(預設3秒)，所以對效能無影響。你可以理解為MHA的效能和簡單的主從複製框架效能一樣。
7. 只要replication支援的儲存引擎都支援MHA，不會侷限於innodb。
8. 對於一般的keepalived高可用，當vip在一臺機器上的時候，另一臺機器是閒置的，而MHA中並沒有閒置的主機。

4.GTID主從複製

什麼是GTID主從複製？

從MySQL 5.6.2 開始新增了一種基於 GTID 的複製方式，用以替代以前傳統的複製方式，到MySQL5.6.10後逐漸完善。通過 GTID 保證了每個在主庫上提交的事務在叢集中有一個唯一的ID。這種方式強化了資料庫的主備一致性，故障恢復以及容錯能力.

在MHA自動故障切換過程中，MHA試圖從宕機的主伺服器上儲存二進位制日誌，最大程度的保證資料的不丟失，但這並不總是可行的。例如，如果主伺服器硬體故障或無法通過ssh訪問，MHA沒法儲存二進位制日誌，只進行故障轉移而丟失了最新的資料。使用自MySQL 5.5開始引入的半同步複製，可以大大降低資料丟失的風險。

MHA可以與半同步複製結合起來。如果只有一個slave已經收到了最新的二進位制日誌，MHA可以將最新的二進位制日誌應用於其他所有的slave伺服器上，因此可以保證所有節點的資料一致性，或者採用GTID。

要想在分散式叢集環境中不丟失事務，就必須為每個事務定製一個全域性唯一的ID號，並且該ID是趨勢遞增的，以此我們便可以方便地順序讀取、不丟事務，其實GTID就是一種很好的分散式ID實踐方案，它滿足分佈ID的兩個基本要求:
# 全域性唯一性
# 趨勢遞增
  
GTID (Global Transaction ID全域性事務ID)是如何做到全域性唯一且趨勢遞增的呢，它是由UUID+TID兩部分組成。
# UUID是資料庫例項的識別符號
# TID表示事務提交的數量，會隨著事務的提交遞增

因此它與主庫上提交的每個事務相關聯,GTID不僅對其發起的伺服器是唯一的，而且在給定複製設定中的所有伺服器都是唯一的，即所有的事務和所有的GTID都是1對1的對映。

當在主庫上提交事務或者被從庫應用時，可以定位和追蹤每一個事務，對DBA來說意義就很大了，我們可以適當的解放出來，不用手工去可以找偏移量的值了，而是通過CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION=1的即可方便的搭建從庫，在故障修復中也可以採用MASTER_AUTO_POSITION= 'X' 的方式。
5.7版本GTID做了增強，不手工開啟也自動維護匿名的GTID資訊。

GTID主從的原理

1）一個GTID的生命週期

1.事務在主庫上執行並提交給事務分配一個gtid（由主庫的uuid和該伺服器上未使用的最小事務序列號），該GTID被寫入到binlog中。
 
2.備庫讀取relaylog中的gtid，並設定session級別的gtid_next的值，以告訴備庫下一個事務必須使用這個值
 
3.備庫檢查該gtid是否已經被其使用並記錄到他自己的binlog中。slave需要擔保之前的事務沒有使用這個gtid，也要擔保此時已分讀取gtid，但未提交的事務也不恩呢過使用這個gtid.
 
4.由於gtid_next非空，slave不會去生成一個新的gtid，而是使用從主庫獲得的gtid。這可以保證在一個複製拓撲中的同一個事務gtid不變。由於GTID在全域性的唯一性，通過GTID，我們可以在自動切換時對一些複雜的複製拓撲很方便的提升新主庫及新備庫，例如通過指向特定的GTID來確定新備庫複製座標

2）圖解

同樣的GTID不能被執行兩次，如果有同樣的GTID，會自動被skip掉

salve1：將自己的UUID1:1傳送給master，然後接收到了UUID1：2，UUID1：3 event

salve2：將自己的UUID1：1，UUID1：2傳送給master，然後接收到了UUID1：3event

5.GTID主從複製的優缺點

GTID的優點

一個事務對應一個唯一ID，一個GTID在一個伺服器上只會執行一次。

GTID是用來代替傳統複製的方法，GTID複製與普通複製模式的最大不同就是不需要指定二進位制檔名和位置。

減少手工干預和降低服務故障時間，當主機掛了之後通過軟體從眾多的備機中提升一臺備機為主機。

GTID的缺點

不支援非事務引擎。

不支援create table ... select 語句複製(主庫直接報錯);(原理: 會生成兩個sql, 一個是DDL建立表SQL, 一個是insert into 插入資料的sql; 由於DDL會導致自動提交, 所以這個sql至少需要兩個GTID, 但是GTID模式下, 只能給這個sql生成一個GTID)。

不允許一個SQL同時更新一個事務引擎表和非事務引擎表。

在一個複製組中，必須要求統一開啟GTID或者是關閉GTID。

開啟GTID需要重啟 (mysql5.7除外)。

開啟GTID後，就不再使用原來的傳統複製方式。

對於create temporary table（建立臨時表） 和 drop temporary table （刪除臨時表）語句不支援。

不支援sql_slave_skip_counter（跳過錯誤）。

6.GTID主從複製部署

環境準備

其中master對外提供寫服務，備選master提供讀服務，salve頁提供相關的讀服務，一旦master宕機，將會把備選master提升為新master，slave指向新的master，manager作為管理伺服器。

主庫配置

1.準備一臺純淨的linux主機，二進位制安裝MySQL5.7，初始化，配置環境變數，配置systemctl管理，配置好配置檔案後重啟

[root@mysql_master mysql_data]# cat /etc/my.cnf
[mysqld]
basedir=/usr/local/mysql
datadir=/mysql_data
port=3306
socket=/usr/local/mysql/mysql.sock
character-set-server=utf8mb4
log-error=/var/log/mysqld.log
pid-file=/tmp/mysqld.pid
server-id = 1                                
binlog_format='row'                          
log-bin = /var/lib/mysql/mybinlog
skip-name-resolve
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
relay_log_purge=0
sync_binlog=1            
expire_logs_days = 7                        
max_binlog_size = 100M
binlog_cache_size=4m
max_binlog_cache_size=512m                        
binlog_rows_query_log_events=on          
			
[mysql]
socket=/usr/local/mysql/mysql.sock

[client]
socket=/usr/local/mysql/mysql.sock

systemctl restart mysqld

2.增加主從複製的使用者
GRANT REPLICATION SLAVE ON *.* TO 'jerry'@'%' IDENTIFIED BY '123';
flush privileges;

從庫配置

1.準備一臺純淨的linux主機，二進位制安裝MySQL5.7，初始化，配置環境變數，配置systemctl管理，配置好配置檔案後重啟

[root@mysql_salve01 ~]# cat /etc/my.cnf 
[mysqld]
basedir=/usr/local/mysql
datadir=/mysql_data
port=3306
socket=/usr/local/mysql/mysql.sock
character-set-server=utf8mb4
log-error=/var/log/mysqld.log
pid-file=/tmp/mysqld.pid

# 中繼日誌
relay-log=mysql-relay-bin
replicate-wild-ignore-table=test.%
replicate-wild-ignore-table=information_schema.%

# 節點ID，確保唯一
server-id=2
binlog_format=row
log-bin=mysql-bin
skip-name-resolve
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
relay_log_purge=0
sync_binlog=1
expire_logs_days=7
#binlog每個日誌檔案大小
max_binlog_size=100m
#binlog快取大小
binlog_cache_size=4m 
#最大binlog快取大小
max_binlog_cache_size=512m
			
[mysql]
socket=/usr/local/mysql/mysql.sock

[client]
socket=/usr/local/mysql/mysql.sock

從庫執行
mysql> change master to 
    ->     master_host='172.16.1.53',
    ->     master_user='jerry',
    ->     master_password='123',
    ->     MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

mysql> show slave status\G
# 結果如下圖

建立MHA管理使用者

在主庫建立
mysql> grant all on *.* to 'mhaadmin'@'%' identified by '123';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

# 因為已經成功部署GTID主從複製，所以從庫也有這個使用者

設定從庫可讀

# 在從庫上進行操作
# 設定只讀，不要新增配置檔案，因為從庫以後可能變成主庫
mysql> set global read_only=1;
Query OK, 0 rows affected (0.00 sec)

mysql> show global variables like "%read_only%";
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_read_only      | OFF   |
| read_only             | ON    |
| super_read_only       | OFF   |
| transaction_read_only | OFF   |
| tx_read_only          | OFF   |
+-----------------------+-------+
5 rows in set (0.00 sec)

關閉MySQL自動清除relaylog的功能

# 關閉MySQL自動清除中繼日誌功能
這一步已經在之前的配置檔案中配置好了
[mysqld]
#禁用自動刪除relay log永久生效
relay_log_purge = 0

7.MHA部署

配置免密登入（所有主機之間互做）

# 建立祕鑰對
# 正常建立 ssh-keygen 需要互動，按回車，可以用一下方法跳過互動
ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa &> /dev/null

# 傳送公鑰，包括自己
for i in 50 52 53 54;do ssh-copy-id -i ~/.ssh/id_dsa.pub [email protected].${i};done

安裝依賴包（所有機器都執行）

# 安裝yum源
wget http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -ivh epel-release-latest-7.noarch.rpm
 
# 安裝MHA依賴的perl包
yum install -y perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager

wget https://qiniu.wsfnk.com/mha4mysql-node-0.58-0.el7.centos.noarch.rpm --no-check-certificate

rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm

然後再去manager主機安裝manager包

wget https://qiniu.wsfnk.com/mha4mysql-manager-0.58-0.el7.centos.noarch.rpm --no-check-certificate
rpm -ivh mha4mysql-manager-0.58-0.el7.centos.noarch.rpm

配置MHA Manager

# 建立工作目錄
mkdir -p /service/mha/
mkdir /service/mha/app1

修改配置

vim /service/mha/app1.cnf

[server default]            
#日誌存放路徑
manager_log=/service/mha/manager.log
#定義工作目錄位置
manager_workdir=/service/mha/app1
#binlog存放目錄（如果三臺資料庫機器部署的路徑不一樣，可以將配置寫到相應的server下面）
#master_binlog_dir=/usr/local/mysql/data
 
#設定ssh的登入使用者名稱
ssh_user=root
#如果埠修改不是22的話，需要加引數，不建議改ssh埠
#否則後續如負責VIP漂移的perl指令碼也都得改，很麻煩
ssh_port=22
 
#管理使用者
user=mhaadmin
password=123
 
#複製使用者
repl_user=jerry
repl_password=123
 
#檢測主庫心跳的間隔時間
ping_interval=1
 
[server1]
# 指定自己的binlog日誌存放目錄
master_binlog_dir=/mysql_data
hostname=172.16.1.52
port=3306
 
[server2]
#暫時註釋掉，先不使用
#candidate_master=1
#check_repl_delay=0
master_binlog_dir=/mysql_data
hostname=172.16.1.53
port=3306
 
[server3]
master_binlog_dir=/mysql_data
hostname=172.16.1.54
port=3306
 
# 1、設定了以下兩個引數，則該從庫成為候選主庫，優先順序最高
# 不管怎樣都切到優先順序高的主機，一般在主機效能差異的時候用         
candidate_master=1
# 不管優先順序高的備選庫，資料延時多久都要往那切
check_repl_delay=0
 
# 2、上述兩個引數詳解如下：
# 設定引數candidate_master=1後，則判斷該主機為為候選master，發生主從切換以後將會將此從庫提升為主庫，即使這個主庫不是叢集中事件最新的slave。
 
# 預設情況下如果一個slave落後master 100M的relay logs的話，MHA將不會選擇該slave作為一個新的master，因為對於這個slave的恢復需要花費很長時間，通過設定check_repl_delay=0,MHA觸發切換在選擇一個新的master的時候將會忽略複製延時，這個引數對於設定了candidate_master=1的主機非常有用，因為這個候選主在切換的過程中一定是新的master
 
# 3、應該為什麼節點設定這倆引數，從而把該節點的優先順序調高
# （1）、多地多中心，設定本地節點為高權重
# （2）、在有半同步複製的環境中，設定半同步複製節點為高權重
# （3）、你覺著哪個機器適合做主節點，配置較高的 、效能較好的

檢測mha配置狀態

# 測試免密連線
1.使用mha命令檢測ssh免密登入
masterha_check_ssh --conf=/service/mha/app1.cnf
    ALL SSH ... successfilly 表示ok了
 
2.使用mha命令檢測主從狀態
masterha_check_repl --conf=/service/mha/app1.cnf
    ... Health is OK
 
# 如果出現問題，可能是反向解析問題，配置檔案加上
    skip-name-resolve
# 還有可能是主從狀態，mha使用者密碼的情況

啟動MHA

nohup masterha_manager --conf=/service/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /service/mha/manager.log 2>&1 &
 
命令引數：
--remove_dead_master_conf       該引數代表當發生主從切換後，宕機庫的配置資訊將會從配置檔案中移除。
--manger_log                    日誌存放位置
--ignore_last_failover          在預設情況下，如果MHA檢測到連續發生宕機，且兩次宕機間隔不足8小時的話，則不會進行Failover，之所以這樣限制是為了避免ping-pong效應。該引數代表忽略上次MHA觸發切換產生的檔案，預設情況下，MHA發生切換後會在日誌目錄，也就是上面設定的manager_workdir目錄中產生app1.failover.complete檔案，下次再次切換的時候如果發現該目錄下存在該檔案將不允許觸發切換，除非在第一次切換後收到刪除該檔案，為了方便，這裡設定為--ignore_last_failover。
 
# MHA的安全機制:
    1.完成一次切換後,會生成一個鎖檔案在工作目錄中
    2.下次切換之前,會檢測鎖檔案是否存在
    3.如果鎖檔案存在,8個小時之內不允許第二次切換