MySQL高可用架構之MHA

什麼是MHA？

　　首先在我們進行架構部署前，簡單地瞭解一下什麼是MHA？
　　MHA（Master HA）是一款開源的 MySQL 的高可用程序，它爲 MySQL 主從複製架構提供了 automating master failover 功能。MHA 在監控到 master 節點故障時，會提升其中擁有最新數據的 slave 節點成爲新的 master 節點，在此期間，MHA 會通過於其它從節點獲取額外信息來避免一致性方面的問題。MHA 還提供了 master 節點的在線切換功能，即按需切換 master/slave 節點。
　　MHA 服務有兩種角色，MHA Manager(管理節點)和 MHA Node(數據節點)：
　　 (1)MHA Manager：通常單獨部署在一臺獨立機器上管理多個 master/slave 集羣(組)，每個 master/slave 集羣稱作一個 application，用來管理統籌整個集羣。
　　 (2)MHA node：運行在每臺 MySQL 服務器上(master/slave/manager)，它通過監控具備解析和清理 logs 功能的腳本來加快故障轉移。主要是接收管理節點所發出指令的代理，代理需要運行在每一個mysql節點上。簡單講node就是用來收集從節點服務器上所生成的bin-log。對比打算提升爲新的主節點之上的從節點的是否擁有並完成操作，如果沒有發給新主節點在本地應用後提升爲主節點。

MHA的工作原理：

　（1）從宕機崩潰的master保存二進制日誌事件（binlog events）;
　（2）識別含有最新更新的slave;
　（3）應用差異的中繼日誌(relay log) 到其他slave;
　（4）應用從master保存的二進制日誌事件(binlog events);
　（5）提升一個slave爲新master;
　（6）使用其他的slave連接新的master進行復制。

實驗

  　　在瞭解了上面的概念後我們就可以開始來實際操作了。
一、環境準備：
　　MHA對MYSQL複製環境有特殊要求，各節點都要開啓二進制日誌及中繼日誌，各從節點必須顯示啓用其read-only屬性，並關閉relay_log_purge功能等，這裏對配置做事先說明。
　　本實驗環境共有四個節點，其角色分配如下：
   　　 node1:MariaDB master
   　　 node2: MariaDB slave
   　　 node3: MariaDB slave
    　　node4: MHA Manager
　
　　　　　　　　　　　　　MHA架構圖
1、主節點master配置：

[mysqld] 
server-id = 1 
log-bin = master-log 
relay-log = relay-log 
skip_name_resolve = ON

2、所有slave節點的配置

[mysqld] 
server-id=2
relay-log=relay-bin
log-bin=slave-bin
read-only=on
relay-log-purge=0 #是否自動清空不再需要中繼日誌
skip_name_resolve = on
log_slave_updates = 1 #使得更新的數據寫進二進制日誌中

3、按上述要求分別配置好主從節點之後，按MYSQL複製配置架構的配置方式將其配置完成並啓動master節點和各slave節點，以及爲各slave節點啓動其IO和SQL線程，確保主從複製運行無誤。操作如下：
Master節點上：

MariaDB [(none)]> grant replication slave,replication client on *.* to slave@'172.17.%.%' identified by '111111';
MariaDB [(none)]> show master status;

Slave 節點上：

MariaDB [(none)]> change master to master_host='172.17.253.210', master_user='slave', master_password='111111', master_log_file='master-bin.000001', master_log_pos=414;
MariaDB [(none)]>start slave；啓動複製線程。
MariaDB [(none)]>show slave status\G;

二、安裝配置MHA
1、在所有MYSQL節點授權擁有管理權限的用戶可在本地網絡中有其他節點上遠程訪問。當然，此時僅需要且只能在master節點運行類似如下SQL語句即可。
grant all on *.* to mhaadmin@'172.17.%.%' identified by '111111';
2、準備基於SSH互信通信環境： MHA集羣中的各節點彼此之間均需要基於ssh互信通信，以實現遠程控制及數據管理功能。簡單起見，可在Manager節點生成密鑰對兒，並設置其可遠程連接本地主機後，將私鑰文件及authorized_keys文件複製給餘下的所有節點即可。（其它各節點按照同樣的步驟，以保證四個節點互相之間能免密登錄。）

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-copy-id -i .ssh/id_rsa.pub [email protected]

