構建MHA實現MySQL高可用集羣架構

構建MHA實現MySQL高可用集羣架構

  原創

51tanxiaojun2018-04-22 18:50:52©著做權

文章標籤MySQL數據庫實現故障自動轉移文章分類數據庫

 https://blog.51cto.com/u_11034229/2106549

1、MHA簡介

MHA（Master HighAvailability）目前在MySQL高可用方面是一個相對成熟的解決方案，它由日本DeNA公司youshimaton（現就任於Facebook公司）開發，是一套優秀的做爲MySQL高可用性環境下故障切換和主從提高的高可用軟件。在MySQL故障切換過程當中，MHA能作到在0~30秒以內自動完成數據庫的故障切換操做，而且在進行故障切換的過程當中，MHA能在最大程度上保證數據的一致性，以達到真正意義上的高可用。

MHA裏有兩個角色一個是MHA Node（數據節點）另外一個是MHA Manager（管理節點）。

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服務器上，所以能夠保證全部節點的數據一致性

異步複製（Asynchronous replication）

MySQL默認的複製便是異步的，主庫在執行完客戶端提交的事務後會當即將結果返給給客戶端，並不關心從庫是否已經接收並處理，這樣就會有一個問題，主若是crash掉了，此時主上已經提交的事務可能並無傳到從上，若是此時，強行將從提高爲主，可能致使新主上的數據不完整。

全同步複製（Fully synchronousreplication）

指當主庫執行完一個事務，全部的從庫都執行了該事務才返回給客戶端。由於須要等待全部從庫執行完該事務才能返回，因此全同步複製的性能必然會收到嚴重的影響。

半同步複製（Semisynchronous replication）

介於異步複製和全同步複製之間，主庫在執行完客戶端提交的事務後不是馬上返回給客戶端，而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於異步複製，半同步複製提升了數據的安全性，同時它也形成了必定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。因此，半同步複製最好在低延時的網絡中使用。
下面來看看半同步複製的原理圖：

總結：異步與半同步異同

默認狀況下MySQL的複製是異步的，Master上全部的更新操做寫入Binlog以後並不確保全部的更新都被複制到Slave之上。異步操做雖然效率高，可是在Master/Slave出現問題的時候，存在很高數據不一樣步的風險，甚至可能丟失數據。
MySQL5.5引入半同步複製功能的目的是爲了保證在master出問題的時候，至少有一臺Slave的數據是完整的。在超時的狀況下也能夠臨時轉入異步複製，保障業務的正常使用，直到一臺salve追遇上以後，繼續切換到半同步模式。

工做原理

相較於其它HA軟件，MHA的目的在於維持MySQL Replication中Master庫的高可用性，其最大特色是能夠修復多個Slave之間的差別日誌，最終使全部Slave保持數據一致，而後從中選擇一個充當新的Master，並將其它Slave指向它。

-從宕機崩潰的master保存二進制日誌事件(binlogevents)。  

-識別含有最新更新的slave。  

-應用差別的中繼日誌(relay log)到其它slave。  

-應用從master保存的二進制日誌事件(binlogevents)。  

-提高一個slave爲新master。  

-使其它的slave鏈接新的master進行復制。

目前MHA主要支持一主多從的架構，要搭建MHA,要求一個複製集羣中必須最少有三臺數據庫服務器，一主二從，即一臺充當master，一臺充當備用master，另一臺充當從庫，由於至少須要三臺服務器。
相關軟件包

1. MHA監控服務器安裝:mha4mysql-manager-0.55-1.el5.noarch，mha4mysql-node-0.54-1.el5.noarch
2. 其餘主從集羣服務器安裝:mha4mysql-node-0.54-1.el5.noarch

MHA軟件包官網地址：  https://code.google.com/archive/p/mysql-master-ha/
使用到以下包：

mha4mysql-manager-0.55-1.el5.noarch

mha4mysql-node-0.54-1.el5.noarch

2、構建集羣架構基礎環境

實現環境：

| 角色 | IP地址 | 主機名 |Server Id | 類型 | OS
| -------- | -------- | -------- |
| Manager | 192.168.64.37 | manager | | 管理節點 | Centos7.2x86_64
| master| 192.168.64.7 | master1 | 1 | 主mysql | Centos7.2x86_64
| Candidate master | 192.168.64.17 |master2| 2 | 從mysql | Centos7.2x86_64
| slave | 192.168.64.27 | slave | 3 | 從mysql | Centos7.2x86_64

其中master對外提供寫服務，備選master（實際的slave，主機名master2）提供讀服務，slave也提供相關的讀服務，一旦master宕機，將會把備選master提高爲新的master，slave指向新的master，manager做爲管理服務器。

一、 在配置好全部主機IP地址後檢查selinux，firewalld設置，關閉全部主機selinux ，firewalld 服務以方便後期主從同步不出錯

