技術實戰：基於 MHA 方式實現 MySQL 的高可用(轉)

時間 2019-11-19

標籤技術實戰基於 mha 方式實現 mysql 可用欄目 MySQL 简体版

原文原文鏈接

轉自：http://os.51cto.com/art/201307/401702_all.htmphp

MHA故障轉移能夠很好的幫咱們解決從庫數據的一致性問題，同時最大化挽回故障發生後的數據。本文分享了基於 MHA 方式實現 Mysql 的高可用的技術實戰，但願對您有所幫助。node

AD：51CTO網+ 首屆中國APP創新評選大賽火熱招募中……mysql

數據的重要性對於人們來講重要程度不說自明，在信息時代，數據有着比人們更大的力量,咱們也知道最近的斯諾登事件，軍事專家對於他掌握的數據給出的評價是，至關於美軍十個重裝甲師。linux

數據庫的價值可見一斑，數據庫的存在爲人們提供了更快的查詢，那麼在一個web網站中如何作到數據庫的高可用，保證持續提供服務，下面的實驗是經過MHA的故障轉移來實現。web

實現原理：MHA是由日本Mysql專家用Perl寫的一套Mysql故障切換方案以保障數據庫的高可用性，它的功能是能在0-30s以內實現主Mysql故障轉移（failover），sql

MHA故障轉移能夠很好的幫咱們解決從庫數據的一致性問題，同時最大化挽回故障發生後的數據。MHA裏有兩個角色一個是node節點一個是manager節點，要實現這個MHA，必須最少要三臺數據庫服務器，一主多備，即一臺充當master，一臺充當master的備份機，另一臺是從屬機，這裏實驗爲了實現更好的效果使用四臺機器，須要說明的是一旦主服務器宕機，備份機即開始充當master提供服務，若是主服務器上線也不會再成爲master了，由於若是這樣數據庫的一致性就被改變了。數據庫

實驗環境：vmware 9.0 RHEL5.5服務器

實驗所需軟件包：http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.52-0.noarch.rpm http://mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.52-0.noarch.rpmapp

實驗大致步驟：ssh

1 首先要保證虛擬機可以上網這裏我在vmware裏添加了第二塊網卡 一塊專門用於四臺機器通訊，一塊配置上網
2 關閉selinux和配置IP地址和本地yum源
3 配置epel源
4 配置ssh公鑰免登陸環境
5 修改hostname
6 配置hosts文件
7 配置Mysql的主從同步關係並經過grant命令賦權
8 安裝node包
9 在管理機安裝manager包
10  編輯主配置文件
11 測試及排錯
12 啓動

驗拓撲圖以下：

1 在配置好IP地址後檢查selinux設置

2 在四臺機器都配置epel源這裏我找了一個epel源

rpm –ivh http://dl.fedoraproject.org/pub/epel/5Server/i386/epel-release-5-4.noarch.rpm

3 創建ssh無密碼登陸環境

主Mysql

#ssh-keygen -t rsa

#ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.1 ----------------------爲何要在本機也要設置呢，由於manager節點安裝在這上面，如不設置在下面ssh檢查時會通不過。

#ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.2

#ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.3

#ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.4

過程示意圖（因其過程都同樣，故只示範192.168.1.1）

主備Mysql

#ssh-keygen -t rsa
#ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.1
#ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.3
#ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.4

從Mysql1

#ssh-keygen -t rsa
#ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.1
#ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.2
#ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.4

從Mysql2

#ssh-keygen -t rsa
#ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.1
#ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.2
#ssh-copy-id -i .ssh/id_rsa.pub root@192.168.1.3

測試ssh登陸

咱們在主Mysql上測試一下：

結果測試成功進入下一步操做

4 接下來步驟就是修改hostname了

爲了保險起見我想要從內存中和文件中修改，不重啓系統（內存中位置 /etc/sysconfig/network）。

192.168.1.1 hostname爲mastersql
192.168.1.2 hostname爲backupsql
192.168.1.3 hostname爲slavesql1
192.168.1.4 hostname爲slavesql2

5 配置hosts文件

配置好後分別拷貝到其餘三臺機器上：

