數據的重要性對於人們來說重要程度不說自明，在信息時代，數據有着比人們更大的力量,我們也知道最近的斯諾登事件，軍事專家對於他掌握的數據給出的評價是，相當於美軍十個重裝甲師.
數據庫的價值可見一斑，數據庫的存在爲人們提供了更快的查詢，那麼在一個web網站中如何做到數據庫的高可用，保證持續提供服務，下面的實驗是通過MHA的故障轉移來實現
實現原理：MHA是由日本Mysql專家用Perl寫的一套Mysql故障切換方案以保障數據庫的高可用性，它的功能是能在0-30s之內實現主Mysql故障轉移（failover），
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.rpmhttp://mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.52-0.noarch.rpm
實驗大體步驟：
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 [email protected] ----------------------爲什麼要在本機也要設置呢，因爲manager節點安裝在這上面，如不設置在下面ssh檢查時會通不過
#ssh-copy-id -i .ssh/id_rsa.pub [email protected]
#ssh-copy-id -i .ssh/id_rsa.pub [email protected]
#ssh-copy-id -i .ssh/id_rsa.pub [email protected]
過程示意圖（因其過程都一樣，故只示範192.168.1.1）
主備Mysql
#ssh-keygen -t rsa
#ssh-copy-id -i .ssh/id_rsa.pub [email protected]
#ssh-copy-id -i .ssh/id_rsa.pub [email protected]
#ssh-copy-id -i .ssh/id_rsa.pub [email protected]
從Mysql1
#ssh-keygen -t rsa
#ssh-copy-id -i .ssh/id_rsa.pub [email protected]
#ssh-copy-id -i .ssh/id_rsa.pub [email protected]
#ssh-copy-id -i .ssh/id_rsa.pub [email protected]
從Mysql2
#ssh-keygen -t rsa
#ssh-copy-id -i .ssh/id_rsa.pub [email protected]
#ssh-copy-id -i .ssh/id_rsa.pub [email protected]
#ssh-copy-id -i .ssh/id_rsa.pub [email protected]
測試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、slavesql1、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 [email protected](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 [email protected](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 [email protected](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 [email protected](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已經成功的切換到備份機上，這時我還注意到一個問題 就是這個切換過程不會立即切換，需要花費幾秒時間，也就是說數據在這個空檔是不能寫入的，這對於要求數據的查詢和寫入實時性要求較高的企業帶來了困難，如何解決這個問題，
通過keepalived實現虛擬IP 虛擬IP的地址隨着master地位的改變而漂移,這樣做的好處是實現數據庫的訪問通過一個IP來訪問
實驗原理已經明白 就是通過虛擬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/下 注意 這個也要被賦可執行權限！
cat /tmp/mysql.sh
開啓MHA進程masterha_manager --conf=/etc/app1.cnf
一切都做好了只等停止mysql服務了 停止下試試
在backupsql上看ip addr
在另一臺slavesql1上查看slave status
成功切換到192.168.1.2 OK 實驗完成 至此通過腳本和虛擬IP地址實現了高效率的故障轉移 實現了mysql的真正的高可用!
最後感謝下隋老師對我的無私指導~_~