MySQL高可用
（1）MMM: Multi-Master Replication Manager for MySQL，Mysql主主復制管理器是一套靈活的腳本程序，基於perl實現，用來對mysql replication進行監控和故障遷移，並能管理mysql Master-Master復制的配置(同一時間只有一個節點是可寫的)
官網： http://www.mysql-mmm.org
https://code.google.com/archive/p/mysql-master-master/downloads #國外網站，需要梯子上網
（2）MHA： Master High Availability，對主節點進行監控，可實現自動故障轉移至其它從節點；通過提升某一從節點為新的主節點，基於主從復制實現，還需要客戶端配合實現，目前MHA主要支持一主多從的架構，要搭建MHA,要求一個復制集群中必須最少有三台數 據庫服務器，一主二從，即一台充當master，一台充當備用master，另外一台充當從庫，出於機器成本的考慮，淘寶進行了改造，目前淘寶TMHA已經支持一主一從
官網:https://code.google.com/archive/p/mysql-master-ha/
（3）Galera Cluster：wsrep(MySQL extended with the Write Set Replication)
通過wsrep協議在全局實現復制；任何一節點都可讀寫，不需要主從復制，實現多主讀寫
（4）GR（Group Replication）：MySQL官方提供的組復制技術(MySQL 5.7.17引入的技術)，基於原生復制技術Paxos算法
github對應manager下載地址：https://github.com/yoshinorim/mha4mysql-manager/releases/
github對應node下載地址：https://github.com/yoshinorim/mha4mysql-node/releases/
MHA工作原理
1 從宕機崩潰的master保存二進制日志事件（binlog events） 2 識別含有最新更新的slave 3 應用差異的中繼日志（relay log）到其他的slave 4 應用從master保存的二進制日志事件（binlog events） 5 提升一個slave為新的master 6 使其他的slave連接新的master進行復制
1、環境准備
A主機： 監控主服務器狀態 192.168.34.105
B主機：主服務器 192.168.34.101
C主機： 從服務器1 192.168.34.102
D主機： 從服務器2 192.168.34.103
2、實現三台服務器的一主多從
注意點：
① 每個節點都需開啟二進制和中繼日志，因為主會宕機，當主的機器修復完畢，可以作為從繼續使用，所以中繼日志是必須的；從也會在主宕機的時候，頂為主，所以二進制日志也是必須的
② 各從節點必須顯示啟用其read-only 屬性，並關閉relay_log_purge 清理中繼日志的功能
③ 注意每個mysql 的server-id都不能相同
開始配置主從服務器的配置文件
B主服務器上配置
vim /etc/my.cnf [mysqld] server-id=1 # 服務ID log_bin=/data/logbin/mysql-bin # 指定二進制日志路徑 binlog_format=ROW # 以行的方式保存二進制日志 skip-name-resolve # 不將IP地址解析成名字 relay_log=relay-log # 開啟中繼日志
C從服務器修改配置文件
vim /etc/my.cnf [mysqld] server-id=2 read-only log_bin=/data/logbin/mysql-bin binlog_format=row skip-name-resolve relay_log_purge=0 # 默認是清除中繼日志，選擇不清除 relay_log=relay-log # 開啟中繼日志
D從服務器上修改配置文件
[mysqld] server-id=3 read-only skip-name-resolve relay_log_purge=0 # 不清除中繼日志 log_bin=/data/logbin/mysql-bin binlog_format=row relay_log=relay-log #開啟中繼日志
配置完主從復制之后，將三個服務器都重啟
systemctl restart mariadb
先清除B、C、D之前實驗所做的二進制日志文件,生產中不要使用，最好是將主服務器的數據完全備份，然后導入到從服務器，從服務器以最新二進制日志開始復制。
MariaDB [(none)]> reset master;
在B主機授權一個復制賬號並實現主從復制
再在B主服務器創建一個賦予復制權限的用戶
MariaDB [(none)]> grant replication slave on *.* to rpluser@'192.168.34.%' identified by 'centos';
在C從服務器上啟動復制線程
MariaDB [(none)]> CHANGE MASTER TO
-> MASTER_HOST='192.168.34.101',
-> MASTER_USER='rpluser',
-> MASTER_PASSWORD='centos',
-> MASTER_PORT=3306,
-> MASTER_LOG_FILE='mysql-bin.000001',
-> MASTER_LOG_POS=245;
開啟C從服務器slave
start slave
在D從服務器上開啟復制線程和slave
MariaDB [(none)]> CHANGE MASTER TO 開啟復制線程
-> MASTER_HOST='192.168.34.101',
-> MASTER_USER='rpluser',
-> MASTER_PASSWORD='centos',
-> MASTER_PORT=3306,
-> MASTER_LOG_FILE='mysql-bin.000001',
-> MASTER_LOG_POS=245;
Query OK, 0 rows affected (0.42 sec)
MariaDB [(none)]>
MariaDB [(none)]> start slave; 開啟slave
Query OK, 0 rows affected (0.00 sec)
在B主機創建一個mha管理監控主從復制主機的賬號
在B主服務器上創建一個賦予所有權限的用戶，可隨時管理主節點的對象用戶賬號，當主節點宕機后，會選舉一個新的主節點
MariaDB [(none)]> grant all on *.* to mhauser@'192.168.34.%' identified by 'magedu';
驗證主從復制
在B主服務器上導入數據庫，並查看結果
[root@centos7~]#mysql < hellodb_innodb.sql 導入數據庫 MariaDB [(none)]> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | hellodb | | mysql | | performance_schema | | test | +--------------------+
在C和D從服務器上查看此時的數據庫已經復制過去
MariaDB [(none)]> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | hellodb | | mysql | | performance_schema | | test | +--------------------+
3、配置MHA的准備
（1）MHA的安裝
MHA軟件由兩部分組成，Manager工具包和Node工具包
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個包 rz傳到A主機上，manager包依賴於epel源，需要打開epel源倉庫進行安裝：
github對應manager下載地址：https://github.com/yoshinorim/mha4mysql-manager/releases/
github對應node下載地址：https://github.com/yoshinorim/mha4mysql-node/releases/
mha4mysql-manager-0.56-0.el6.noarch.rpm
mha4mysql-node-0.56-0.el6.noarch.rpm
在管理節點上安裝兩個包：
mha4mysql-manager mha4mysql-node
在被管理節點安裝：
mha4mysql-node
在A主機安裝MHA包：
[root@centos6~]#yum install mha4mysql* -y
在B、C、D主機上安裝mha4mysql-node包
[root@node2 ~]# yum install mha4mysql-node-0.56-0.el6.noarch.rpm -y
（2）實現各個節點都基於KEY驗證
在A主機上生成基於Key驗證，先生成公私鑰對
[root@centos6~]#ssh-keygen
在A主機上生成自己的公鑰文件
[root@centos6~]#ssh-copy-id 192.168.34.105
將生成的公鑰文件整個目錄全部復制到其他服務器上
[root@centos6~]#scp -rp /root/.ssh 192.168.34.101:/root/ 復制到B主服務器的 [root@centos6~]#scp -rp /root/.ssh 192.168.34.102:/root/ 復制到C從服務器 [root@centos6~]#scp -rp /root/.ssh 192.168.34.103:/root/ 復制到D從服務器
定義MHA 管理配置文件，在A主機上新建一個目錄文件並配置相關的配置文件
[root@centos6~]#mkdir /etc/mha/ 新建一個mha目錄，存放配置文件路徑 [root@centos6~]#vim /etc/mha/cluster1.conf 新建一個cluster1,cnf配置文件並在里邊配置相關數據 [server default] user=mhauser #管理用戶 password=magedu # 管理密碼 manager_workdir=/data/mastermha/cluster1/ mha工作路徑 manager_log=/data/mastermha/cluster1/manager.log mha日志文件 remote_workdir=/data/mastermha/cluster1/ 每個遠程主機的工作目錄 master_binlog_dir=/data/logbin/ # 指定數據庫的二進制日志文件路徑，此路徑是主從復制數據庫的路徑，如果單獨存放二進制日志，一定要指定，否則會報錯。 ssh_user=root #使用ssh遠程連接 repl_user=rpluser # master授權的用戶名 repl_password=centos # master授權的密碼 ping_interval=1 ping時間時長 [server1] hostname=192.168.34.101 主服務器IP地址 candidate_master=1 [server2] hostname=192.168.34.102 候選主服務器IP地址 candidate_master=1 # 開啟候選功能 [server3] hostname=192.168.34.103 candidate_master=1 # 開啟候選功能
開啟服務前檢測
在所有節點實現相互之間ssh key驗證
[root@centos7~]#masterha_check_ssh --conf=/etc/mha/cluster1.conf Wed Nov 27 10:41:04 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. Wed Nov 27 10:41:04 2019 - [info] Reading application default configuration from /etc/mha/cluster1.conf.. Wed Nov 27 10:41:04 2019 - [info] Reading server configuration from /etc/mha/cluster1.conf.. Wed Nov 27 10:41:04 2019 - [info] Starting SSH connection tests.. Wed Nov 27 10:41:05 2019 - [debug] Wed Nov 27 10:41:04 2019 - [debug] Connecting via SSH from root@192.168.34.101(192.168.34.101:22) to root@192.168.34.102(192.168.34.102:22).. Wed Nov 27 10:41:05 2019 - [debug] ok. Wed Nov 27 10:41:05 2019 - [debug] Connecting via SSH from root@192.168.34.101(192.168.34.101:22) to root@192.168.34.103(192.168.34.103:22).. Warning: Permanently added '192.168.34.103' (ECDSA) to the list of known hosts. Wed Nov 27 10:41:05 2019 - [debug] ok. Wed Nov 27 10:41:06 2019 - [debug] Wed Nov 27 10:41:04 2019 - [debug] Connecting via SSH from root@192.168.34.102(192.168.34.102:22) to root@192.168.34.101(192.168.34.101:22).. Wed Nov 27 10:41:05 2019 - [debug] ok. Wed Nov 27 10:41:05 2019 - [debug] Connecting via SSH from root@192.168.34.102(192.168.34.102:22) to root@192.168.34.103(192.168.34.103:22).. Wed Nov 27 10:41:06 2019 - [debug] ok. Wed Nov 27 10:41:06 2019 - [debug] Wed Nov 27 10:41:05 2019 - [debug] Connecting via SSH from root@192.168.34.103(192.168.34.103:22) to root@192.168.34.101(192.168.34.101:22).. Warning: Permanently added '192.168.34.103' (ECDSA) to the list of known hosts. Wed Nov 27 10:41:05 2019 - [debug] ok. Wed Nov 27 10:41:05 2019 - [debug] Connecting via SSH from root@192.168.34.103(192.168.34.103:22) to root@192.168.34.102(192.168.34.102:22).. Wed Nov 27 10:41:06 2019 - [debug] ok. Wed Nov 27 10:41:06 2019 - [info] All SSH connection tests passed successfully. 驗證已經成功
驗證復制集群的連接配置參數是否OK
[root@openstack ~]# masterha_check_repl --conf=/etc/mha/cluster1.conf
Sun Mar 29 20:42:03 2020 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Sun Mar 29 20:42:03 2020 - [info] Reading application default configuration from /etc/mha/cluster1.conf..
Sun Mar 29 20:42:03 2020 - [info] Reading server configuration from /etc/mha/cluster1.conf..
Sun Mar 29 20:42:03 2020 - [info] MHA::MasterMonitor version 0.56.
Sun Mar 29 20:42:04 2020 - [info] GTID failover mode = 0
Sun Mar 29 20:42:04 2020 - [info] Dead Servers:
Sun Mar 29 20:42:04 2020 - [info] Alive Servers:
Sun Mar 29 20:42:04 2020 - [info] 192.168.7.101(192.168.7.101:3306)
Sun Mar 29 20:42:04 2020 - [info] 192.168.7.102(192.168.7.102:3306)
Sun Mar 29 20:42:04 2020 - [info] 192.168.7.103(192.168.7.103:3306)
Sun Mar 29 20:42:04 2020 - [info] Alive Slaves:
Sun Mar 29 20:42:04 2020 - [info] 192.168.7.102(192.168.7.102:3306) Version=5.5.64-MariaDB (oldest major version between slaves) log-bin:enabled
Sun Mar 29 20:42:04 2020 - [info] Replicating from 192.168.7.101(192.168.7.101:3306)
Sun Mar 29 20:42:04 2020 - [info] Primary candidate for the new Master (candidate_master is set)
Sun Mar 29 20:42:04 2020 - [info] 192.168.7.103(192.168.7.103:3306) Version=10.3.10-MariaDB-log log-bin:enabled
Sun Mar 29 20:42:04 2020 - [info] Replicating from 192.168.7.101(192.168.7.101:3306)
Sun Mar 29 20:42:04 2020 - [info] Primary candidate for the new Master (candidate_master is set)
Sun Mar 29 20:42:04 2020 - [info] Current Alive Master: 192.168.7.101(192.168.7.101:3306)
Sun Mar 29 20:42:04 2020 - [info] Checking slave configurations..
Sun Mar 29 20:42:04 2020 - [warning] relay_log_purge=0 is not set on slave 192.168.7.102(192.168.7.102:3306).
Sun Mar 29 20:42:04 2020 - [info] Checking replication filtering settings..
Sun Mar 29 20:42:04 2020 - [info] binlog_do_db= , binlog_ignore_db=
Sun Mar 29 20:42:04 2020 - [info] Replication filtering check ok.
Sun Mar 29 20:42:04 2020 - [info] GTID (with auto-pos) is not supported
Sun Mar 29 20:42:04 2020 - [info] Starting SSH connection tests..
Sun Mar 29 20:42:06 2020 - [info] All SSH connection tests passed successfully.
Sun Mar 29 20:42:06 2020 - [info] Checking MHA Node version..
Sun Mar 29 20:42:07 2020 - [info] Version check ok.
Sun Mar 29 20:42:07 2020 - [info] Checking SSH publickey authentication settings on the current master..
Sun Mar 29 20:42:07 2020 - [info] HealthCheck: SSH to 192.168.7.101 is reachable.
Sun Mar 29 20:42:07 2020 - [info] Master MHA Node version is 0.56.
Sun Mar 29 20:42:07 2020 - [info] Checking recovery script configurations on 192.168.7.101(192.168.7.101:3306)..
Sun Mar 29 20:42:07 2020 - [info] Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/data/logbin/ --output_file=/data/mastermha/cluster1//save_binary_logs_test --manager_version=0.56 --start_file=mysql-bin.000001
Sun Mar 29 20:42:07 2020 - [info] Connecting to root@192.168.7.101(192.168.7.101:22)..
Creating /data/mastermha/cluster1 if not exists.. ok.
Checking output directory is accessible or not..
ok.
Binlog found at /data/logbin/, up to mysql-bin.000001
Sun Mar 29 20:42:08 2020 - [info] Binlog setting check done.
Sun Mar 29 20:42:08 2020 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..
Sun Mar 29 20:42:08 2020 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user='mhauser' --slave_host=192.168.7.102 --slave_ip=192.168.7.102 --slave_port=3306 --workdir=/data/mastermha/cluster1/ --target_version=5.5.64-MariaDB --manager_version=0.56 --relay_log_info=/data/mysql/relay-log.info --relay_dir=/data/mysql/ --slave_pass=xxx
Sun Mar 29 20:42:08 2020 - [info] Connecting to root@192.168.7.102(192.168.7.102:22)..
Creating directory /data/mastermha/cluster1/.. done.
Checking slave recovery environment settings..
Opening /data/mysql/relay-log.info ... ok.
Relay log found at /data/mysql, up to centos7-relay-bin.000002
Temporary relay log file is /data/mysql/centos7-relay-bin.000002
Testing mysql connection and privileges.. done.
Testing mysqlbinlog output.. done.
Cleaning up test file(s).. done.
Sun Mar 29 20:42:08 2020 - [info] Executing command : apply_diff_relay_logs --command=test --slave_user='mhauser' --slave_host=192.168.7.103 --slave_ip=192.168.7.103 --slave_port=3306 --workdir=/data/mastermha/cluster1/ --target_version=10.3.10-MariaDB-log --manager_version=0.56 --relay_log_info=/data/mysql/relay-log.info --relay_dir=/data/mysql/ --slave_pass=xxx
Sun Mar 29 20:42:08 2020 - [info] Connecting to root@192.168.7.103(192.168.7.103:22)..
Checking slave recovery environment settings..
Opening /data/mysql/relay-log.info ... ok.
Relay log found at /data/mysql, up to node2-relay-bin.000002
Temporary relay log file is /data/mysql/node2-relay-bin.000002
Testing mysql connection and privileges.. done.
Testing mysqlbinlog output.. done.
Cleaning up test file(s).. done.
Sun Mar 29 20:42:09 2020 - [info] Slaves settings check done.
Sun Mar 29 20:42:09 2020 - [info]
192.168.7.101(192.168.7.101:3306) (current master)
+--192.168.7.102(192.168.7.102:3306)
+--192.168.7.103(192.168.7.103:3306)
Sun Mar 29 20:42:09 2020 - [info] Checking replication health on 192.168.7.102..
Sun Mar 29 20:42:09 2020 - [info] ok.
Sun Mar 29 20:42:09 2020 - [info] Checking replication health on 192.168.7.103..
Sun Mar 29 20:42:09 2020 - [info] ok.
Sun Mar 29 20:42:09 2020 - [warning] master_ip_failover_script is not defined.
Sun Mar 29 20:42:09 2020 - [warning] shutdown_script is not defined.
Sun Mar 29 20:42:09 2020 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK. # 此檢測主要是檢測二進制日志文件是否可以查到。
啟動MHA
（1）開啟mha服務,前台執行監控主從復制節點不安全，我們以后台方式啟動
[root@openstack ~]# nohup masterha_manager -conf=/etc/mha/cluster1.conf &> /data/mastermha/cluster1/manager.log &
（2）檢查此時mha的狀態
[root@centos7~]#tail /data/mastermha/cluster1/manager.log -f 192.168.34.101(192.168.34.101:3306) (current master) +--192.168.34.102(192.168.34.102:3306) +--192.168.34.103(192.168.34.103:3306) Wed Nov 27 11:00:13 2019 - [warning] master_ip_failover_script is not defined. Wed Nov 27 11:00:13 2019 - [warning] shutdown_script is not defined. Wed Nov 27 11:00:13 2019 - [info] Set master ping interval 1 seconds. Wed Nov 27 11:00:13 2019 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes. Wed Nov 27 11:00:13 2019 - [info] Starting ping health check on 192.168.34.101(192.168.34.101:3306).. Wed Nov 27 11:00:13 2019 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond.. 可以看到此時的狀態是成功的，直至mysql不響應
測試MHA 測試故障轉移
（1）在A主機上先創建大文件，並讓其他從服務器進行復制，從服務器不復制的狀態下，當主服務器宕機后，不能推舉一個集群從服務器當新主。
create table testlog (id int auto_increment primary key,name char(10),age int default 20);
delimiter $$
create procedure pro_testlog()
begin
declare i int;
set i = 1;
while i <= 100000
do insert into testlog(name,age) values (concat('wang',i),i);
set i = i +1;
end while;
end$$
delimiter ;
call pro_testlog;
（2）將數據庫停掉，模擬宕機實驗。
# systemctl stop mariadb
（3）在A服務器上查看此時監控狀態，此時當前MHA的監控退出，提升一個從服務器作為主服務器
[root@centos7~]#masterha_manager --conf=/etc/mha/cluster1.conf Wed Nov 27 11:00:07 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. Wed Nov 27 11:00:07 2019 - [info] Reading application default configuration from /etc/mha/cluster1.conf.. Wed Nov 27 11:00:07 2019 - [info] Reading server configuration from /etc/mha/cluster1.conf.. Creating /data/mastermha/cluster1 if not exists.. ok. Checking output directory is accessible or not.. ok. Binlog found at /var/lib/mysql, up to mariadb-bin.000001 Wed Nov 27 11:22:28 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. Wed Nov 27 11:22:28 2019 - [info] Reading application default configuration from /etc/mha/cluster1.conf.. Wed Nov 27 11:22:28 2019 - [info] Reading server configuration from /etc/mha/cluster1.conf..
（4）此時查看排錯日志，可以看到將哪個從服務器作為主服務器
[root@centos7~]#tail /data/mastermha/cluster1/manager.log Started automated(non-interactive) failover. The latest slave 192.168.34.102(192.168.34.102:3306) has all relay logs for recovery. Selected 192.168.34.102(192.168.34.102:3306) as a new master. 可以看到此時的新主服務器是192.168.34.102 192.168.34.102(192.168.34.102:3306): OK: Applying all logs succeeded. 192.168.34.103(192.168.34.103:3306): This host has the latest relay log events. Generating relay diff files from the latest slave succeeded. 192.168.34.103(192.168.34.103:3306): OK: Applying all logs succeeded. Slave started, replicating from 192.168.34.102(192.168.34.102:3306) 192.168.34.102(192.168.34.102:3306): Resetting slave info succeeded. Master failover to 192.168.34.102(192.168.34.102:3306) completed successfully.
查看日志里邊的內容，也可以確認此時的192.168.34.102是新主服務器
[root@centos7~]#cat /data/mastermha/cluster1/manager.log Wed Nov 27 11:22:32 2019 - [info] New master is 192.168.34.102(192.168.34.102:3306)
可以查看此時新的主服務器的read-only已經關閉
MariaDB [(none)]> show variables like 'read_only'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | read_only | OFF | +---------------+-------+
查看D從服務器指向的是新主服務器（192.168.34.102）
MariaDB [(none)]> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.34.102
Master_User: rpluser
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mariadb-bin.000001
Read_Master_Log_Pos: 245
Relay_Log_File: mariadb-relay-bin.000002
Relay_Log_Pos: 531
Relay_Master_Log_File: mariadb-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
注意：如果之前down掉的主服務器恢復，其他從服務器也不會再指向此服務器，只能將恢復的服務器作為從服務器更好，以免在操作過程中出現其他錯誤。
將宕機的主服務器做為從服務器
原有 master 節點故障后，需要重新准備好一個新的 MySQL 節點。基於來自於master 節點的備份恢復數據后，將其配置為新的 master 的從節點即可。注意，新加入的節點如果為新增節點，其 IP 地址要配置為原來 master 節點的 IP ，否則，還需要修改 cluster1.conf 中相應的 ip 地址。隨后再次啟動 manager ，並再次檢測其狀態。
1、在新成立的主服務器上完全備份數據庫
[root@centos7 ~]# mysqldump -A > mysql-all-backup.sql [root@centos7 ~]# scp mysql-all-backup.sql 192.168.7.101: # 將完全備份的數據庫傳到之前宕機的主服務器上
2、在修復的主機上導入備份的數據
[root@centos7 ~]# mysql < mysql-all-backup.sql
修改配置文件，設置為只讀
[mysqld] server-id=4 # 與前面主從服務器的ID不要一樣 read-only skip-name-resolve # 不反向解析為域名 relay_log_purge=0 # 不清除中繼日志 log_bin=/data/logbin/mysql-bin binlog_format=row relay_log=relay-log # 開啟中繼日志
3、在新主上查看二進制日志起始位置
（1）在新主上查看此時的二進制日志的起始位置，將修復的主服務器作為從進行復制
[root@centos7 ~]# mysql Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 81 Server version: 5.5.64-MariaDB MariaDB Server Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> show master logs; +------------------+-----------+ | Log_name | File_size | +------------------+-----------+ | mysql-bin.000001 | 245 | +------------------+-----------+
4、在舊主上開始變為從服務器進行復制
CHANGE MASTER TO # 開始復制
MASTER_HOST='192.168.7.102', #新主的IP地址
MASTER_USER='rpluser',
MASTER_PASSWORD='centos',
MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000001', # 二進制起始名稱
MASTER_LOG_POS=245; # 二進制日志文件起始大小
MariaDB [(none)]> start salve ;
MariaDB [(none)]> show slave status\G; # 查看從服務器的狀態。
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.7.102
Master_User: rpluser
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 245
Relay_Log_File: centos7-relay-bin.000002
Relay_Log_Pos: 544
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
5、在MHA管理主機上驗證從服務器加入后狀態
如果此時修復的主機顯示OK，說明正常。
masterha_check_repl --conf=/etc/mha/cluster1.conf
注意：
(1) 在生產環境中，當你的主節點掛了后，一定要在從節點上做一個備份，拿着備份文件把主節點手動提升為從節點，並指明從哪一個日志文件的位置開始復制
(2) 每一次自動完成轉換后，每一次的(replication health ) 檢測不ok 始終都是啟動不了必須手動修復主節點，除非你改配置文件
(3) 手動修復主節點提升為從節點后，再次運行檢測命令
masterha_check_repl --conf=/etc/mha/cluster1.conf
(4) 再次運行起來就恢復成功了
masterha_manager --conf=/etc/mha/cluster1.conf