vim /etc/sysconfig/selinux

SELINUX=disabled   本行替換爲

 

systemctl stop firewalld   關閉防火牆

2.同步服務器時間

vim /etc/chrony.conf

server 192.168.64.7 iburst   master2 slave配置與master1時間同步

 

三、
在四臺主機上都配置epel源
官網下載地址：點擊打開連接 wget  https://mirrors.ustc.edu.cn/epel/7/x86_64/Packages/e/epel-release-7-11.noarch.rpm
4.在四臺主機上創建ssh無交互登陸環境

[root@manager ~]#  ssh-keygen -t rsa

[root@manager ~]#  ssh-copy-id -i id_rsa.pub 192.168.64.37

[root@manager ~]#  scp authorized_keys id_rsa 192.168.64.17:/root/.ssh/

[root@manager ~]#  scp authorized_keys id_rsa 192.168.64.27:/root/.ssh/

[root@manager ~]#   scp authorized_keys id_rsa 192.168.64.7:/root/.ssh/

 

測試ssh登陸面密鑰

[root@master ~]# ssh root@192.168.64.37   

其它主機能夠分別測試下

3、 配置MySQL的主從複製

一、在主從節點安裝node節點包（master1 master2,slave）

[root@master ~]# ls

anaconda-ks.cfg  Downloads                             original-ks.cfg  reset.sh   Videos

Desktop          mha4mysql-node-0.54-0.el6.noarch.rpm  Pictures         reset.sql

Documents        Music                                 Public           Template

[root@master ~]# l  yum install mha*

二、修改my.cnf文件，配置主從同步
注意：若主MYSQL服務器已經存在，只是後期才搭建從MYSQL服務器，在置配數據同步前應先將主MYSQL服務器的要同步的數據庫拷貝到從MYSQL服務器上（如先在主MYSQL上備份數據庫，再用備份在從MYSQL服務器上恢復）
（1.）master1的主機配置：

innodb_file_per_table

log_bin

read_only

server_id=0

skip_name_resolve=1

（2.）master2的主機配置：

innodb_file_per_table

server_id=2

skip_name_resolve=1

read_only

relay_log_purge=0

log_bin

（3）slave的主機配置：

innodb_file_per_table

server_id=3

skip_name_resolve=1

read_only

relay_log_purge=0

log_bin

注意：重啓全部主機的mariadb服務！！！

（3.）建立用於主從複製的帳號「mharep」，在（master一、master2）主機上建立便可，建立MHA管理帳號「manager」在全部mysql服務器上都要建立。
master一、master2主機上的配置：

mysql>GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'192.168.64.%' IDENTIFIED BY 'centos';

mysql> GRANT ALL ON *.* TO 'mhauser'@'192.168.64.%' IDENTIFIED BY 'centos';

slave主機上的配置：

mysql> GRANT ALL ON *.* TO 'mhauser'@'192.168.64.%' IDENTIFIED BY 'centos';

開始建立主從複製：

查看master1的節點：

MariaDB [(none)]> show master logs;

+--------------------+-----------+

| Log_name           | File_size |

+--------------------+-----------+

| mariadb-bin.000001 |       502 |

| mariadb-bin.000002 |       487 |

| mariadb-bin.000003 |       504 |

| mariadb-bin.000004 |       245 |

+--------------------+-----------+

4 rows in set (0.04 sec)

 

master2主機上的配置：

建立主從複製，並開啓slave功能

mysql>CHANGE MASTER TO MASTER_HOST='192.168.64.7',MASTER_USER='repluser' ,MASTER_PASSWORD='centos',MASTER_LOG_FILE='mariadb-bin.000004',MASTER_LOG_POS=245;

mysql> start slave;

查看master2主機從的狀態，如下兩個值必須爲yes,表明從服務器能正常鏈接主服務器

Slave_IO_Running:Yes  

Slave_SQL_Running:Yes  

slave主機上的配置：

建立主從複製，並開啓salve功能

mysql>CHANGE MASTER TO MASTER_HOST='192.168.64.7',MASTER_USER='repluser' ,MASTER_PASSWORD='centos',MASTER_LOG_FILE='mariadb-bin.000004',MASTER_LOG_POS=245;

mysql> start slave;

查看slave主機從的狀態，如下兩個值必須爲yes,表明從服務器能正常鏈接主服務器

Slave_IO_Running:Yes  

Slave_SQL_Running:Yes

MariaDB [(none)]> show slave status\G;