6 配置mysql主從關係

在四臺系統經過yum安裝mysql

yum –y install mysql-server

在mastersql：

vi /etc/my.cnf

在裏面添加2 3 4 行定義id和二進制目錄：

在backupsql
vi /etc/my.cnf
在裏面添加2 3 4 5 6 7行

在slavesql1

vi /etc/my.cnf 不一樣的是第三行中的代碼其中意思是sql數據庫是隻讀的：

在slavesql2

vi /etc/my.cnf

配置好後重啓下mysql服務從新加載配置文件：

service mysqld restart

在mastersql中：

mysql> GRANT replication slave ON *.* TO 'kyo'@'%' identified by '123';-------------------賦給用戶有關操做權限
mysql> flush privileges;
#mysqldump -A -x > /tmp/full.sql  #scp /tmp/full.sql root@192.168.1.2:/tmp/
#scp /tmp/full.sql root@192.168.1.3:/tmp/
#scp /tmp/full.sql root@192.168.1.4:/tmp/
mysql> show master status;------------------記住position號碼（366）

分別在backupsql、slavesql一、slavesql2中作以下操做，這裏以backupsql機爲例：

只要看到Slave_IO_Running Slave_SQL_Running都爲yes就能夠了。

而後再就是賦權了，以前的一步賦權操做是權限是隻有replication,MHA會在配置文件裏要求能遠程登陸到數據庫，因此要進行必要的賦權。

在四臺機器中都作以下操做：

mysql> grant all privileges on *.* to 'root'@'mastersql' identified by '123';
mysql> flush privileges;
mysql> grant all privileges on *.* to 'root'@'backupsql' identified by '123';
mysql> flush privileges;
mysql> grant all privileges on *.* to 'root'@'slavesql1' identified by '123';
mysql> flush privileges;
mysql> grant all privileges on *.* to 'root'@'slavesql2' identified by '123';
mysql> flush privileges;

7 接下來就是開始正式安裝MHA了，先安裝節點包開始四臺機器都要安裝！

yum install perl-DBD-MySQL -----------------MHA是perl編寫的軟件須要perl支持以前yum安裝mysql已經安裝過了若是沒安裝過須要安裝這個依賴。

rpm -Uvh http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.52-0.noarch.rpm

8 節點配置完畢就開始配置管理節點了

yum –y install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager  -----------安裝依賴包
rpm -Uvh http://mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.52-0.noarch.rpm

管理節點安裝完畢後就應該去編輯主配文件了

vi /etc/app1.cnf 須要指出的是第二行第三行中以前提到的user和password是mysql中賦權的用戶：

檢查下SSH公鑰免密碼登陸

masterha_check_ssh --conf=/etc/app1.cnf

以前的都看不到了能夠看到最後檢測成功

再檢查下MySQL複製

masterha_check_repl --conf=/etc/app1.cnf---------------------因爲截圖過小直接貼出檢測文字能夠看出最後檢測都成功（雖然有些警告信息，不用去管它）。

