（專案六）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 [email protected]'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 &
