（項目六）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工具包，具體的說明如下：
#Manager工具包主要包括以下幾個工具：masterha_check_ssh #檢查MHA的SSH配置狀況masterha_check_repl #檢查MySQL復制狀況masterha_check_status #檢測當前MHA運行狀態masterha_master_monitor #檢測master是否宕機masterha_manger #啟動MHAmasterha_master_switch #控制故障轉移（自動或者手動）masterha_conf_host #添加或刪除配置的server信息masterha_secondary_check #試圖建立TCP連接從遠程服務器masterha_stop #停止MHA#Node工具包主要包括以下幾個工具：save_binary_logs #保存和復制master的二進制日誌apply_diff_relay_logs #識別差異的中繼日誌事件filter_mysqlbinlog #去除不必要的ROLLBACK事件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 &
（項目六）Mha-Atlas-MySQL高可用方案實踐