[root@mastersql ~]# masterha_check_repl --conf=/etc/app1.cnf 
Mon Jul  1 02:08:33 2013 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. 
Mon Jul  1 02:08:33 2013 - [info] Reading application default configurations from /etc/app1.cnf.. 
Mon Jul  1 02:08:33 2013 - [info] Reading server configurations from /etc/app1.cnf.. 
Mon Jul  1 02:08:33 2013 - [info] MHA::MasterMonitor version 0.52. 
Mon Jul  1 02:08:33 2013 - [info] Dead Servers: 
Mon Jul  1 02:08:33 2013 - [info] Alive Servers: 
Mon Jul  1 02:08:33 2013 - [info]   192.168.1.1(192.168.1.1:3306) 
Mon Jul  1 02:08:33 2013 - [info]   192.168.1.2(192.168.1.2:3306) 
Mon Jul  1 02:08:33 2013 - [info]   192.168.1.3(192.168.1.3:3306) 
Mon Jul  1 02:08:33 2013 - [info]   192.168.1.4(192.168.1.4:3306) 
Mon Jul  1 02:08:33 2013 - [info] Alive Slaves: 
Mon Jul  1 02:08:33 2013 - [info]   192.168.1.2(192.168.1.2:3306)  Version=5.0.77-log (oldest major version between slaves) log-bin:enabled 
Mon Jul  1 02:08:33 2013 - [info]     Replicating from 192.168.1.1(192.168.1.1:3306) 
Mon Jul  1 02:08:33 2013 - [info]     Primary candidate for the new Master (candidate_master is set) 
Mon Jul  1 02:08:33 2013 - [info]   192.168.1.3(192.168.1.3:3306)  Version=5.0.77-log (oldest major version between slaves) log-bin:enabled 
Mon Jul  1 02:08:33 2013 - [info]     Replicating from 192.168.1.1(192.168.1.1:3306) 
Mon Jul  1 02:08:33 2013 - [info]     Not candidate for the new Master (no_master is set) 
Mon Jul  1 02:08:33 2013 - [info]   192.168.1.4(192.168.1.4:3306)  Version=5.0.77-log (oldest major version between slaves) log-bin:enabled 
Mon Jul  1 02:08:33 2013 - [info]     Replicating from 192.168.1.1(192.168.1.1:3306) 
Mon Jul  1 02:08:33 2013 - [info]     Not candidate for the new Master (no_master is set) 
Mon Jul  1 02:08:33 2013 - [info] Current Alive Master: 192.168.1.1(192.168.1.1:3306) 
Mon Jul  1 02:08:33 2013 - [info] Checking slave configurations.. 
Mon Jul  1 02:08:33 2013 - [warning]  read_only=1 is not set on slave 192.168.1.2(192.168.1.2:3306). 
Mon Jul  1 02:08:33 2013 - [warning]  relay_log_purge=0 is not set on slave 192.168.1.2(192.168.1.2:3306). 
Mon Jul  1 02:08:33 2013 - [warning]  relay_log_purge=0 is not set on slave 192.168.1.3(192.168.1.3:3306). 
Mon Jul  1 02:08:33 2013 - [warning]  relay_log_purge=0 is not set on slave 192.168.1.4(192.168.1.4:3306). 
Mon Jul  1 02:08:33 2013 - [info] Checking replication filtering settings.. 
Mon Jul  1 02:08:33 2013 - [info]  binlog_do_db= , binlog_ignore_db= 
Mon Jul  1 02:08:33 2013 - [info]  Replication filtering check ok. 
Mon Jul  1 02:08:33 2013 - [info] Starting SSH connection tests.. 
Mon Jul  1 02:08:36 2013 - [info] All SSH connection tests passed successfully. 
Mon Jul  1 02:08:36 2013 - [info] Checking MHA Node version.. 
Mon Jul  1 02:08:36 2013 - [info]  Version check ok. 
Mon Jul  1 02:08:36 2013 - [info] Checking SSH publickey authentication and checking recovery script configurations on the current master.. 
Mon Jul  1 02:08:36 2013 - [info]   Executing command: save_binary_logs --command=test --start_file=binlog.000003 --start_pos=4 --
binlog_dir=/var/lib/mysql,/var/log/mysql --output_file=/var/log/masterha/app1/save_binary_logs_test --manager_version=0.52 
Mon Jul  1 02:08:36 2013 - [info]   Connecting to root@192.168.1.1(192.168.1.1).. 
  Creating /var/log/masterha/app1 if not exists..    ok. 
  Checking output directory is accessible or not.. 
   ok. 
  Binlog found at /var/lib/mysql, up to binlog.000003 