*************************** 1. row ***************************

               Slave_IO_State: Waiting for master to send event

                  Master_Host: 192.168.64.7

                  Master_User: repluser

                  Master_Port: 3306

                Connect_Retry: 60

              Master_Log_File: mariadb-bin.000004

          Read_Master_Log_Pos: 245

               Relay_Log_File: mariadb-relay-bin.000002

                Relay_Log_Pos: 531

        Relay_Master_Log_File: mariadb-bin.000004

             Slave_IO_Running: Yes

            Slave_SQL_Running: Yes

              Replicate_Do_DB:

          Replicate_Ignore_DB:

           Replicate_Do_Table:

       Replicate_Ignore_Table:

      Replicate_Wild_Do_Table:

  Replicate_Wild_Ignore_Table:

                   Last_Errno: 0

                   Last_Error:

                 Skip_Counter: 0

          Exec_Master_Log_Pos: 245

              Relay_Log_Space: 827

              Until_Condition: None

               Until_Log_File:

                Until_Log_Pos: 0

           Master_SSL_Allowed: No

           Master_SSL_CA_File:

           Master_SSL_CA_Path:

              Master_SSL_Cert:

            Master_SSL_Cipher:

               Master_SSL_Key:

        Seconds_Behind_Master: 0

Master_SSL_Verify_Server_Cert: No

                Last_IO_Errno: 0

                Last_IO_Error:

               Last_SQL_Errno: 0

               Last_SQL_Error:

  Replicate_Ignore_Server_Ids:

             Master_Server_Id: 1

1 row in set (0.00 sec)

 

ERROR: No query specified

 

注意：

第一條grant命令是建立一個用於主從複製的賬號repluser，在master1和master2的主機上建立便可。

第二條grant命令是建立MHA管理帳號manager，全部mysql服務器上都須要建立。MHA會在配置文件裏要求能遠程登陸到數據庫，因此要進行必要的賦權。

4、安裝配置mysql-MHA

mha包括manager節點和data節點，data節點包括原有的MySQL複製結構中的主機，至少3臺，即1主2從，當masterfailover後，還能保證主從結構；主從複製集羣只需安裝node包。

manager server：運行監控腳本，負責monitoring和 auto-failover；mha manager節點須要安裝node包和manager包。
一、在manager主機上須要安裝（ mha4mysql-manager-0.55-0.el6.noarch.rpm和 mha4mysql-node-0.54-0.el6.noarch.rpm）兩個操做管理節點， 在3臺數據庫主機上只須要安裝MHA的node節點便可。

[root@manager ~]# ls

192.168.64.17    cobbler.ks            mha4mysql-manager-0.55-0.el6.noarch.rpm

192.168.64.27    ks-post.log           mha4mysql-node-0.54-0.el6.noarch.rpm

192.168.64.7     ks-post-nochroot.log  original-ks.cfg

anaconda-ks.cfg  ks-pre.log

[root@manager ~]#  yum install mha*

其餘三臺數據庫節點須要安裝MHA的node節點（過程略）！！！

1. 配置MHA

與絕大多數Linux應用程序相似，MHA的正確使用依賴於合理的配置文件。MHA的配置文件與mysql的my.cnf文件配置類似，採起的是param=value的方式來配置，配置文件位於管理節點，一般包括每個mysql server的主機名，mysql用戶名，密碼，工做目錄等等。

（1.）編輯/etc/masterha/app1.conf，內容以下：

[root@manager ~]# vim /etc/mastermha/app1.cnf

[server default]

user=mhauser

password=centos

manager_workdir=/data/mastermha/app1/

manager_log=/data/mastermha/app1/manager.log

remote_workdir=/data/mastermha/app1/

ssh_user=root

repl_user=repluser

repl_password=centos

ping_interval=1

 

[server1]

hostname=192.168.64.7

candidate_master=1

[server2]

hostname=192.168.64.17

candidate_master=1

[server3]

hostname=192.168.64.27

candidate_master=1

配置項的解釋：

manager_workdir=/masterha/app1 //設置manager的工做目錄  

manager_log=/masterha/app1/manager.log //設置manager的日誌  

user=manager//設置監控用戶manager  

password=123456  //監控用戶manager的密碼  

ssh_user=root  //ssh鏈接用戶  

repl_user=mharep  //主從複製用戶  

repl_password=123.abc //主從複製用戶密碼  

ping_interval=1   //設置監控主庫，發送ping包的時間間隔，默認是3秒，嘗試三次沒有迴應的時候自動進行railover  

master_binlog_dir=/usr/local/mysql/data   //設置master 保存binlog的位置，以便MHA能夠找到master的日誌，我這裏的也就是mysql的數據目錄  

candidate_master=1//設置爲候選master，若是設置該參數之後，發生主從切換之後將會將此從庫提高爲主庫。

SSH 有效性驗證：

[root@manager ~]# masterha_check_ssh --conf=/etc/mastermha/app1.cnf

Sun Apr 22 06:36:33 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.

/etc/masterha/app1.cnf:No such file or directory

 at /usr/share/perl5/vendor_perl/MHA/SSHCheck.pm line 148.

