MHA配置mysql高可用

最新推荐文章于 2024-04-24 17:12:48 发布

??ff

最新推荐文章于 2024-04-24 17:12:48 发布

阅读量860

点赞数

分类专栏：企业运维文章标签： MHA

本文链接：https://blog.csdn.net/sinat_36888624/article/details/79217051

版权

企业运维专栏收录该内容

27 篇文章 0 订阅

订阅专栏

使用三台主机：
server1（172.25.92.1）:monitor,master
server7:(172.25.92.7):candicate slave
server8:(172.25.92.8):slave
三台主机安装全新的mysql。
原理简介：MHA（Master High Availability）是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在较大程度上保证数据的一致性，以达到真正意义上的高可用。
MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，较大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了的二进制日志，MHA可以将的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性

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 root@172.25.92.1
ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.25.92.7
ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.25.92.8

在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的切换，实现了高可用。

“`

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> use mysql;
mysql> select * from plugin;
+-------------------+----------------------+
| name              | dl                   |
+-------------------+----------------------+
| validate_password | validate_password.so |
+-------------------+----------------------+
mysql> delete from plugin;
mysql> delete  from plugin;
Query OK, 1 row affected (0.10 sec)

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

mysql> show slave status\G;
此时正常！

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| westos             |
+--------------------+

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

masterha_check_ssh --conf=/usr/local/masterha/app1.cnf 
All SSH connection tests passed successfully.

masterha_check_repl --conf=/usr/local/masterha/app1.cnf
MySQL Replication Health is OK.

两个检查都没有报错后，开始测试。

测试：

首先解决真正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的切换已经正常。

在server7上：
mysql> show master status;
+---------------+----------+--------------+------------------+-------------------------------------------------------------------------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                                                                   |
+---------------+----------+--------------+------------------+-------------------------------------------------------------------------------------+
| binlog.000011 |      234 |              |                  | b7b3a550-064a-11e8-afa8-525400b9c5e8:1-25,
c1b5f01d-064a-11e8-aefc-525400f92035:1-4 |
+---------------+----------+--------------+------------------+-------------------------------------------------------------------------------------+
可以看见server7成为新的master。

在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的切换，实现了高可用。

注意：要在做之前删除密码检测插件validate_password

如果不删除，对后面的高可用master切换会有影响
vim /etc/init.d/mysqld
这里写图片描述
三台主机都不需要安装密码插件

??ff

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
MHA配置mysql高可用

使用三台主机： server1（172.25.92.1）:monitor,master server7:(172.25.92.7):candicate slave server8:(172.25.92.8):slave 三台主机安装全新的mysql。原理简介：MHA（Master High Availability）是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件
复制链接

扫一扫