Mon Jul  1 02:08:37 2013 - [info] Master setting check done. 
Mon Jul  1 02:08:37 2013 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers.. 
Mon Jul  1 02:08:37 2013 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user=root --slave_host=192.168.1.2 --slave_ip=192.168.1.2 --slave_port=3306 --workdir=/var/log/masterha/app1 --target_version=5.0.77-log --manager_version=0.52 --relay_log_info=/var/lib/mysql/relay-log.info  --slave_pass=xxx 
Mon Jul  1 02:08:37 2013 - [info]   Connecting to root@192.168.1.2(192.168.1.2).. 
mysqlbinlog version is 3.2 (included in MySQL Client 5.0 or lower). This is not recommended. Consider upgrading MySQL Client to 5.1 or higher. 
  Checking slave recovery environment settings.. 
  Opening /var/lib/mysql/relay-log.info ... ok. 
  Relay log found at /var/lib/mysql, up to mysql-relay-bin.000002 
  Temporary relay log file is /var/lib/mysql/mysql-relay-bin.000002 
  Testing mysql connection and privileges.. done. 
  Testing mysqlbinlog output.. done. 
  Cleaning up test file(s).. done. 
Mon Jul  1 02:08:37 2013 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user=root --slave_host=192.168.1.3 --slave_ip=192.168.1.3 --slave_port=3306 --workdir=/var/log/masterha/app1 --target_version=5.0.77-log --manager_version=0.52 --relay_log_info=/var/lib/mysql/relay-log.info  --slave_pass=xxx 
Mon Jul  1 02:08:37 2013 - [info]   Connecting to root@192.168.1.3(192.168.1.3)..  mysqlbinlog version is 3.2 (included in MySQL Client 5.0 or lower). This is not recommended. Consider upgrading MySQL Client to 5.1 or higher. 
  Checking slave recovery environment settings.. 
  Opening /var/lib/mysql/relay-log.info ... ok. 
  Relay log found at /var/lib/mysql, up to mysql-relay-bin.000002 
  Temporary relay log file is /var/lib/mysql/mysql-relay-bin.000002 
  Testing mysql connection and privileges.. done. 
  Testing mysqlbinlog output.. done. 
  Cleaning up test file(s).. done. 
Mon Jul  1 02:08:37 2013 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user=root --slave_host=192.168.1.4 --slave_ip=192.168.1.4 --slave_port=3306 --workdir=/var/log/masterha/app1 --target_version=5.0.77-log --manager_version=0.52 --relay_log_info=/var/lib/mysql/relay-log.info  --slave_pass=xxx 
Mon Jul  1 02:08:37 2013 - [info]   Connecting to root@192.168.1.4(192.168.1.4).. 
mysqlbinlog version is 3.2 (included in MySQL Client 5.0 or lower). This is not recommended. Consider upgrading MySQL Client to 5.1 or higher. 
Creating directory /var/log/masterha/app1.. done. 
  Checking slave recovery environment settings.. 
  Opening /var/lib/mysql/relay-log.info ... ok. 
  Relay log found at /var/lib/mysql, up to mysql-relay-bin.000002 
  Temporary relay log file is /var/lib/mysql/mysql-relay-bin.000002 
  Testing mysql connection and privileges.. done. 
  Testing mysqlbinlog output.. done. 
  Cleaning up test file(s).. done. 
Mon Jul  1 02:08:37 2013 - [info] Slaves settings check done. 
Mon Jul  1 02:08:37 2013 - [info] 
192.168.1.1 (current master) 
+--192.168.1.2 
+--192.168.1.3 
+--192.168.1.4
Mon Jul  1 02:08:37 2013 - [info] Checking replication health on 192.168.1.2.. 
Mon Jul  1 02:08:37 2013 - [info]  ok. 
Mon Jul  1 02:08:37 2013 - [info] Checking replication health on 192.168.1.3.. 
Mon Jul  1 02:08:37 2013 - [info]  ok. 
Mon Jul  1 02:08:37 2013 - [info] Checking replication health on 192.168.1.4.. 
Mon Jul  1 02:08:37 2013 - [info]  ok. 
Mon Jul  1 02:08:37 2013 - [warning] master_ip_failover_script is not defined. 
Mon Jul  1 02:08:37 2013 - [warning] shutdown_script is not defined. 
Mon Jul  1 02:08:37 2013 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK.

這時用虛擬機的話得要作個快照，由於下面咱們要進行兩個小實驗這個實驗是不可逆的

開啓MHA進程

這時咱們模擬主Mysql宕機，看看數據庫是否可以切換到備份機上

