（項目六）Mha-Atlas-MySQL高可用方案實踐

mha-mysql環境準備：

三臺虛擬機，都安裝了mysql，都關閉防火牆和selinux，同時在每臺虛擬機上都作映射

軟件包

1） mha管理節點安裝包：

mha4mysql-manager-0.56-0.el6.noarch.rpm

mha4mysql-manager-0.56.tar.gz

2） mha node節點安裝包：

mha4mysql-node-0.56-0.el6.noarch.rpm

mha4mysql-node-0.56.tar.gz

3） mysql中間件：

Atlas-2.2.1.el6.x86_64.rpm

4） mysql源碼安裝包

mysql-5.6.17-linux-glibc2.5-x86_64.tar

注意，mysql的安裝包必定要用5.6版本及以上

 軟件簡介

• MHA（Master High Availability）目前在MySQL高可用方面是一個相對成熟的解決方案，是一套優秀的做爲MySQL高可用性環境下故障切換和主從提高的高可用軟件。在MySQL故障切換過程當中，MHA能作到0~30秒以內自動完成數據庫的故障切換操做，而且在進行故障切換過程當中，MHA能最大程度上保證數據庫的一致性，以達到真正意義上的高可用。
• MHA由兩部分組成：MHA Manager（管理節點）和MHA Node（數據節點）。MHA Manager能夠獨立部署在一臺獨立的機器上管理多個Master-Slave集羣，也能夠部署在一臺Slave上。當Master出現故障時，它能夠自動將最新數據的Slave提高爲新的Master，而後將全部其餘的Slave從新指向新的Master。整個故障轉移過程對應程序是徹底透明的。

工做流程

• 從宕機崩潰的master保存二進制日誌事件（binlog events）；
• 識別含有最新更新的slave；
• 應用差別的中繼日誌（relay log）到其餘的slave；
• 應用從master保存的二進制日誌事件（binlog events）；
• 提高一個slave爲新的master；
• 使其餘的slave鏈接新的master進行復制；

 MHA架構圖

MHA工具介紹

MHA軟件由兩部分組成，Manager工具包和Node工具包，具體的說明以下：

1. #Manager工具包主要包括如下幾個工具：
2. masterha_check_ssh #檢查MHA的SSH配置情況
3. masterha_check_repl #檢查MySQL複製情況
4. masterha_check_status #檢測當前MHA運行狀態
5. masterha_master_monitor #檢測master是否宕機
6. masterha_manger #啓動MHA
7. masterha_master_switch #控制故障轉移（自動或者手動）
8. masterha_conf_host #添加或刪除配置的server信息
9. masterha_secondary_check #試圖創建TCP鏈接從遠程服務器
10. masterha_stop #中止MHA
11. #Node工具包主要包括如下幾個工具：
12. save_binary_logs #保存和複製master的二進制日誌
13. apply_diff_relay_logs #識別差別的中繼日誌事件
14. filter_mysqlbinlog #去除沒必要要的ROLLBACK事件
15. purge_relay_logs #清除中繼日誌

mysql安裝過程略（在安裝以前先安裝ncurses-devel 和 libaio，本地yum便可安裝 ）

在安裝完mysql後設置密碼：mysqladmin -uroot password ‘123456’

配置基於GTID的主從複製

先決條件

• 主庫和從庫都要開啓binlog
• 主庫和從庫server-id不一樣
• 要有主從複製用戶

打開了GTID，就控制不了同步過程，一旦出現問題，得先關閉GTID才能修改

主庫操做（Mysql-Master）

修改配置文件  （主要是開啓二進制日誌和server id）

修改完配置文件要重啓mysqld服務

建立主從複製用戶

 從庫操做（Mysql-slave1和Mysql-slave2）

從庫配置文件和主庫同樣，只須要修改server id 便可，我把Mysql-slave1的改成5，Mysql-slave2的改成10，改完記得重啓mysqld服務

特別提示：
在以往若是是基於binlog日誌的主從複製，則必需要記住主庫的master狀態信息。

可是在MySQL5.6版本里多了一個Gtid的功能，能夠自動記錄主從複製位置點的信息，並在日誌中輸出出來。

開啓GTID

 修改配置文件，在mysqld模塊加三條語句

[mysqld]

gtid_mode = ON
log_slave_updates
enforce_gtid_consistency

 三臺虛擬機都得加，加完後重啓服務。

 

改完後查看GTID狀態

 

 

再次提示： 

從庫都必需要開啓GTID，不然在作主從複製的時候就會報錯.

 

主庫配置主從複製(Mysql-slave1，Mysql-slave2)

 

 

開啓從庫的主從複製功能(Mysql-slave1，Mysql-slave2)

 

 

兩個從庫都執行以上步驟

從庫設置(Mysql-slave1，Mysql-slave2)

須要把從庫的relay-log日誌自動刪除功能給關閉，修改配置文件

 

改完須要重啓服務

部署MHA

環境準備（全部節點Mysql-master，Mysql-slave1，Mysql-slave2）

 

主庫上建立該帳號從庫會自動複製

部署管理節點（mha-manager）

在mysql-slave2上部署管理節點

使用阿里雲源+epel源

wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-6.repo

wget -O /etc/yum.repos.d/epel-6.repo http://mirrors.aliyun.com/repo/epel-6.repo

而後yum -y install perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes

 

 rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm

編輯配置文件

建立配置文件目錄    mkdir -p /etc/mha

建立日誌目錄     mkdir -p /var/log/mha/mha1

建立配置文件（默認沒有）

 

以上配置文件內容裏每行的最後不要留有空格

特別說明： 
參數：candidate_master=1
解釋：設置爲候選master，若是設置該參數之後，發生主從切換之後會將此從庫提高爲主庫，即便這個主庫不是集羣中事件最新的slave
參數：check_repl_delay=0
解釋：默認狀況下若是一個slave落後master 100M的relay logs 的話，MHA將不會選擇該slave做爲一個新的master，由於對於這個slave的恢復須要花費很長時間，經過設置check_repl_delay=0,MHA觸發切換在選擇一個新的master的時候將會忽略複製延時，這個參數對於設置了candidate_master=1的主機很是有用，由於這個候選主在切換的過程當中必定是新的master

配置ssh信任（全部節點Mysql-master，Mysql-slave1，Mysql-slave2）

每一個虛擬機都建立密鑰對 ssh-keygen -t dsa -P "" -f ~/.ssh/id_dsa

每一個虛擬機的公鑰都分發給全部虛擬機（包括本身）

 

 

啓動測試

ssh檢查檢測

 

出現上圖最後一行，表示成功

主從複製檢測

（1）錯誤的主從複製檢測

 

最後一行顯示出錯，你們應該都是這樣的，這是說明Mysql-slave1和Mysql-slave2上沒有主從複製帳號

所以在Mysql-slave1和Mysql-slave2上添加主從複製的用戶便可。

grant replication slave on *.* to rep@'192.168.200.%' identified by '123123';

注意，建立完主從複製帳號要刷新一下，不然仍是會報錯

flush  privileges；

再次檢查

 

 

啓動MHA

運行nohup masterha_manager --conf=/etc/mha/mha1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/mha1/manager.log 2>&1 &