3、進行MHA安裝包安裝

Manager 節點： #yum localinstall mha4mysql-manager-0.56-0.el6.noarch.rpm 
所有節點，包括Manager: #yum localinstall mha4mysql-node-0.56-0.el6.norch.rpm

4、定義MHA管理配置文件爲MHA專門創建一個管理用戶，方便以後使用，在mysql的主節點上，三個節點自動同步

mkdir /etc/masterha/app1.cnf
[root@manager masterha]#vim /etc/masterha/app1.cnf
[server default] //適用於server1,2,3個server的配置 
user=mhaadmin //mha管理用戶 
password=111111 //mha管理密碼 
manager_workdir=/etc/masterha/app1
manager_log=/etc/masterha/manager.log  // mha_master自己的日誌文件 
remote_workdir=/etc/masterha/mha  //每個遠程主機的工作目錄在何處 
ssh_user=root // 基於ssh的密鑰認證 
repl_user=slave//數據庫用戶名 
repl_password=111111 //數據庫密碼 
ping_interval=1 // ping間隔時長 

[server1]  
hostname=172.17.253.210 
ssh_port=22  
candidate_master=1  
port=3306
[server2] 
hostname=172.17.254.222  
ssh_port=22  
candidate_master=1 
port=3306
[server3] 
hostname=172.17.254.224 
ssh_port=22 
candidate_master=1
port=3306

配置文件中註釋在執行時要去掉，否則在下步檢查ssh時會出錯。
6、檢查各節點ssh是否能夠通信
[root@manager ~]#masterha_check_ssh --conf=/etc/masterha/app1.cnf
檢查管理的MySQL複製集羣的連接配置參數是否OK：
[root@manager ~]#masterha_check_repl --conf=/etc/masterha/app1.cnf
三、啓動MHA

[root@manager ~]#nohup masterha_manager 
--conf=/etc/masterha/app1.cnf&>/etc/masterha/manager.log & 
[1] 72494

檢查狀態是否已啓動：

[root@manager ~]#masterha_check_status --conf=/etc/masterha/app1.cnf 
app1 (pid:72494) is running(0:PING_OK), master:172.17.253.210
上面的信息中“app1 (pid:4978)is running(0:PING_OK)”表示MHA服務運行OK， 否則，則會顯示爲類似“app1 is stopped(1:NOT_RUNNINg).”
如果要停止MHA，需要使用master_stop命令：
[root@manager ~]#masterha_stop -conf=/etc/mastermha/app1.cnf

四、測試MHA故障轉移
(1)在master節點關閉mariadb服務,模擬主節點數據崩潰
[root@manager ~]#systemctl stop mariadb
(2)在manager節點查看日誌：
/etc/masterha/manager.log，日誌文件中出現如下信息，表示manager檢測到172.17.253.210節點故障，而後自動執行故障轉移，將172.17.254.222提升爲主節點。注意，故障轉移完成後，manager將會自動停止，此時使用 masterha_check_status命令檢測將會遇到錯誤提示，如下所示：

 [root@manager ~]#masterha_check_status –conf=/etc/masterha/app1.cnf 
app1 is stopped(2:NOT_RINNING).

(3)提供新的從節點以修復複製集羣原有 master 節點故障後，需要重新準備好一個新的 MySQL 節點。基於來自於 master 節點的備份恢復數據後，將其配置爲新的 master 的從節點即可。注意，新加入的節點如果爲新增節點，其 IP 地址要配置爲原來 master 節點的 IP，否則，還需要修改 app1.cnf 中相應的 ip 地址。隨後再次啓動 manager，並再次檢測其狀態。修改/etc/masterha/app1.cnf的文件爲（即把原來的server2提升爲server1主節點，把candidate_master=1刪除）：

