該文章轉自: https://www.cloudbility.com/club/7104.html 目錄 一、當前高可用方案 1、Heartbeat+DRBD 2、MySQL Cluster 3、全局事務ID 4、PXC 5、MHA的優勢 1)故障切換快 2)master故障不會導致數據不一致 3) ...
該文章轉自: https://www.cloudbility.com/club/7104.html
目錄
- 一、當前高可用方案
- 1、Heartbeat+DRBD
- 2、MySQL Cluster
- 3、全局事務ID
- 4、PXC
- 5、MHA的優勢
- 1)故障切換快
- 2)master故障不會導致數據不一致
- 3)無需修改當前的MySQL設置
- 4)無需增加大量的伺服器
- 5)無性能下降
- 6)適用於任何存儲引擎
- 二、MHA簡介:
- 1、MHA結構
- 1)MHA Manager
- 1.Manager工具包主要工具
- 2)MHA Node
- 1.Node工具包
- 3)註意
- 1)MHA Manager
- 2、MAH工作原理
- 1、MHA結構
- 三、部署MHA
- 1、環境準備
- 2、安裝epel源
- 3、環境初始化
- 1)修改每台主機名
- 2)主機名解析
- 3)ssh無密碼登錄
- 四、規劃mysql
- 1)安裝mysql
- 2)配置master、slave01和slave02之間的主從複製
- 3)在master、slave01上創建主從同步的賬號。
- 4)在master上執行命令,查看master狀態信息
- 5)在slave01和slave02上執行主從同步
- 五、規劃mha
- 1)創建mha管理用的複製賬號
- 2)在3台主機上(master、slave01和slave02)上分別安裝mha4mysql-node包
- 3)在manager上安裝mha4mysql-manager和mha4mysql-node包
- 4)修改manager端mha的配置文件
- 5)檢查ssh是否暢通
- 6)masterha_check_repl工具檢查mysql主從複製是否成功
- 六、mha實驗模擬
- 1)在每次做mha實驗的時候,我們都最好先執行如下命令做檢測
- 2)在manager端啟動mha服務並時刻監控日誌文件的輸出變化
- 3)測試master宕機後會自動切換
- 4)恢復master服務
- 5)再次啟動MHA的manager服務,並停止slave01
- 6)恢復slave01服務
- 7)重啟MHA的manager服務
- 七、通過vip實現mysql的高可用
- 1)修改/usr/local/mha/mha.cnf
- 2)修改腳本/usr/local/mha/scripts/master_ip_failover
- 3)模擬故障進行切換
- 八、MHA日常維護命令
- 1、查看ssh登陸是否成功
- 2、查看複製是否建立好
- 3、啟動mha
- 4、檢查啟動的狀態
- 5、停止mha
- 6、failover後下次重啟
- 九、FAQ(常見問題解答)
- 1、可能報錯1
- 2、可能報錯2
- 3、可能報錯3
- 4、可能報錯4
- 5、可能報錯5
- 6、小知識
-
一、當前高可用方案
1、Heartbeat+DRBD
開銷:需要額外添加處於被動狀態的master server(並不處理應用流量) 性能:為了實現DRBD複製環境的高可用,innodb-flush-log-at-trx-commit和sync-binlog必須設置為1,這樣會導致寫性能下降。
一致性:在master上必要的binlog時間可能會丟失,這樣slave就無法進行複製,導致產生數據一致性問題。
2、MySQL Cluster
MySQL Cluster真正實現了高可用,但是使用的是NDB存儲引擎,並且SQL節點有單點故障問題。
半同步複製(5.5+) 半同步複製大大減少了“binlog events只存在故障master上”的問題。
在提交時,保證至少一個slave(並不是所有的)接收到binlog,因此一些slave可能沒有接收到binlog。
3、全局事務ID
在二進位文件中添加全局事務ID(global transaction id)需要更改binlog格式,在5.1/5.5版本中不支持。
在應用方面有很多方法可以直線全局事務ID,但是仍避免不了複雜度、性能、數據丟失或者一致性的問題。
4、PXC
PXC實現了服務高可用,數據同步時是併發複製。但是僅支持InnoDB引擎,所有的表都要有主鍵。鎖衝突、死鎖問題相對較多等等問題。
5、MHA的優勢
1)故障切換快
在主從複製集群中,只要從庫在複製上沒有延遲,MHA通常可以在數秒內實現故障切換。9-10秒內檢查到master故障,可以選擇在7-10秒關閉master以避免出現裂腦,幾秒鐘內,將差異中繼日誌(relay log)應用到新的master上,因此總的宕機時間通常為10-30秒。恢復新的master後,MHA並行的恢復其餘的slave。即使在有數萬台slave,也不會影響master的恢復時間。
2)master故障不會導致數據不一致
當目前的master出現故障是,MHA自動識別slave之間中繼日誌(relay log)的不同,並應用到所有的slave中。這樣所有的salve能夠保持同步,只要所有的slave處於存活狀態。和Semi-Synchronous Replication一起使用,(幾乎)可以保證沒有數據丟失。
3)無需修改當前的MySQL設置
MHA的設計的重要原則之一就是儘可能地簡單易用。MHA工作在傳統的MySQL版本5.0和之後版本的主從複製環境中。和其它高可用解決方法比,MHA並不需要改變MySQL的部署環境。MHA適用於非同步和半同步的主從複製。
啟動/停止/升級/降級/安裝/卸載MHA不需要改變(包擴啟動/停止)MySQL複製。當需要升級MHA到新的版本,不需要停止MySQL,僅僅替換到新版本的MHA,然後重啟MHA Manager就好了。
MHA運行在MySQL 5.0開始的原生版本上。一些其它的MySQL高可用解決方案需要特定的版本(比如MySQL集群、帶全局事務ID的MySQL等等),但並不僅僅為了master的高可用才遷移應用的。在大多數情況下,已經部署了比較舊MySQL應用,並且不想僅僅為了實現Master的高可用,花太多的時間遷移到不同的存儲引擎或更新的前沿發行版。MHA工作的包括5.0/5.1/5.5的原生版本的MySQL上,所以並不需要遷移。
4)無需增加大量的伺服器
MHA由MHA Manager和MHA Node組成。
MHA Node運行在需要故障切換/恢復的MySQL伺服器上,因此並不需要額外增加伺服器。
MHA Manager運行在特定的伺服器上,因此需要增加一臺(實現高可用需要2台),但是MHA Manager可以監控大量(甚至上百台)單獨的master,因此,並不需要增加大量的伺服器。即使在一臺slave上運行MHA Manager也是可以的。綜上,實現MHA並沒用額外增加大量的服務。
5)無性能下降
MHA適用與非同步或半同步的MySQL複製。監控master時,MHA僅僅是每隔幾秒(預設是3秒)發送一個ping包,並不發送重查詢。可以得到像原生MySQL複製一樣快的性能。
6)適用於任何存儲引擎
MHA可以運行在只要MySQL複製運行的存儲引擎上,並不僅限制於InnoDB,即使在不易遷移的傳統的MyISAM引擎環境,一樣可以使用MHA。
-
二、MHA簡介:
MHA(Master High Availability),是比較成熟的MySQL高可用方案。MHA能夠在30秒內實現故障切換,並能在故障切換中,最大可能的保證數據一致性。目前淘寶也正在開發相似產品TMHA,目前已支持一主一從。
1、MHA結構
該軟體由兩部分組成:MHA Manager(管理節點)和MHA Node(數據節點)。
1)MHA Manager
可以單獨部署在一臺獨立的機器上管理多個master-slave集群,也可以部署在一臺slave節點上。MHA Manager主要運行一些工具,比如masterha_manager工具實現自動監控MySQL Master和實現master故障切換,其它工具實現手動實現master故障切換、線上master轉移、連接檢查等等。
1.Manager工具包主要工具
masterha_check_ssh 檢查MHA的SSH配置狀況 masterha_check_repl 檢查MySQL複製狀況 masterha_manger 啟動MHA masterha_check_status 檢測當前MHA運行狀態 masterha_master_monitor 檢測master是否宕機 masterha_master_switch 控制故障轉移(自動或者手動) masterha_conf_host 添加或刪除配置的server信息
2)MHA Node
MHA Node 運行在每台MySQL伺服器上MHA Manager會定時探測集群中的master節點,當master出現故障時,它可以自動將最新數據的slave提升為新的master,然後將所有其他的slave重新指向新的master。整個故障轉移過程對應用程式完全透明。
部署在所有運行MySQL的伺服器上,無論是master還是slave。主要作用有三個。
Ⅰ、保存二進位日誌 如果能夠訪問故障master,會拷貝master的二進位日誌
II、應用差異中繼日誌 從擁有最新數據的slave上生成差異中繼日誌,然後應用差異日誌。
III、清除中繼日誌 在不停止SQL線程的情況下刪除中繼日誌
1.Node工具包
這些工具通常由MHA Manager的腳本觸發,無需人為操作主要包括以下幾個工具:
save_binary_logs 保存和複製master的二進位日誌 apply_diff_relay_logs 識別差異的中繼日誌事件並將其差異的事件應用於其他的slave filter_mysqlbinlog 去除不必要的ROLLBACK事件(MHA已不再使用這個工具) purge_relay_logs 清除中繼日誌(不會阻塞SQL線程)
3)註意
為了儘可能的減少主庫硬體損壞宕機造成的數據丟失,因此在配置MHA的同時建議配置成MySQL 5.5的半同步複製。關於半同步複製原理各位自己進行查閱。(不是必須)
2、MAH工作原理
1.從宕機崩潰的Master保存二進位日誌事件(binlog event);
2.識別含有最新更新的Slave;
3.應用差異的中繼日誌(relay log)到其他Slave;
4.應用從Master保存的二進位日誌事件;
5.提升一個Slave為新的Master;
6.使其他的Slave連接新的Master進行複製;
-
三、部署MHA
1、環境準備
[root@server01 ~]# cat /etc/redhat-release CentOS release 6.8 (Final) [root@server01 ~]# uname -r 2.6.32-642.el6.x86_64
2、安裝epel源
所有節點
#備份 mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup #下載epel源 wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-6.repo #生成緩存 yum makecache
3、環境初始化
1)修改每台主機名
172.16.1.241 master 172.16.1.242 slave01 172.16.1.243 slave02 172.16.1.244 manager
其中master對外提供寫服務,備選master(實際的slave,主機名slave01)提供讀服務,slave也提供相關的讀服務,一旦master宕機,將會把備選master提升為新的master,slave指向新的master。
2)主機名解析
#每台伺服器執行修改主機名解析
echo ''' 172.16.1.241 master 172.16.1.242 slave01 172.16.1.243 slave02 172.16.1.244 manager''' >>/etc/hosts
3)ssh無密碼登錄
使用key登錄,工作中常用,伺服器之間無需密碼驗證的。關於配置使用key登錄,一點需要註意:不能禁止 password 登陸,否則會出現錯誤
註意:所以全部機器都要相互做密鑰登錄。伺服器間,無密碼ssh登錄 #主機:master執行命令
[root@master ~]# ssh-keygen -t rsa [root@master ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@manager [root@master ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@slave01 [root@master ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@slave02
#主機:slave01執行命令
[root@slave01 ~]# ssh-keygen -t rsa [root@slave01 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@manager [root@slave01 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@master [root@slave01 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@slave02
#主機: slave02執行命令
[root@slave02 ~]# ssh-keygen -t rsa [root@slave02 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@manager [root@slave02 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@master [root@slave02 ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@slave01
#主機:manager執行命令
[root@manager ~]# ssh-keygen -t rsa [root@manager ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@master [root@manager ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@slave01 [root@manager ~]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@slave02
-
四、規劃mysql
1)安裝mysql
#master配置文件/etc/my.cnf 核心配置如下:
basedir = /application/mysql datadir = /application/mysql/data port = 3306 server_id = 241 socket = /tmp/mysql.sock log-bin=mysql-bin log-slave-updates expire_logs_days = 10
#slave01配置文件/etc/my.cnf 核心配置如下:
basedir = /application/mysql datadir = /application/mysql/data port = 3306 server_id = 242 socket = /tmp/mysql.sock log-bin=mysql-bin log-slave-updates expire_logs_days = 10
#slave02配置文件/etc/my.cnf 核心配置如下:
basedir = /application/mysql datadir = /application/mysql/data port = 3306 server_id = 243 socket = /tmp/mysql.sock log-bin=mysql-bin log-slave-updates expire_logs_days = 10 read_only = 1
2)配置master、slave01和slave02之間的主從複製
註意:binlog-do-db 和 replicate-ignore-db 設置必須相同。 MHA 在啟動時候會檢測過濾規則,如果過濾規則不同,MHA 不啟動監控和故障轉移。
在MySQL5.6 的Replication配置中,master端同樣要開啟兩個重要的選項,server-id和log-bin,並且選項server-id在全局架構中並且唯一,不能被其它主機使用,這裡採用主機ip地址的最後一位充當server-id的值;slave端要開啟relay-log;
#主機: master執行命令
[root@master ~]# egrep "log-bin|server_id" /etc/my.cnf server_id = 241 log-bin=mysql-bin
#主機: slave01執行命令
[root@slave01 ~]# egrep "log-bin|server_id" /etc/my.cnf server_id = 242 log-bin=mysql-bin
#主機: slave02執行命令
[root@slave02 ~]# egrep "log-bin|server_id" /etc/my.cnf server_id = 243 log-bin=mysql-bin
3)在master、slave01上創建主從同步的賬號。
slave01是備用master,這個也需要建立授權用戶。
#master [root@master ~]# mysql -e "grant replication slave on *.* to 'backup'@'172.16.1.%' identified by 'backup';flush privileges; #slave01 [root@slave01 ~]# mysql -e "grant replication slave on *.* to 'backup'@'172.16.1.%' identified by 'backup';flush privileges;"
4)在master上執行命令,查看master狀態信息
[root@master ~]# mysql -e 'show master status;' +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000007 | 107 | | | +------------------+----------+--------------+------------------+
5)在slave01和slave02上執行主從同步
#slave01配置主從
[root@slave01 ~]# mysql mysql> change master to master_host='172.16.1.241',master_user='backup',master_password='backup',master_port=3306,master_log_file='mysql-bin.000007',master_log_pos=107; Query OK, 0 rows affected (0.12 sec) mysql> start slave; Query OK, 0 rows affected (0.00 sec) mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 172.16.1.241 Master_User: backup Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000007 Read_Master_Log_Pos: 107 Relay_Log_File: slave01-relay-bin.000002 Relay_Log_Pos: 253 Relay_Master_Log_File: mysql-bin.000007 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: 107 Relay_Log_Space: 411 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: 241 1 row in set (0.00 sec)
#slave02配置主從
[root@slave02 ~]# mysql mysql> change master to master_host='172.16.1.241',master_user='backup',master_password='backup',master_port=3306,master_log_file='mysql-bin.000007',master_log_pos=107; Query OK, 0 rows affected (0.12 sec) mysql> start slave; Query OK, 0 rows affected (0.00 sec) mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 172.16.1.241 Master_User: backup Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000007 Read_Master_Log_Pos: 107 Relay_Log_File: slave01-relay-bin.000002 Relay_Log_Pos: 253 Relay_Master_Log_File: mysql-bin.000007 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: 107 Relay_Log_Space: 411 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: 241 1 row in set (0.00 sec)
#至此主從已經配置完成!
-
五、規劃mha
1)創建mha管理用的複製賬號
每台資料庫(master、slave01、slave02)上都要創建賬號,在這裡以其中master為例.。
[root@master ~]# mysql -e "grant all privileges on *.* to 'mha_rep'@'172.16.1.%' identified by '123456';flush privileges;" [root@master ~]# mysql mysql> select host,user from mysql.user;
2)在3台主機上(master、slave01和slave02)上分別安裝mha4mysql-node包
安裝完成後會在/usr/local/bin目錄下生成以下腳本文件:
-r-xr-xr-x 1 root root 15498 4月 2 16:04 apply_diff_relay_logs # 識別差異的中繼日誌事件並將其差異的事件應用於其他的slave -r-xr-xr-x 1 root root 4807 4月 2 16:04 filter_mysqlbinlog # 去除不必要的ROLLBACK事件(MHA已不再使用這個工具) -r-xr-xr-x 1 root root 7401 4月 2 16:04 purge_relay_logs # 清除中繼日誌(不會阻塞SQL線程) -r-xr-xr-x 1 root root 7263 4月 2 16:04 save_binary_logs # 保存和複製master的二進位日誌
這裡以master為例,其它主機同理。
[root@master ~]# yum install perl-DBD-MySQL -y [root@master ~]# rpm -ivh https://downloads.mariadb.com/files/MHA/mha4mysql-node-0.54-0.el6.noarch.rpm
3)在manager上安裝mha4mysql-manager和mha4mysql-node包
MHA Manager中主要包括了幾個管理員的命令行工具,例如master_manger,master_master_switch等。MHA Manger也依賴於perl模塊,具體如下:
安裝完成後會在/usr/local/bin目錄下麵生成以下腳本文件
-r-xr-xr-x 1 root root 15498 4月 2 15:59 apply_diff_relay_logs # 識別差異的中繼日誌事件並將其差異的事件應用於其他的slave -r-xr-xr-x 1 root root 4807 4月 2 15:59 filter_mysqlbinlog # 去除不必要的ROLLBACK事件(MHA已不再使用這個工具) -r-xr-xr-x 1 root root 1995 4月 2 16:21 masterha_check_repl # 檢查MySQL複製狀況 -r-xr-xr-x 1 root root 1779 4月 2 16:21 masterha_check_ssh # 檢查MHA的SSH配置狀況 -r-xr-xr-x 1 root root 1865 4月 2 16:21 masterha_check_status # 檢測當前MHA運行狀態 -r-xr-xr-x 1 root root 3201 4月 2 16:21 masterha_conf_host # 添加或刪除配置的server信息 -r-xr-xr-x 1 root root 2517 4月 2 16:21 masterha_manager # 啟動MHA -r-xr-xr-x 1 root root 2165 4月 2 16:21 masterha_master_monitor # 檢測master是否宕機 -r-xr-xr-x 1 root root 2373 4月 2 16:21 masterha_master_switch # 控制故障轉移(自動或者手動) -r-xr-xr-x 1 root root 3749 4月 2 16:21 masterha_secondary_check # -r-xr-xr-x 1 root root 1739 4月 2 16:21 masterha_stop # -r-xr-xr-x 1 root root 7401 4月 2 15:59 purge_relay_logs # 清除中繼日誌(不會阻塞SQL線程) -r-xr-xr-x 1 root root 7263 4月 2 15:59 save_binary_logs # 保存和複製master的二進位日誌
複製相關腳本到/usr/local/bin目錄(軟體包解壓縮後就有了,不是必須,因為這些腳本不完整,需要自己修改,這是軟體開發著留給我們自己發揮的,如果開啟下麵的任何一個腳本對應的參數,而對應這裡的腳本又沒有修改,則會報錯,自己被坑的很慘)
[root@manager ~]# cd mha4mysql-manager-0.56/samples/scripts/ # 這是我們下載解壓軟體的目錄 [root@manager scripts]# ll 總用量 32 -rwxr-xr-x 1 root root 3443 1月 8 2012 master_ip_failover #自動切換時vip管理的腳本,不是必須,如果我們使用keepalived的,我們可以自己編寫腳本完成對vip的管理,比如監控mysql,如果mysql異常,我們停止keepalived就行,這樣vip就會自動漂移 -rwxr-xr-x 1 root root 9186 1月 8 2012 master_ip_online_change #線上切換時vip的管理,不是必須,同樣可以可以自行編寫簡單的shell完成 -rwxr-xr-x 1 root root 11867 1月 8 2012 power_manager #故障發生後關閉主機的腳本,不是必須 -rwxr-xr-x 1 root root 1360 1月 8 2012 send_report #因故障切換後發送報警的腳本,不是必須,可自行編寫簡單的shell完成。 [root@manager ~]# cp * /usr/local/bin/
#在manager上安裝mha4mysql-manager和mha4mysql-node包
[root@manager ~]# yum install perl cpan perl-DBD-MySQL perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Net-Telnet -y [root@manager ~]# rpm -ivh https://downloads.mariadb.com/files/MHA/mha4mysql-node-0.54-0.el6.noarch.rpm [root@manager ~]# wget https://downloads.mariadb.com/files/MHA/mha4mysql-manager-0.56.tar.gz [root@manager ~]# tar zvxf mha4mysql-manager-0.56.tar.gz [root@manager ~]# cd mha4mysql-manager-0.56 [root@manager ~]# perl Makefile.PL [root@manager mha4mysql-manager-0.56]# make && make install [root@manager mha4mysql-manager-0.56]# mkdir -p /usr/local/mha/scripts [root@manager mha4mysql-manager-0.56]# cp samples/conf/app1.cnf /usr/local/mha/mha.cnf [root@manager mha4mysql-manager-0.56]# cp samples/scripts/* /usr/local/mha/scripts/
4)修改manager端mha的配置文件
記得去註釋
[root@manager mha4mysql-manager-0.56]# vim /usr/local/mha/mha.cnf [server default] user=mha_rep #MHA管理mysql的用戶名 password=123456 #MHA管理mysql的密碼 manager_workdir=/usr/local/mha #MHA的工作目錄 manager_log=/usr/local/mha/manager.log #MHA的日誌路徑 ssh_user=root #免秘鑰登陸的用戶名 repl_user=backup #主從複製賬號,用來在主從之間同步數據 repl_password=backup ping_interval=1 #ping間隔時間,用來檢查master是否正常 [server1] hostname=172.16.1.241 master_binlog_dir=/application/mysql/data/ candidate_master=1 #master宕機後,優先啟用這台作為master [server2] hostname=172.16.1.242 master_binlog_dir=/application/mysql/data/ candidate_master=1 [server3] hostname=172.16.1.243 master_binlog_dir=/application/mysql/data/ no_master=1
5)檢查ssh是否暢通
註意:所有主機之間必須做SSH免密鑰登錄。否則報錯。研究了兩天。(通過查看MHA的功能實現過程發現)
[root@manager ~]# masterha_check_ssh --conf=/usr/local/mha/mha.cnf Mon Apr 3 21:42:33 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. Mon Apr 3 21:42:33 2017 - [info] Reading application default configurations from /usr/local/mha/mha.cnf.. Mon Apr 3 21:42:33 2017 - [info] Reading server configurations from /usr/local/mha/mha.cnf.. Mon Apr 3 21:42:33 2017 - [info] Starting SSH connection tests.. Mon Apr 3 21:42:33 2017 - [debug] Mon Apr 3 21:42:33 2017 - [debug] Connecting via SSH from [email protected](172.16.1.241:22) to [email protected](172.16.1.242:22).. Mon Apr 3 21:42:33 2017 - [debug] ok. Mon Apr 3 21:42:33 2017 - [debug] Connecting via SSH from [email protected](172.16.1.241:22) to [email protected](172.16.1.243:22).. Mon Apr 3 21:42:33 2017 - [debug] ok. Mon Apr 3 21:42:34 2017 - [debug] Mon Apr 3 21:42:34 2017 - [debug] Connecting via SSH from [email protected](172.16.1.243:22) to [email protected](172.16.1.241:22).. Mon Apr 3 21:42:34 2017 - [debug] ok. Mon Apr 3 21:42:34 2017 - [debug] Connecting via SSH from [email protected](172.16.1.243:22) to [email protected](172.16.1.242:22).. Mon Apr 3 21:42:34 2017 - [debug] ok. Mon Apr 3 21:42:34 2017 - [debug] Mon Apr 3 21:42:33 2017 - [debug] Connecting via SSH from [email protected](172.16.1.242:22) to [email protected](172.16.1.241:22).. Mon Apr 3 21:42:33 2017 - [debug] ok. Mon Apr 3 21:42:33 2017 - [debug] Connecting via SSH from [email protected](172.16.1.242:22) to [email protected](172.16.1.243:22).. Mon Apr 3 21:42:34 2017 - [debug] ok. Mon Apr 3 21:42:34 2017 - [info] All SSH connection tests passed successfully.
#如果得到以上結果,表明主機之間ssh互信是暢通的
6)masterha_check_repl工具檢查mysql主從複製是否成功
註意:slave01 slave02和master確保已經做好主從複製。否則出錯。(研究22個小時)不懂perl 挺麻煩的。
[root@manager ~]# masterha_check_repl --conf=/usr/local/mha/mha.cnf Mon Apr 3 21:44:13 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. Mon Apr 3 21:44:13 2017 - [info] Reading application default configurations from /usr/local/mha/mha.cnf.. Mon Apr 3 21:44:13 2017 - [info] Reading server configurations from /usr/local/mha/mha.cnf.. Mon Apr 3 21:44:13 2017 - [info] MHA::MasterMonitor version 0.56. Mon Apr 3 21:44:14 2017 - [info] Dead Servers: Mon Apr 3 21:44:14 2017 - [info] Alive Servers: Mon Apr 3 21:44:14 2017 - [info] 172.16.1.241(172.16.1.241:3306) Mon Apr 3 21:44:14 2017 - [info] 172.16.1.242(172.16.1.242:3306) Mon Apr 3 21:44:14 2017 - [info] 172.16.1.243(172.16.1.243:3306) Mon Apr 3 21:44:14 2017 - [info] Alive Slaves: Mon Apr 3 21:44:14 2017 - [info] 172.16.1.242(172.16.1.242:3306) Version=5.5.32-log (oldest major version between slaves) log-bin:enabled Mon Apr 3 21:44:14 2017 - [info] Replicating from 172.16.1.241(172.16.1.241:3306) Mon Apr 3 21:44:14 2017 - [info] Primary candidate for the new Master (candidate_master is set) Mon Apr 3 21:44:14 2017 - [info] 172.16.1.243(172.16.1.243:3306) Version=5.5.32-log (oldest major version between slaves) log-bin:enabled Mon Apr 3 21:44:14 2017 - [info] Replicating from 172.16.1.241(172.16.1.241:3306) Mon Apr 3 21:44:14 2017 - [info] Not candidate for the new Master (no_master is set) Mon Apr 3 21:44:14 2017 - [info] Current Alive Master: 172.16.1.241(172.16.1.241:3306) Mon Apr 3 21:44:14 2017 - [info] Checking slave configurations.. Mon Apr 3 21:44:14 2017 - [info] read_only=1 is not set on slave 172.16.1.242(172.16.1.242:3306). Mon Apr 3 21:44:14 2017 - [warning] relay_log_purge=0 is not set on slave 172.16.1.242(172.16.1.242:3306). Mon Apr 3 21:44:14 2017 - [warning] relay_log_purge=0 is not set on slave 172.16.1.243(172.16.1.243:3306). Mon Apr 3 21:44:14 2017 - [info] Checking replication filtering settings.. Mon Apr 3 21:44:14 2017 - [info] binlog_do_db= , binlog_ignore_db= Mon Apr 3 21:44:14 2017 - [info] Replication filtering check ok. Mon Apr 3 21:44:14 2017 - [info] Starting SSH connection tests.. Mon Apr 3 21:44:16 2017 - [info] All SSH connection tests passed successfully. Mon Apr 3 21:44:16 2017 - [info] Checking MHA Node version.. Mon Apr 3 21:44:16 2017 - [info] Version check ok. Mon Apr 3 21:44:16 2017 - [info] Checking SSH publickey authentication settings on the current master.. Mon Apr 3 21:44:16 2017 - [info] HealthCheck: SSH to 172.16.1.241 is reachable. Mon Apr 3 21:44:17 2017 - [info] Master MHA Node version is 0.54. Mon Apr 3 21:44:17 2017 - [info] Checking recovery script configurations on the current master.. Mon Apr 3 21:44:17 2017 - [info] Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/application/mysql/data/ --output_file=/var/tmp/save_binary_logs_test --manager_version=0.56 --start_file=mysql-bin.000007 Mon Apr 3 21:44:17 2017 - [info] Connecting to [email protected](172.16.1.241).. Creating /var/tmp if not exists.. ok. Checking output directory is accessible or not.. ok. Binlog found at /application/mysql/data/, up to mysql-bin.000007 Mon Apr 3 21:44:17 2017 - [info] Master setting check done. Mon Apr 3 21:44:17 2017 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers.. Mon Apr 3 21:44:17 2017 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user='mha_rep' --slave_host=172.16.1.242 --slave_ip=172.16.1.242 --slave_port=3306 --workdir=/var/tmp --target_version=5.5.32-log --manager_version=0.56 --relay_log_info=/application/mysql/data/relay-log.info --relay_dir=/application/mysql/data/ --slave_pass=xxx Mon Apr 3 21:44:17 2017 - [info] Connecting to [email protected](172.16.1.242:22).. Checking slave recovery environment settings.. Opening /application/mysql/data/relay-log.info ... ok. Relay log found at /application/mysql/data, up to slave01-relay-bin.000002 Temporary relay log file is /application/mysql/data/slave01-relay-bin.000002 Testing mysql connection and privileges.. done. Testing mysqlbinlog output.. done. Cleaning up test file(s).. done. Mon Apr 3 21:44:17 2017 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user='mha_rep' --slave_host=172.16.1.243 --slave_ip=172.16.1.243 --slave_port=3306 --workdir=/var/tmp --target_version=5.5.32-log --manager_version=0.56 --relay_log_info=/application/mysql/data/relay-log.info --relay_dir=/application/mysql/data/ --slave_pass=xxx Mon Apr 3 21:44:17 2017 - [info] Connecting to [email protected](172.16.1.243:22).. Checking slave recovery environment settings.. Opening /application/mysql/data/relay-log.info ... ok. Relay log found at /application/mysql/data, up to slave02-relay-bin.000002 Temporary relay log file is /application/mysql/data/slave02-relay-bin.000002 Testing mysql connection and privileges.. done. Testing mysqlbinlog output.. done. Cleaning up test file(s).. done. Mon Apr 3 21:44:18 2017 - [info] Slaves settings check done. Mon Apr 3 21:44:18 2017 - [info] 172.16.1.241 (current master) +--172.16.1.242 +--172.16.1.243 Mon Apr 3 21:44:18 2017 - [info] Checking replication health on 172.16.1.242.. Mon Apr 3 21:44:18 2017 - [info] ok. Mon Apr 3 21:44:18 2017 - [info] Checking replication health on 172.16.1.243.. Mon Apr 3 21:44:18 2017 - [info] ok. Mon Apr 3 21:44:18 2017 - [warning] master_ip_failover_script is not defined. Mon Apr 3 21:44:18 2017 - [warning] shutdown_script is not defined. Mon Apr 3 21:44:18 2017 - [info] Got exit code 0 (Not master dead). MySQL Replication Health is OK.