[root@manager ~]# masterha_check_ssh

masterha_check_ssh

[root@manager ~]# masterha_check_ssh --conf=/etc/mastermha/app1.cnf

Sun Apr 22 06:37:13 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.

Sun Apr 22 06:37:13 2018 - [info] Reading application default configurations from /etc/mastermha/app1.cnf..

Sun Apr 22 06:37:13 2018 - [info] Reading server configurations from /etc/mastermha/app1.cnf..

Sun Apr 22 06:37:13 2018 - [info] Starting SSH connection tests..

Sun Apr 22 06:37:18 2018 - [debug]

Sun Apr 22 06:37:14 2018 - [debug]  Connecting via SSH from root@192.168.64.27(192.168.64.27:22) to root@192.168.64.7(192.168.64.7:22)..

Sun Apr 22 06:37:16 2018 - [debug]   ok.

Sun Apr 22 06:37:16 2018 - [debug]  Connecting via SSH from root@192.168.64.27(192.168.64.27:22) to root@192.168.64.17(192.168.64.17:22)..

Sun Apr 22 06:37:17 2018 - [debug]   ok.

Sun Apr 22 06:37:18 2018 - [debug]

Sun Apr 22 06:37:14 2018 - [debug]  Connecting via SSH from root@192.168.64.17(192.168.64.17:22) to root@192.168.64.7(192.168.64.7:22)..

Sun Apr 22 06:37:16 2018 - [debug]   ok.

Sun Apr 22 06:37:16 2018 - [debug]  Connecting via SSH from root@192.168.64.17(192.168.64.17:22) to root@192.168.64.27(192.168.64.27:22)..

Sun Apr 22 06:37:17 2018 - [debug]   ok.

Sun Apr 22 06:37:18 2018 - [debug]

Sun Apr 22 06:37:13 2018 - [debug]  Connecting via SSH from root@192.168.64.7(192.168.64.7:22) to root@192.168.64.17(192.168.64.17:22)..

Sun Apr 22 06:37:17 2018 - [debug]   ok.

Sun Apr 22 06:37:17 2018 - [debug]  Connecting via SSH from root@192.168.64.7(192.168.64.7:22) to root@192.168.64.27(192.168.64.27:22)..

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that a host key has just been changed.

The fingerprint for the ECDSA key sent by the remote host is

SHA256:080GPU/VjQmyb/Ije4lASHgZDXJv5E/QOqAcAv0wfV0.

Please contact your system administrator.

Add correct host key in /root/.ssh/known_hosts to get rid of this message.

Offending ECDSA key in /root/.ssh/known_hosts:1

Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.

Sun Apr 22 06:37:18 2018 - [debug]   ok.

Sun Apr 22 06:37:18 2018 - [info] All SSH connection tests passed successfully.

集羣複製的有效性驗證：

注意：mysql數據庫必須都啓動

[root@manager ~]# masterha_check_repl --conf=/etc/mastermha/app1.cnf

注意：驗證成功的話會自動識別出全部服務器和主從情況！！！

在驗證時，若遇到這個錯誤：Can’t exec 「mysqlbinlog」 …

解決方法是在全部服務器上執行：

[css] view plain copy

ln -s /usr/local/mysql/bin/* /usr/local/bin/

啓動 manager：

[root@manager ~]# masterha_manager --conf=/etc/mastermha/app1.cnf

Sun Apr 22 06:39:35 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.

Sun Apr 22 06:39:35 2018 - [info] Reading application default configurations from /etc/mastermha/app1.cnf..

Sun Apr 22 06:39:35 2018 - [info] Reading server configurations from /etc/mastermha/app1.cnf..

注意：在應用Unix/Linux時，咱們通常想讓某個程序在後臺運行，因而咱們將常會用&在程序結尾來讓程序自動運行。好比咱們要運行mysql在後臺： /usr/local/mysql/bin/mysqld_safe –user=mysql&。但是有不少程序並不想mysqld同樣，這樣咱們就須要nohup命令，

5、模擬故障，檢測狀態轉移

一、停掉master1 的mariadb服務

[root@master ~]#  systemctl stop mariadb

（2.)查看 MHA 日誌
上面的配置文件中指定了日誌位置爲/data /masterha/app1/manager.log

[root@manager ~]# cat/masterha/app1/manager.log

從日誌信息中能夠看到master failover 已經成功了，並能夠看出故障轉移的大致流程

(3)檢查 slave 的複製
登陸 slave（192.168.64.27）的Mysql，查看 slave 狀態

mysql> show slave status\G;

能夠看到master 的 IP 如今爲 192.168.64.17,已經切換到和192.168.64.27同步了，原本是和192.168.64.7同步的，說明 MHA 已經把Candicatemaster(master2)提高爲了新的master，IO線程和SQL線程也正確運行，MHA 搭建成功!!!