mysql高可用架構之MHA和mysql日誌優化
一、MHA簡介：
MHA（Master High Availability）目前在MySQL高可用方面是一個相對成熟的解決方案，它由日本DeNA公司youshimaton（現就職於 Facebook公司）開發，是一套優秀的作為MySQL高可用性環境下故障切換和主從提升的高可用軟體。在MySQL故障切換過程中，MHA能做到在 0~30秒之內自動完成資料庫的故障切換操作，並且在進行故障切換的過程中，MHA能在最大程度上保證資料的一致性，以達到真正意義上的高可用。
該軟體由兩部分組成：MHA Manager（管理節點）和MHA Node（資料節點）。MHA Manager可以單獨部署在一臺獨立的機器上管理多個master-slave叢集，也可以部署在一臺slave節點上。MHA Node執行在每臺MySQL伺服器上，MHA Manager會定時探測叢集中的master節點，當master出現故障時，它可以自動將最新資料的slave提升為新的master，然後將所有其 他的slave重新指向新的master。整個故障轉移過程對應用程式完全透明。
在MHA自動故障切換過程中，MHA試圖從宕機的主伺服器上儲存二進位制日誌，最大程度的保證資料的不丟失，但這並不總是可行的。例如，如果主伺服器 硬體故障或無法通過ssh訪問，MHA沒法儲存二進位制日誌，只進行故障轉移而丟失了最新的資料。使用MySQL 5.5的半同步複製，可以大大降低資料丟失的風險。MHA可以與半同步複製結合起來。如果只有一個slave已經收到了最新的二進位制日誌，MHA可以將最新的二進位制日誌應用於其他所有的slave伺服器上，因此可以保證所有節點的資料一致性。
目前MHA主要支援一主多從的架構，要搭建MHA,要求一個複製叢集中必須最少有三臺資料庫伺服器，一主二從，即一臺充當master，一臺充當備用master，另外一臺充當從庫，因為至少需要三臺伺服器，出於機器成本的考慮，淘寶也在該基礎上進行了改造，目前淘寶TMHA已經支援一主一從
MHA工作原理總結為如下：
（1）從宕機崩潰的master儲存二進位制日誌事件（binlog events）;
（2）識別含有最新更新的slave；
（3）應用差異的中繼日誌（relay log）到其他的slave；
（4）應用從master儲存的二進位制日誌事件（binlog events）；
（5）提升一個slave為新的master；
（6）使其他的slave連線新的master進行復制；
MHA軟體由兩部分組成，Manager工具包和Node工具包，具體的說明如下。
Manager工具包主要包括以下幾個工具：
masterha_check_ssh 檢查MHA的SSH配置狀況 masterha_check_repl 檢查MySQL複製狀況 masterha_manger 啟動MHA masterha_check_status 檢測當前MHA執行狀態 masterha_master_monitor 檢測master是否宕機 masterha_master_switch 控制故障轉移（自動或者手動） masterha_conf_host 新增或刪除配置的server資訊
Node工具包（這些工具通常由MHA Manager的指令碼觸發，無需人為操作）主要包括以下幾個工具：
save_binary_logs 儲存和複製master的二進位制日誌
apply_diff_relay_logs 識別差異的中繼日誌事件並將其差異的事件應用於其他的slave
filter_mysqlbinlog 去除不必要的ROLLBACK事件（MHA已不再使用這個工具）
purge_relay_logs 清除中繼日誌（不會阻塞SQL執行緒）二、相關配置
實驗環境：
server5：MHA管理節點 172.25.66.5
server6：myslq master 172.25.66.6
server7：mysql Candicate slave 172.25.66.7
server8：mysql slave 172.2.66.8
1.安裝資料庫，搭建主從複製：（server6、7、8）
以server6為例：
vim /etc/my.cnf
重啟服務並初始化資料庫
/etc/init.d/mysqld start
grep password /var/log/mysqld.log
mysql -p
進入資料庫首先需要重置root使用者密碼
檢視master的狀態，並授權slave能通過repl使用者，使用‘Yuanxiaoxi+007‘的密碼從master端進行資料同步
兩個slave端的配置：
vim /etc/my.cnf
問題：SQL執行緒顯示為NO，錯誤提示中有“PRIMARY'
解決：在master端 reset master
在slave端：
測試兩個slave是否可以和master保持資料同步
在master端插入資料
slave端資料同步
MHA端的配置：
檢查ssh連線
masterha_check_ssh
原因：MHA manager通過ssh訪問所有的node節點，各個node節點同樣也需要ssh來相互發送不同的relay log檔案，所以有必要在每一個node和manager之間配置ssh無密碼登陸
ssh-keygen
ssh-copy-id 172.25.66.5
scp -r .ssh/ 172.25.66.6:
scp -r .ssh/ 172.25.66.7:
scp -r .ssh/ 172.25.66.8:
檢查repl環境
解決方法：在master上
在檢測時可能還會出現報錯：
slave節點配置：
在sever7和server8上配置slave為只讀，但不要寫入配置檔案，因為master機down掉後可能隨時升級為master
set global read_only=1;
測試：
在server5開啟MHA監控模式：
啟動引數介紹：
--remove_dead_master_conf 該引數代表當發生主從切換後，老的主庫的ip將會從配置檔案中移除。
--manger_log 日誌存放位置
--ignore_last_failover 在預設情況下，如果MHA檢測到連續發生宕機，且兩次宕機間隔不足8小時的話，則不會進行Failover，之所以這樣限制是為了避免ping-pong效應。該引數代表忽略上次MHA觸發切換產生的檔案， 預設情況下，MHA發生切換後會在日誌目錄下產生app1.failover.complete檔案，下次再次切換的時候如果發現該目錄下存在該檔案將不允許觸發切換，除非在第一次切換後手動刪除該檔案，為了方便，這裡設定為--ignore_last_failover。
將Master的服務down掉
在server5檢視日誌：
server7變為了master
server8的狀態
為了後續的實驗，將server6的服務恢復
/etc/init.d/mysqld start
線上切換
在許多情況下， 需要將現有的主伺服器遷移到另外一臺伺服器上。 比如主伺服器硬體故障，RAID 控制卡需要重建，將主伺服器移到效能更好的伺服器上等等。維護主伺服器引起效能下降， 導致停機時間至少無法寫入資料。 另外， 阻塞或殺掉當前執行的會話會導致主主之間資料不一致的問題發生。 MHA 提供快速切換和優雅的阻塞寫入，這個切換過程只需要 0.5-2s 的時間，這段時間內資料是無法寫入的。在很多情況下，0.5-2s 的阻塞寫入是可以接受的。因此切換主伺服器不需要計劃分配維護時間視窗。
其中引數的意思：
--orig_master_is_new_slave 切換時加上此引數是將原 master 變為 slave 節點，如果不加此引數，原來的 master 將不啟動
--running_updates_limit=10000,故障切換時,候選master 如果有延遲的話， mha 切換不能成功，加上此引數表示延遲在此時間範圍內都可切換（單位為s），但是切換的時間長短是由recover 時relay 日誌的大小決定
server7上變為了slave
server6變為了master
手動切換（MHA Manager必須沒有執行）
手動failover，這種場景意味著在業務上沒有啟用MHA自動切換功能，當主伺服器故障時，人工手動呼叫MHA來進行故障切換操作
將server6的mysql服務down掉，在server5上手動切換到server7上
server7已經變為了master
通過指令碼的方式管理VIP：
vim master_ip_failover
vim master_ip_online_change
vim /etc/masterha/app1.cnf
第一次需要新增虛擬ip
在客戶端測試：可以訪問伺服器
將server7的mysql服務down掉，看是否server6能否接替
客戶端使用虛擬ip訪問不受影響，並且虛擬ip自動調轉到了server6上
傳送告警郵件
server5：
vim root/MHA/send_report
cp send_report /usr/local/bin/
cd /usr/local/bin/
chmod +x send_report
vim /etc/masterha/app1.cnf
測試：
mysql binlog日誌優化
在資料庫安裝完畢，對於binlog日誌引數設定，有一些引數的調整，來滿足業務需求或使效能最大化。Mysql日誌主要對io效能產生影響，本次主要關注binlog日誌。binlog日誌會記錄下資料庫的所有增刪改操作，當不小心刪除、清空資料，或資料庫系統出錯，這時候就可以使用binlog日誌來還原資料庫，簡單來說就是一個記錄備份的東西
引數binlog_row_image 控制著這種image型別，預設為FULL（log all columns），即記錄before&after images。
該引數還有兩種，minimal和noblob，minimal表示只記錄after更改後的值，並且如果有主鍵或者非空唯一索引，則只以該欄位作為where條件判斷；noblob同full，只是不記錄blob、text列。
慢查詢日誌
slow_query_log，這個東西是用來記錄查詢比較慢的sql語句，通過查詢日誌來查詢哪條sql語句比較慢，然後就可以進行資料庫或sql語句或程式上的優化，簡單來說就是一個優化輔助工具
1.開啟慢查詢日誌
如果想關閉慢查詢日誌，只需要執行 set global slow_query_log = off
2.查詢慢查詢時間臨界點：查詢時間高於這個臨界點的都會被記錄到慢查詢日誌中
3.設定慢查詢時間臨界點：所有執行時間超過1秒的sql都將被記錄到慢查詢檔案中
set long_query_time = 1;
4.檢視慢查詢日誌
比如上面，就表示 sql語句 select sleep（10）; 執行時間為10.001548秒，超出了我們設定的慢查詢時間臨界點10s，所以被記錄下來了。
5.我們通過檢視慢查詢日誌可以發現，很亂，資料量大的時候，可能一天會產生幾個G的日誌，根本沒有辦法去清晰明瞭的分析。所以，這裡，我們採用工具進行分析。
mysqldumpslow是mysql安裝後就自帶的工具，用於分析慢查詢日誌，但是pt-query-digest卻不是mysql自帶的，如果想使用pt-query-digest進行慢查詢日誌的分析，則需要自己安裝pt-query-digest。pt-query-digest工具相較於mysqldumpslow功能多一點。