[server default] //適用於server1,2,3個server的配置 
user=mhaadmin //mha管理用戶 
password=111111 //mha管理密碼 
manager_workdir=/etc/masterha/app1
manager_log=/etc/masterha/manager.log  // mha_master自己的日誌文件 
remote_workdir=/etc/masterha/mha  //每個遠程主機的工作目錄在何處 
ssh_user=root // 基於ssh的密鑰認證 
repl_user=slave//數據庫用戶名 
repl_password=111111 //數據庫密碼 
ping_interval=1 // ping間隔時長 
[server1]
hostname=172.17.254.222
ssh_port=22
port=3306
[server2]
hostname=172.17.254.224
ssh_port=22
candidate_master=1
port=3306

此時再檢測狀態,並且主節點已經切換：

[root@manager ~]#masterha_check_status --conf=/etc/masterha/app1.cnf 
app1 (pid:73791) is running(0:PING_OK), master:172.17.254.222
[root@manager ~]#masterha_check_repl --conf=/etc/masterha/app1.cnf       
Thu Nov 23 09:18:31 2017 - [info] Reading default configuration from /etc/masterha_default.cnf..
Thu Nov 23 09:18:31 2017 - [info] Reading application default configuration from /etc/masterha/app1.cnf..
Thu Nov 23 09:18:31 2017 - [info] Reading server configuration from /etc/masterha/app1.cnf..
Thu Nov 23 09:18:31 2017 - [info] MHA::MasterMonitor version 0.56.
Thu Nov 23 09:18:32 2017 - [info] GTID failover mode = 0
Thu Nov 23 09:18:32 2017 - [info] Dead Servers:
Thu Nov 23 09:18:32 2017 - [info] Alive Servers:
Thu Nov 23 09:18:32 2017 - [info]   172.17.254.222(172.17.254.222:3306)
Thu Nov 23 09:18:32 2017 - [info]   172.17.254.224(172.17.254.224:3306)
Thu Nov 23 09:18:32 2017 - [info] Alive Slaves:
Thu Nov 23 09:18:32 2017 - [info]   172.17.254.224(172.17.254.224:3306)  Version=5.5.52-MariaDB (oldest major version between slaves) log-bin:enabled
Thu Nov 23 09:18:32 2017 - [info]     Replicating from 172.17.254.222(172.17.254.222:3306)
Thu Nov 23 09:18:32 2017 - [info]     Primary candidate for the new Master (candidate_master is set)
Thu Nov 23 09:18:32 2017 - [info] Current Alive Master: 172.17.254.222(172.17.254.222:3306)
Thu Nov 23 09:18:32 2017 - [info] Checking slave configurations..
Thu Nov 23 09:18:32 2017 - [warning]  relay_log_purge=0 is not set on slave 172.17.254.224(172.17.254.224:3306).
Thu Nov 23 09:18:32 2017 - [info] Checking replication filtering settings..
Thu Nov 23 09:18:32 2017 - [info]  binlog_do_db= , binlog_ignore_db= 
Thu Nov 23 09:18:32 2017 - [info]  Replication filtering check ok.
Thu Nov 23 09:18:32 2017 - [info] GTID (with auto-pos) is not supported
Thu Nov 23 09:18:32 2017 - [info] Starting SSH connection tests..
Thu Nov 23 09:18:34 2017 - [info] All SSH connection tests passed successfully.
Thu Nov 23 09:18:34 2017 - [info] Checking MHA Node version..
Thu Nov 23 09:18:34 2017 - [info]  Version check ok.
Thu Nov 23 09:18:34 2017 - [info] Checking SSH publickey authentication settings on the current master..
Thu Nov 23 09:18:35 2017 - [info] HealthCheck: SSH to 172.17.254.222 is reachable.
Thu Nov 23 09:18:35 2017 - [info] Master MHA Node version is 0.56.
Thu Nov 23 09:18:35 2017 - [info] Checking recovery script configurations on 172.17.254.222(172.17.254.222:3306)..
Thu Nov 23 09:18:35 2017 - [info]   Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/var/lib/mysql,/var/log/mysql --output_file=/etc/masterha/mha/save_binary_logs_test --manager_version=0.56 --start_file=slave-bin.000001 
Thu Nov 23 09:18:35 2017 - [info]   Connecting to [email protected](172.17.254.222:22).. 
  Creating /etc/masterha/mha if not exists..    ok.
  Checking output directory is accessible or not..
   ok.
  Binlog found at /var/lib/mysql, up to slave-bin.000001
