使用三台主机：
server1（172.25.92.1）:monitor,master
server7:(172.25.92.7):candicate slave
server8:(172.25.92.8):slave
三台主机安装全新的mysql。

server1上：

安装mha：
yum install -y 
mha4mysql-manager-0.56-0.el6.noarch.rpm
mha4mysql-node-0.56-0.el6.noarch.rpm
perl-Config-Tiny-2.12-7.1.el6.noarch.rpm
perl-Email-Date-Format-1.002-5.el6.noarch.rpm
perl-Log-Dispatch-2.27-1.el6.noarch.rpm
perl-Mail-Sender-0.8.16-3.el6.noarch.rpm
perl-Mail-Sendmail-0.79-12.el6.noarch.rpm
perl-MIME-Lite-3.027-2.el6.noarch.rpm
perl-MIME-Types-1.28-2.el6.noarch.rpm
perl-Parallel-ForkManager-0.7.9-1.el6.noarch.rpm

vim /etc/my.cnf
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
log_bin=binlog

```生成MHA的配置化文件：




<div class="se-preview-section-delimiter"></div>

tar zxf mha4mysql-manager-0.56.tar.gz
cd /mha4mysql-manager-0.56/samples/conf
[root@server1 conf]# ls
app1.cnf masterha_default.cnf
mkdir /usr/local/masterha
cp app1.cnf /usr/local/masterha/
[root@server1 conf]# cat masterha_default.cnf #查看此文件，并将文件内容复制到app1.cnf中

vim /usr/local/masterha/app1.cnf
[server default]
manager_log=/usr/local/masterha/manager.log
manager_workdir=/usr/local/masterha/
master_binlog_dir=/var/lib/mysql
password=Workhard@345
ping_interval=1
remote_workdir=/tmp
repl_password=Workhard@345
repl_user=repl
ssh_user=root
user=root

[serever1]
hostname=172.25.92.1

[server2]
candidate_master=1#置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件的slave
check_repl_delay=0 #认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置 check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了 candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master
hostname=172.25.92.7

[server3]
hostname=172.25.92.8

server1上：




<div class="se-preview-section-delimiter"></div>

mysql -uroot -p
mysql> garant all on . to root@’%’ identified by ‘Workhard@34’;
mysql> grant replication slave on . to repl@’%’ identified by ‘Workhard@345’;
Query OK, 0 rows affected, 1 warning (0.56 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.09 sec)

mysql> create database westos;
Query OK, 1 row affected (0.07 sec)

server7和server8相同操作：




<div class="se-preview-section-delimiter"></div>

yum install -y mha4mysql-node-0.56-0.el6.noarch.rpm

vim /etc/my.cnf
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
log_bin=binlog

mysql -uroot -p

mysql> change master to master_host=’172.25.92.1’,master_user=’ly’,master_password=’Workhard@345’,master_auto_position=1;

mysql> start slave;
Query OK, 0 rows affected (0.05 sec)

mysql> show slave status\G;

出现此种报错！！

Last_SQL_Error: Could not execute Write_rows event on table mysql.plugin; Duplicate entry ‘validate_password’ for key ‘PRIMARY’, Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event’s master log binlog.000002, end_log_pos 398

解决：

mysql> start slave;
Query OK, 0 rows affected (0.04 sec)

配置monitor和节点之间可以ssh免密登陆：




<div class="se-preview-section-delimiter"></div>

ssh-keygen -t rsa #生成密钥，一路回车

注意，本次实验server1既是monitor，也是初始master，也属于高可用的一个节点，所以发送密钥的时候也需要给自己发送密钥，否则会出错。

ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]

在server7和server8上也同样生成密钥并互相发送，即可以实现彼此间ssh无密连接





<div class="se-preview-section-delimiter"></div>

masterha_check_ssh –conf=/usr/local/masterha/app1.cnf

masterha_check_repl –conf=/usr/local/masterha/app1.cnf
两个检查都没有报错后，开始测试。

测试：




<div class="se-preview-section-delimiter"></div>

首先解决真正slave（server8）的一个问题：

mysql> use mysql;
mysql> select * from plugin;
+——————-+———————-+
| name | dl |
+——————-+———————-+
| validate_password | validate_password.so |
+——————-+———————-+

mysql> delete from plugin;
Query OK, 1 row affected (0.10 sec)
若不删除“validate_password“这个插件，后面测试时，挂掉原本的master（server1），虽然备用 master（server7）会升级为master，但是slave（server8）却不会指向新的master（server7），解决这个问题之后就可以了。

server1上：
nohup masterha_manager –conf=/usr/local/masterha/app1.cnf –remove_dead_master_conf –ignore_last_failover &
pkill -9 mysqld
cat manager.log
—– Failover Report —–

app1: MySQL Master failover 172.25.92.1(172.25.92.1:3306) to 172.25.92.7(172.25.92.7:3306) succeeded

Master 172.25.92.1(172.25.92.1:3306) is down!

Check MHA Manager logs at server1:/usr/local/masterha/manager.log for details.

Started automated(non-interactive) failover.
Selected 172.25.92.7(172.25.92.7:3306) as a new master.
172.25.92.7(172.25.92.7:3306): OK: Applying all logs succeeded.
172.25.92.8(172.25.92.8:3306): OK: Slave started, replicating from 172.25.92.7(172.25.92.7:3306)
172.25.92.7(172.25.92.7:3306): Resetting slave info succeeded.
Master failover to 172.25.92.7(172.25.92.7:3306) completed successfully.
看到日志中的这样的内容即说明master的切换以及slave的切换已经正常。

在server8上：
mysql> start slave;
Query OK, 0 rows affected (0.03 sec)

mysql> show slave status\G;
***************** 1. row *****************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.25.92.7
Master_User: repl
说明server8（slave）指向了新的master（server7）。

到此可以看见MHA成功完成了master的切换，实现了高可用。

MHA配置mysql高可用

出现此种报错！！

解决：

注意，本次实验server1既是monitor，也是初始master，也属于高可用的一个节点，所以发送密钥的时候也需要给自己发送密钥，否则会出错。

在server7和server8上也同样生成密钥并互相发送，即可以实现彼此间ssh无密连接

到此可以看见MHA成功完成了master的切换，实现了高可用。

猜你喜欢