mysql實現高可用架構之MHA

一、簡介

  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, 目前已支持一主一從。

二、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 。對比打算提升爲新的主節點之上的從節點的是否擁有並完成操作,如果沒有發給新主節點在本地應用後提升爲主節點。
mysql實現高可用架構之MHA
  由上圖我們可以看出,每個複製組內部和 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工作原理

MHA工作原理總結爲以下幾條:
(1) 從宕機崩潰的 master 保存二進制日誌事件(binlog events);
(2) 識別含有最新更新的 slave ;
(3) 應用差異的中繼日誌(relay log) 到其他 slave ;
(4) 應用從 master 保存的二進制日誌事件(binlog events);
(5) 提升一個 slave 爲新 master ;

三、實現過程

MHA 對 MYSQL 複製環境有特殊要求,例如各節點都要開啓二進制日誌及中繼日誌,各從節點必須顯示啓用其read-only屬性,並關閉relay_log_purge功能等,這裏對配置做事先說明。
mysql實現高可用架構之MHA

所有節點進行初始化關閉防火牆,selinux 重啓系統

[root@master ~]# hostnamectl --static set-hostname master
[root@master ~]# systemctl status firewalld.service
[root@master ~]# systemctl stop firewalld.service
[root@master ~]# systemctl disable firewalld.service 
[root@master ~]# getenforce 
Enforcing
[root@master ~]# setenforce 0
[root@master ~]# vim /etc/selinux/config 
 修改 SELINUX=disabled
[root@master ~]# reboot

爲了方便我們後期的操作,我們在各節點的/etc/hosts文件配置內容中添加如下內容:

192.168.11.11 manager
192.168.11.12 master
192.168.11.13 slave1
192.168.11.14 slave2

這樣的話,我們就可以通過 host 解析節點來打通私鑰訪問,會方便很多。

安裝 mariadb

1、添加mariadb的yum源
[root@master ~]# vim /etc/yum.repo.d/mariadb.repo
[mariadb]
name = MariaDB 
baseurl = https://mirrors.ustc.edu.cn/mariadb/yum/10.4/centos7-amd64 gpgkey=https://mirrors.ustc.edu.cn/mariadb/yum/RPM-GPG-KEY-MariaDB 
gpgcheck=1
2、安裝
[root@master ~]# yum -y install MariaDB-server MariaDB-client
3、初始化mariadb
[root@master ~]# mysql_secure_installation

3.1.2 初始主節點 master 的配置

  我們需要修改 master 的數據庫配置文件來對其進行初始化配置:

[root@master ~]# vim /etc/my.cnf.d/server.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.d/server.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.d/server.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 節點上:

#授權同步數據賬號

[root@master ~]# mysql -uroot -p'keer'
MariaDB [(none)]>grant replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer';
 #備份數據導出到從庫
[root@master ~]# mysqldump -uroot -p'keer' --all-databases > `date +%F`-mysql-all.sql
[root@master ~]# scp *mysql-all.sql  192.168.11.12:/root
[root@master ~]# mysql -uroot -p'keer'
MariaDB [(none)]> show master status;

mysql實現高可用架構之MHA
slave 節點上:
#導入數據

[root@slave1 ~]# mysql -uroot -p'keer' < *mysql-all.sql
[root@slave1 ~]# mysql -uroot -p'keer'
MariaDB [(none)]> grant replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer';
MariaDB [(none)]> change master to master_host='192.168.11.11', 
    -> master_user='slave', 
    -> master_password='keer',
    -> master_log_file='master-log.000001',
    -> master_log_pos=245;
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status\G;

mysql實現高可用架構之MHA
slave2同理

3.2 安裝配置MHA

3.2.1 在 master 上進行授權

在所有 Mysql 節點授權擁有管理權限的用戶可在本地網絡中有其他節點上遠程訪問。 當然, 此時僅需要且只能在 master 節點運行類似如下 SQL 語句即可。

[root@master ~]# mysql -uroot -p'keer'
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 
[root@master ~]# ssh-keygen 
[root@master ~]# ssh-copy-id  192.168.11.11
[root@slave1 ~]# ssh-keygen 
[root@slave1 ~]# ssh-copy-id  192.168.11.11
[root@slave2 ~]# ssh-keygen 
[root@slave2 ~]# ssh-copy-id  192.168.11.11
[root@manager ~]# scp .ssh/authorized_keys  [email protected]:/root/.ssh/
[root@manager ~]# scp .ssh/authorized_keys  [email protected]:/root/.ssh/
[root@manager ~]# scp .ssh/authorized_keys  [email protected]:/root/.ssh/

3.2.3 安裝 MHA 包

在本步驟中, Manager節點需要另外多安裝一個包。具體需要安裝的內容如下:

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

[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 
[root@master ~]#  yum install -y mha4mysql-node-0.56-0.el6.noarch.rpm
[root@slave1 ~]#  yum install -y mha4mysql-node-0.56-0.el6.noarch.rpm
[root@slave2 ~]#  yum install -y mha4mysql-node-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的主節點上, 三個節點自動同步:

    [root@manager ~]# mkdir /etc/mha_master
    [root@manager ~]#  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.11.11 //節點2主機地址
ssh_port=22 //節點2的ssh端口
candidate_master=1 //將來可不可以成爲master候選節點/主節點
[server2]
hostname=192.168.11.12
ssh_port=22
candidate_master=1
[server3]
hostname=192.168.11.13
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

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了。

如果報錯,這可能是因爲從節點上沒有賬號,因爲這個架構,任何一個從節點, 將有可能成爲主節點, 所以都需要創建賬號。
  因此,我們需要在節點上再次執行以下操作:

[root@master ~]# mysql -uroot -p'keer'
MariaDB [(none)]> grant replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer';
MariaDB [(none)]> flush privileges;

此步驟完成。

3.3 啓動 MHA

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

mha (pid:7598) is running(0:PING_OK), master:192.168.11.12
上面的信息中“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 ~]# systemctl stop mairadb
3.4.2 在 manger 節點查看日誌
[root@manager ~]# tail -200 /etc/mha_master/manager.log 

Thu May 23 09:17:19 2019 - [info] Master failover to 192.168.11.11(192.168.11.12:3306) completed successfully.

表示 manager 檢測到192.168.11.11節點故障, 而後自動執行故障轉移, 將192.168.11.12提升爲主節點。
  注意,故障轉移完成後, 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/`date +%F-%T`-myql-all.sql
[root@slave1 ~]# scp /backup/2019-5-23-09\:57\:09-mysql-all.sql [email protected]:~/

然後在 原master 節點上進行數據恢復:

啓動並初始化 mariadb
[root@master ~]# systemctl start mariadb
[root@master ~]# mysql_secure_installation
還原數據
[root@master ~]# mysql < 2017-11-23-09\:57\:09-mysql-all.sql

接下來就是配置主從。照例查看一下現在的主的二進制日誌和位置,然後就進行如下設置:

查看主服務器信息
[root@slave1 ~]# mysql -uroot -p'keer'
MariaDB [(none)]> show master status;
配置主從
[root@master ~]# mysql -uroot -p'keer'
MariaDB [(none)]> show master status;
MariaDB [(none)]> change master to master_host='192.168.11.12',  master_user='slave',  master_password='keer', master_log_file='master-log.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.11.12
                  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

  5)再次使用的注意事項

由於/etc/mha_master/app1 下會記住之前的master的日誌文件

所以要把那個原來的master日誌文件刪除

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章