mysql實現高可用架構之MHA

時間 2019-12-14

標籤 mysql 實現可用架構 mha 欄目 MySQL 简体版

原文原文鏈接

1、簡介

　　MHA（Master HA）是一款開源的 MySQL 的高可用程序，它爲 MySQL 主從複製架構提供了 automating master failover 功能。MHA 在監控到 master 節點故障時，會提高其中擁有最新數據的 slave 節點成爲新的master 節點，在此期間，MHA 會經過於其它從節點獲取額外信息來避免一致性方面的問題。MHA 還提供了 master 節點的在線切換功能，即按需切換 master/slave 節點。
　　MHA 是由日本人 yoshinorim（原就任於DeNA現就任於FaceBook）開發的比較成熟的 MySQL 高可用方案。MHA 可以在30秒內實現故障切換，並能在故障切換中，最大可能的保證數據一致性。目前淘寶也正在開發類似產品 TMHA，目前已支持一主一從。html

2、MHA 服務

2.1 服務角色

　　MHA 服務有兩種角色， MHA Manager(管理節點)和 MHA Node(數據節點)：
MHA Manager：
　　一般單獨部署在一臺獨立機器上管理多個 master/slave 集羣(組)，每一個 master/slave 集羣稱做一個 application，用來管理統籌整個集羣。
MHA node：
　　運行在每臺 MySQL 服務器上(master/slave/manager)，它經過監控具有解析和清理 logs 功能的腳原本加快故障轉移。
　　主要是接收管理節點所發出指令的代理，代理須要運行在每個 mysql 節點上。簡單講 node 就是用來收集從節點服務器上所生成的 bin-log 。對比打算提高爲新的主節點之上的從節點的是否擁有並完成操做，若是沒有發給新主節點在本地應用後提高爲主節點。

　　由上圖咱們能夠看出，每一個複製組內部和 Manager 之間都須要ssh實現無密碼互連，只有這樣，在 Master 出故障時， Manager 才能順利的鏈接進去，實現主從切換功能。node

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地址。mysql

2.3工做原理

MHA工做原理總結爲如下幾條：
（1）從宕機崩潰的 master 保存二進制日誌事件（binlog events）；
（2）識別含有最新更新的 slave ；
（3）應用差別的中繼日誌(relay log) 到其餘 slave ；
（4）應用從 master 保存的二進制日誌事件(binlog events)；
（5）提高一個 slave 爲新 master ；
（6）使用其餘的 slave 鏈接新的 master 進行復制。sql

3、實現過程

3.1 準備實驗 Mysql 的 Replication 環境

3.1.1 相關配置

　　MHA 對 MYSQL 複製環境有特殊要求，例如各節點都要開啓二進制日誌及中繼日誌，各從節點必須顯示啓用其read-only屬性，並關閉relay_log_purge功能等，這裏對配置作事先說明。
　　本實驗環境共有四個節點，其角色分配以下（實驗機器均爲centos 7.3）：
數據庫

　　爲了方便咱們後期的操做，咱們在各節點的/etc/hosts文件配置內容中添加以下內容：vim

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

　　這樣的話，咱們就能夠經過 host 解析節點來打通私鑰訪問，會方便不少。
　　本步驟完成。
　　centos

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 的數據庫配置文件，兩臺機器都作以下操做：架構

[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

[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 配置一主多從複製架構

　　下面只會給出命令，具體的知識及過程詳解見個人上一篇博客——實戰項目——mysql主從架構的實現。
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.2 安裝配置MHA

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/

　　固然，咱們也能夠在機器上實驗一下，看看 ssh 是否還須要輸入密碼。
　　本步驟完成。

3.2.3 安裝 MHA 包

　　在本步驟中， Manager節點須要另外多安裝一個包。具體須要安裝的內容以下：

四個節點都需安裝：mha4mysql-node-0.56-0.el6.norch.rpm
Manager 節點另須要安裝：mha4mysql-manager-0.56-0.el6.noarch.rpm

　　須要安裝的包我已經上傳至百度雲盤，密碼：mkcr，你們須要的自行下載使用~
　　咱們使用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 對四個節點進行檢測

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.

　　能夠看出，咱們的檢測已經ok了。
　　此步驟完成。

3.3 啓動 MHA

　　咱們在 manager 節點上執行如下命令來啓動 MHA：

[root@manager ~]# nohup masterha_manager -conf=/etc/mha_master/mha.cnf &> /etc/mha_master/manager.log &
[1] 7598

　　啓動成功之後，咱們來查看一下 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

　　以上。咱們的實驗已經圓滿完成。　　若有疑問或者建議你們能夠多多討論吶~(～￣▽￣)～

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。

mysql實現高可用架構之MHA

1、簡介

2、MHA 服務

2.1 服務角色

2.2提供的工具

2.3工做原理

3、實現過程

3.1 準備實驗 Mysql 的 Replication 環境

3.1.1 相關配置

3.1.2 初始主節點 master 的配置

3.1.3 全部 slave 節點依賴的配置

3.1.4 配置一主多從複製架構

3.2 安裝配置MHA

3.2.1 在 master 上進行受權

3.2.2 準備 ssh 互通環境

3.2.3 安裝 MHA 包

3.2.4 初始化 MHA ，進行配置

3.2.5 定義 MHA 管理配置文件

3.2.6 對四個節點進行檢測

3.3 啓動 MHA

3.4 測試 MHA 故障轉移

3.4.1 在 master 節點關閉 mariadb 服務,模擬主節點數據崩潰

3.4.2 在 manger 節點查看日誌

3.5 提供新的從節點以修復複製集羣

3.6 新節點提供後再次執行檢查操做

3.7新節點上線， 故障轉換恢復注意事項

3.7新節點上線，故障轉換恢復注意事項