service mysqld stop

在從屬機中

mysql>show slave status \G

mysql已經成功的切換到備份機上，這時我還注意到一個問題就是這個切換過程不會當即切換，須要花費幾秒時間，也就是說數據在這個空檔是不能寫入的，這對於要求數據的查詢和寫入實時性要求較高的企業帶來了困難，如何解決這個問題，主要有兩個思路：

1 經過腳本實現failover（故障轉移）

2 經過keepalived實現虛擬IP 虛擬IP的地址隨着master的改變而漂移

先來第一種方式

若是仔細看上面的開啓進程中會注意到一個warning Mon Jul 1 02:08:37 2013 - [warning] master_ip_failover_script is not defined. 在/etc/app1.cnf中咱們註釋了這一行，如今在/etc/app1.cnf裏開啓這一行代碼，而後在/tmp /master_ip_failover寫入以下代碼：

#!/usr/bin/env php
<?php
$longopts = array(
'command:',
'ssh_user:',
'orig_master_host:',
'orig_master_ip:',
'orig_master_port:',
'new_master_host::',
'new_master_ip::',
'new_master_port::', );
$options = getopt(null, $longopts);
if ($options['command'] == 'start') {
$params = array(
'ip' => $options['new_master_ip'],
'port' => $options['new_master_port'],
);
$string = '<?php return ' . var_export($params, true) . '; ?>';
file_put_contents('config.php', $string, LOCK_EX); }
exit(0);
?>

這是一段PHP代碼若是機器中沒裝php模塊的話要執行 yum –y install php

以後賦給這個文件可執行權限 chmod +x /tmp/master_ip_failover，

再次檢查後的截圖總之是檢查OK了，此次再去把主Mysql服務器中止看看
再次運行MHA進程masterha_manager --conf=/etc/app1.cnf

而後中止mysql服務：

service mysqld stop

能夠看到master的host成了192.168.1.2 實現了最短期的故障轉移：

2 keepalived實現方式

首先還原快照實驗原理已經明白就是經過虛擬IP來管理master的狀態

在mastersql和backupsql中都安裝keepalived軟件

tar -zvxf keepalived-1\[1\].1.17.tar.gz
yum -y install  kernel-devel
ln -s /usr/src/kernels/2.6.18-164.el5-i686/ /usr/src/linux
cd keepalived-1.1.17/
yum –y install openssl-* 
./configure --prefix=/usr/local/keepalived

編譯後看到三個yes纔算成功若是出現兩個yes或者一個應該要檢查下內核軟鏈接作對了沒有：

make
make install
cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
mkdir -pv /etc/keepalived
cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/
ln -s /usr/local/keepalived/sbin/keepalived /sbin/
service keepalived restart

注意這裏若是下載的keepalived軟件包不同和kernel版本不同不要盲目複製粘貼該用tab命令補全就補全。

編輯mastersql的keepalived配置文件

vi /etc/keepalived/keepalived.conf 只編輯有效配置：

編輯backupsql的配置文件：

在mastersql上重啓keepalived服務後看ip addr

能夠看到eth0上有了另一個IP 即虛擬IP

編輯腳本文件大致意思是隻要檢測到mysql服務中止keepalived服務也中止，由於keepalived是經過組播方式告訴本網段本身還活着當mysql服務中止後keepalived還依然運行這時就須要中止keepalived讓另外一個主機得到虛擬IP，能夠在後臺運行這個腳本也能夠在keepalived配置文件加入這個腳本。

mastersql上keepalived配置以下：

interval 2 是每間隔兩秒執行一次腳本這個能夠本身調節

腳本文件放置路徑在/tmp/下注意這個也要被賦可執行權限！

開啓MHA進程masterha_manager --conf=/etc/app1.cnf

一切都作好了只等中止mysql服務了中止下試試

在backupsql上看ip addr：

在另外一臺slavesql1上查看slave status：

成功切換到192.168.1.2 OK 實驗完成。至此經過腳本和虛擬IP地址實現了高效率的故障轉移，實現了mysql的真正的高可用！

相關標籤/搜索

每日一句

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