Thu Nov 23 09:18:36 2017 - [info] Binlog setting check done.
Thu Nov 23 09:18:36 2017 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..
Thu Nov 23 09:18:36 2017 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user='mhaadmin' --slave_host=172.17.254.224 --slave_ip=172.17.254.224 --slave_port=3306 --workdir=/etc/masterha/mha --target_version=5.5.52-MariaDB --manager_version=0.56 --relay_log_info=/var/lib/mysql/relay-log.info  --relay_dir=/var/lib/mysql/  --slave_pass=xxx
Thu Nov 23 09:18:36 2017 - [info]   Connecting to [email protected](172.17.254.224:22).. 
  Checking slave recovery environment settings..
    Opening /var/lib/mysql/relay-log.info ... ok.
    Relay log found at /var/lib/mysql, up to relay-bin.000002
    Temporary relay log file is /var/lib/mysql/relay-bin.000002
    Testing mysql connection and privileges.. done.
    Testing mysqlbinlog output.. done.
    Cleaning up test file(s).. done.
Thu Nov 23 09:18:36 2017 - [info] Slaves settings check done.
Thu Nov 23 09:18:36 2017 - [info] 
172.17.254.222(172.17.254.222:3306) (current master)
 +--172.17.254.224(172.17.254.224:3306)

Thu Nov 23 09:18:36 2017 - [info] Checking replication health on 172.17.254.224..
Thu Nov 23 09:18:36 2017 - [info]  ok.
Thu Nov 23 09:18:36 2017 - [warning] master_ip_failover_script is not defined.
Thu Nov 23 09:18:36 2017 - [warning] shutdown_script is not defined.
Thu Nov 23 09:18:36 2017 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.
檢查無誤再次運行：
[root@manager ~]# masterha_manager 
--conf=/etc/masterha/app1.cnf&>/etc/masterha/manager.log &     
[2] 74401

新節點上線，故障轉換恢復注意事項：

(1)、在生產環境中，當你的主節點掛了後，一定要在從節點上做一個備份，拿着備份文件把主節點手動提升爲從節點，並指明從哪一個日誌文件的位置開始複製
(2)、每一次自動完成轉換後，每一次的(replication health )檢測不ok始終都是啓動不了必須手動修復主節點，除非你改配置文件
(3)、手動修復主節點提升爲從節點後，再次運行檢測命令

[root@manager ~]#masterha_check_repl --conf=/etc/masterha/app1.cnf 
..............
MySQL Replication Health is OK.

(4)、再次運行起來就恢復成功了

[root@manager ~]#masterha_manager --conf=/etc/masterha/app1.cnf
[root@manager ~]#masterha_check_status --conf=/etc/masterha/app1.cnf 
app1 (pid:73791) is running(0:PING_OK), master:172.17.254.222

MySQL高可用架構之MHA

什麼是MHA？

MHA的工作原理：

實驗

新節點上線，故障轉換恢復注意事項：

京東面試：如何進行JVM調優？

美團一面：項目中有 10000 個 if else 如何優化？想了半天，被問懵了！

Python 將PowerPoint (PPT/PPTX) 轉爲HTML

SQL優化-20231016

Linux中執行shell腳本的4種方法

Linux的五個查找命令：find,locate,whereis,which,type

SecureCRT 8.0的安裝及Linux基本命令介紹

apache配置文件詳解

raid分類

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結