MHA實現MySQL的高可用
一：軟件簡介
MHA（Master High Availability）目前在MySQL高可用方面是一個相對成熟的解決方案，是一套優秀的做爲MySQL高可用性環境下故障切換和主從提高的高可用軟件。html
在MySQL故障切換過程當中，MHA能作到在0~30秒以內自動完成數據庫的故障切換操做，而且在進行故障切換的過程當中，MHA能在最大程度上保證數據的一致性，以達到真正意義上的高可用。node
它由兩部分組成：MHA Manager（管理節點）和MHA Node（數據節點）。mysql
MHA Manager能夠單獨部署在一臺獨立的機器上管理多個master-slave集羣，也能夠部署在一臺slave節點上。sql
MHA Node運行在每臺MySQL服務器上，MHA Manager會定時探測集羣中的master節點，當master出現故障時，它能夠自動將最新數據的slave提高爲新的master，而後將全部其餘的slave從新指向新的master。整個故障轉移過程對應用程序徹底透明。數據庫
二：MHA服務
2.1服務角色
MHA 服務有兩種角色， MHA Manager(管理節點)和 MHA Node(數據節點)：vim
MHA Manager： centos
一般單獨部署在一臺獨立機器上管理多個 master/slave 集羣(組)，每一個 master/slave 集羣稱做一個 application，用來管理統籌整個集羣。服務器
MHA node： 網絡
運行在每臺 MySQL 服務器上(master/slave/manager)，它經過監控具有解析和清理 logs 功能的腳原本加快故障轉移。
主要是接收管理節點所發出指令的代理，代理須要運行在每個 mysql 節點上。簡單講 node 就是用來收集從節點服務器上所生成的 bin-log 。對比打算提高爲新的主節點之上的從節點的是否擁有並完成操做，若是沒有發給新主節點在本地應用後提高爲主節點。架構
由上圖咱們能夠看出，每一個複製組內部和 Manager 之間都須要ssh實現無密碼互連，只有這樣，在 Master 出故障時， Manager 才能順利的鏈接進去，實現主從切換功能。
2.2提供的工具
MHA會提供諸多工具程序， 其常見的以下所示：
Manager節點：
masterha_check_ssh ：MHA 依賴的 ssh 環境監測工具；
masterha_check_repl ：MySQL 複製環境檢測工具；
masterga_manager ：MHA 服務主程序；
masterha_check_status ：MHA 運行狀態探測工具；
masterha_master_monitor ：MYSQL master 節點可用性監測工具；
masterha_master_swith:master ：節點切換工具；
masterha_conf_host ：添加或刪除配置的節點；
masterha_stop ：關閉 MHA 服務的工具。
Node節點：（這些工具一般由MHA Manager的腳本觸發，無需人爲操做）
save_binary_logs ：保存和複製 master 的二進制日誌；
apply_diff_relay_logs ：識別差別的中繼日誌事件並應用於其餘 slave；
purge_relay_logs ：清除中繼日誌（不會阻塞 SQL 線程）；
自定義擴展：
secondary_check_script ：經過多條網絡路由檢測master的可用性；
master_ip_failover_script ：更新application使用的masterip；
report_script ：發送報告;
init_conf_load_script ：加載初始配置參數；
master_ip_online_change_script ;更新master節點ip地址。
2.3工做原理
原理總結爲如下幾條：
（1） 從宕機崩潰的 master 保存二進制日誌事件（binlog events）；
（2） 識別含有最新更新的 slave ；
（3） 應用差別的中繼日誌(relay log) 到其餘 slave ；
（4） 應用從 master 保存的二進制日誌事件(binlog events)；
（5） 提高一個 slave 爲新 master ；
（6） 使用其餘的 slave 鏈接新的 master 進行復制。
三：實現過程
3.1準備實驗MySQL的 Replication 環境
3.1.1環境配置
MHA 對 MYSQL 複製環境有特殊要求，例如各節點都要開啓二進制日誌及中繼日誌，各從節點必須顯示啓用其read-only屬性，並關閉relay_log_purge功能等，這裏對配置作事先說明。
本實驗環境共有四個節點， 其角色分配以下（實驗機器均爲centos 7.3）：
爲了方便咱們後期的操做，咱們在各節點的/etc/hosts文件配置內容中添加以下內容：
經過 host 解析節點來打通私鑰訪問，會方便不少。
192.168.37.111 node1.keer.com node1 192.168.37.122 node2.keer.com node2 192.168.37.133 node3.keer.com node3 192.168.37.144 node4.keer.com node4
3.1.2初始master節點配置
修改 master 的數據庫配置文件來對其進行初始化配置：
[root@master ~]# vim /etc/my.cnf [mysqld] server-id = 1 //複製集羣中的各節點的id均必須惟一
log-bin = master-log //開啓二進制日誌
relay-log = relay-log //開啓中繼日誌
skip_name_resolve //關閉名稱解析（非必須）
[root@master ~]# systemctl restart mariadb
3.1.3全部slave節點依賴配置
修改兩個 slave 節點的數據庫配置文件：
#slave1節點 [root@slave1 ~]# vim /etc/my.cnf [mysqld] server-id = 2 //複製集羣中的各節點的id均必須惟一；
relay-log = relay-log //開啓中繼日誌
log-bin = master-log //開啓二進制日誌
read_only = ON //啓用只讀屬性
relay_log_purge = 0 //是否自動清空再也不須要中繼日誌
skip_name_resolve //關閉名稱解析（非必須）
log_slave_updates = 1 //使得更新的數據寫進二進制日誌中
[root@slave1 ~]# systemctl restart mariadb
#slave2節點 [root@slave2 ~]# vim /etc/my.cnf [mysqld] server-id = 3 //複製集羣中的各節點的id均必須惟一；
relay-log = relay-log //開啓中繼日誌
log-bin = master-log //開啓二進制日誌
read_only = ON //啓用只讀屬性
relay_log_purge = 0 //是否自動清空再也不須要中繼日誌
skip_name_resolve //關閉名稱解析（非必須）
log_slave_updates = 1 //使得更新的數據寫進二進制日誌中
[root@slave2 ~]# systemctl restart mariadb
3.1.4配置一主多從複製架構
master節點上：
MariaDB [(none)]>grant replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer'; MariaDB [(none)]> show master status;
slave節點上：
MariaDB [(none)]> change master to master_host='192.168.37.122', -> master_user='slave', -> master_password='keer', -> master_log_file='mysql-bin.000001', -> master_log_pos=415; MariaDB [(none)]> start slave; MariaDB [(none)]> show slave status\G;
3.2MHA安裝配置
3.2.1在master上進行受權
在全部 Mysql 節點受權擁有管理權限的用戶可在本地網絡中有其餘節點上遠程訪問。 固然， 此時僅須要且只能在 master 節點運行相似以下 SQL 語句便可。
MariaDB [(none)]> grant all on *.* to 'mhaadmin'@'192.168.%.%' identified by 'mhapass';
3.2.2配置ssh免祕鑰登陸
MHA集羣中的各節點彼此之間均須要基於ssh互信通訊，以實現遠程控制及數據管理功能。
簡單起見，可在Manager節點生成密鑰對兒，並設置其可遠程鏈接本地主機後， 將私鑰文件及authorized_keys文件複製給餘下的全部節點便可。
下面操做在全部節點上進行：
[root@manager ~]# ssh-keygen -t rsa [root@manager ~]# ssh-copy-id -i .ssh/id_rsa.pub root@node1
當四臺機器都進行了上述操做之後，咱們能夠在 manager 機器上看到以下文件：
[root@manager ~]# cd .ssh/ [root@manager .ssh]# ls authorized_keys id_rsa id_rsa.pub known_hosts [root@manager .ssh]# cat authorized_keys
四臺機器的公鑰都已經在authorized_keys這個文件中了，接着，咱們只須要把這個文件發送至另外三臺機器，這四臺機器就能夠實現 ssh 無密碼互通了：
[root@manager .ssh]# scp authorized_keys root@node2:~/.ssh/ [root@manager .ssh]# scp authorized_keys root@node3:~/.ssh/ [root@manager .ssh]# scp authorized_keys root@node4:~/.ssh/
3.2.3安裝MHA
四個節點都需安裝： mha4mysql-node-0.56-0.el6.norch.rpm
Manager 節點需多安裝一個： mha4mysql-manager-0.56-0.el6.noarch.rpm
使用rz命令分別上傳，而後使用yum安裝便可。
[root@manager ~]# rz [root@manager ~]# ls anaconda-ks.cfg initial-setup-ks.cfg Pictures Desktop mha4mysql-manager-0.56-0.el6.noarch.rpm Public Documents mha4mysql-node-0.56-0.el6.noarch.rpm Templates Downloads Music Videos [root@manager ~]# yum install -y mha4mysql-node-0.56-0.el6.noarch.rpm [root@manager ~]# yum install -y mha4mysql-manager-0.56-0.el6.noarch.rpm
其他機器也分別進行安裝，就不一一舉例了。
3.2.4初始化MHA及配置
Manager 節點須要爲每一個監控的 master/slave 集羣提供一個專用的配置文件，而全部的 master/slave 集羣也可共享全局配置。全局配置文件默認爲 /etc/masterha_default.cnf ，其爲可選配置。若是僅監控一組 master/slave 集羣，也可直接經過 application 的配置來提供各服務器的默認配置信息。而每一個 application 的配置文件路徑爲自定義。具體操做見下一步驟。
3.2.5定義MHA配置管理文件
爲MHA專門建立一個管理用戶， 方便之後使用， 在MySQL的主節點上， 三個節點自動同步：
mkdir /etc/mha_master vim /etc/mha_master/mha.cnf
配置文件內容以下；
[server default] //適用於server1,2,3個server的配置
user=mhaadmin //mha管理用戶
password=mhapass //mha管理密碼
manager_workdir=/etc/mha_master/app1 //mha_master本身的工做路徑
manager_log=/etc/mha_master/manager.log // mha_master本身的日誌文件
remote_workdir=/mydata/mha_master/app1 //每一個遠程主機的工做目錄在何處
ssh_user=root // 基於ssh的密鑰認證
repl_user=slave //數據庫用戶名
repl_password=magedu //數據庫密碼
ping_interval=1 //ping間隔時長
[server1] //節點2
hostname=192.168.37.133 //節點2主機地址
ssh_port=22 //節點2的ssh端口
candidate_master=1 //未來可不能夠成爲master候選節點/主節點
[server2] hostname=192.168.37.133 ssh_port=22 candidate_master=1 [server3] hostname=192.168.37.144 ssh_port=22 candidate_master=1
3.2.6檢測4個節點
1）檢測各節點間 ssh 互信通訊配置是否 ok
咱們在 Manager 機器上輸入下述命令來檢測：
[root@manager ~]# masterha_check_ssh -conf=/etc/mha_master/mha.cnf
若是最後一行顯示爲 [info]All SSH connection tests passed successfully 則表示成功。
2）檢查管理的MySQL複製集羣的鏈接配置參數是否OK
[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf
咱們發現檢測失敗，這多是由於從節點上沒有帳號，由於這個架構，任何一個從節點， 將有可能成爲主節點， 因此也須要建立帳號。
所以，咱們須要在master節點上再次執行如下操做：
MariaDB [(none)]> grant replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer'; MariaDB [(none)]> flush privileges;
執行完這段操做以後，咱們再次運行檢測命令：
[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf Thu Nov 23 09:07:08 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. Thu Nov 23 09:07:08 2017 - [info] Reading application default configuration from /etc/mha_master/mha.cnf.. Thu Nov 23 09:07:08 2017 - [info] Reading server configuration from /etc/mha_master/mha.cnf.. …… MySQL Replication Health is OK.
3.3啓動MHA
在 manager 節點上執行如下命令來啓動 MHA：
[root@manager ~]# nohup masterha_manager -conf=/etc/mha_master/mha.cnf &> /etc/mha_master/manager.log &
啓動成功之後，咱們來查看一下 master 節點的狀態：
[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf mha (pid:7598) is running(0:PING_OK), master:192.168.37.122
上面的信息中「mha (pid:7598) is running(0:PING_OK)」表示MHA服務運行OK，不然， 則會顯示爲相似「mha is stopped(1:NOT_RUNNING).」
若是，咱們想要中止 MHA ，則須要使用 stop 命令：
[root@manager ~]# masterha_stop -conf=/etc/mha_master/mha.cnf
3.4測試MHA故障轉移
3.4.1 在 master 節點關閉 mariadb 服務,模擬主節點數據崩潰
[root@master ~]# killall -9 mysqld mysqld_safe [root@master ~]# rm -rf /var/lib/mysql/*
3.4.2 在 manger 節點查看日誌
[root@manager ~]# tail -200 /etc/mha_master/manager.log …… Thu Nov 23 09:17:19 2017 - [info] Master failover to 192.168.37.133(192.168.37.133:3306) completed successfully.
日誌顯示manager 檢測到192.168.37.122節點故障， 然後自動執行故障轉移， 將192.168.37.133提高爲主節點。
注意，故障轉移完成後， manager將會自動中止， 此時使用 masterha_check_status 命令檢測將會遇到錯誤提示， 以下所示：
[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf mha is stopped(2:NOT_RUNNING).
3.5 提供新的從節點修復集羣
原有 master 節點故障後，須要從新準備好一個新的 MySQL 節點。基於來自於master 節點的備份恢復數據後，將其配置爲新的 master 的從節點便可。
注意，新加入的節點若是爲新增節點，其 IP 地址要配置爲原來 master 節點的 IP，不然，還須要修改 mha.cnf 中相應的 ip 地址。隨後再次啓動 manager ，並再次檢測其狀態。
咱們就以剛剛關閉的那臺主做爲新添加的機器，來進行數據庫的恢復：
本來的 slave1 已經成爲了新的主機器，因此，咱們對其進行徹底備份，然後把備份的數據發送到咱們新添加的機器上：
[root@slave1 ~]# mkdir /backup [root@slave1 ~]# mysqldump --all-database > /backup/mysql-backup-`date +%F-%T`-all.sql [root@slave1 ~]# scp /backup/mysql-backup-2017-11-23-09\:57\:09-all.sql root@node2:~
而後在 node2 節點上進行數據恢復：
[root@master ~]# mysql < mysql-backup-2017-11-23-09\:57\:09-all.sql
接下來就是配置主從。照例查看一下如今的主的二進制日誌和位置，而後就進行以下設置：
MariaDB [(none)]> change master to master_host='192.168.37.133', master_user='slave', master_password='keer', master_log_file='mysql-bin.000006', master_log_pos=925; MariaDB [(none)]> start slave; MariaDB [(none)]> show slave status\G; Slave_IO_State: Waiting for master to send event Master_Host: 192.168.37.133 Master_User: slave Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000006 Read_Master_Log_Pos: 925 Relay_Log_File: mysql-relay-bin.000002 Relay_Log_Pos: 529 Relay_Master_Log_File: mysql-bin.000006 Slave_IO_Running: Yes Slave_SQL_Running: Yes ……
3.6 新節點提供後再次執行檢查操做
再次檢測狀態：
[root@manager ~]# masterha_check_repl -conf=/etc/mha_master/mha.cnf
若是報錯，則再次受權（詳見上文）。若沒有問題，則啓動 manager，注意，此次啓動要記錄日誌：
[root@manager ~]# masterha_manager -conf=/etc/mha_master/mha.cnf > /etc/mha_master/manager.log 2>&1 & [1] 10012
啓動成功之後，咱們來查看一下 master 節點的狀態：
[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf mha (pid:9561) is running(0:PING_OK), master:192.168.37.133
3.7新節點上線， 故障轉換恢復注意事項
1）在生產環境中， 當你的主節點掛了後， 必定要在從節點上作一個備份，拿着備份文件把主節點手動提高爲從節點， 並指明從哪個日誌文件的位置開始複製；
2）每一次自動完成轉換後， 每一次的(replication health )檢測不ok始終都是啓動不了必須手動修復主節點， 除非你改配置文件；
3）手動修復主節點提高爲從節點後， 再次運行檢測命令；
[root@manager ~]# masterha_check_status -conf=/etc/mha_master/mha.cnf mha (pid:9561) is running(0:PING_OK), master:192.168.37.133
4）再次運行起來就恢復成功了；
[root@manager ~]# masterha_manager --conf=/etc/mha_master/mha.cnf
以上的實驗已經圓滿完成。
- 1. MHA實現mysql高可用
- 2. MySQL實現高可用——MHA
- 3. Mysql實現MHA高可用
- 4. Mysql的高可用MHA實現
- 5. MHA實現mysql的高可用集羣
- 6. MHA實現mysql的高可用
- 7. mysql實現高可用架構之MHA
- 8. MHA實現mysql高可用性
- 9. MHA實現Mysql半同步高可用
- 10. mysql 高可用之mha實現
- 更多相關文章...
- • 現實生活中的 XML - XML 教程
- • PHP 可用的函數 - PHP參考手冊
- • ☆基於Java Instrument的Agent實現
- • 漫談MySQL的鎖機制
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 字節跳動21屆秋招運營兩輪面試經驗分享
- 2. Java 3 年，25K 多嗎？
- 3. mysql安裝部署
- 4. web前端開發中父鏈和子鏈方式實現通信
- 5. 3.1.6 spark體系之分佈式計算-scala編程-scala中trait特性
- 6. dataframe2
- 7. ThinkFree在線
- 8. 在線畫圖
- 9. devtools熱部署
- 10. 編譯和鏈接
- 1. MHA實現mysql高可用
- 2. MySQL實現高可用——MHA
- 3. Mysql實現MHA高可用
- 4. Mysql的高可用MHA實現
- 5. MHA實現mysql的高可用集羣
- 6. MHA實現mysql的高可用
- 7. mysql實現高可用架構之MHA
- 8. MHA實現mysql高可用性
- 9. MHA實現Mysql半同步高可用
- 10. mysql 高可用之mha實現