有的时候博客内容会有变动,首发博客是最新的,其他博客地址可能会未同步,认准https://blog.zysicyj.top
MHA架构介绍
MHA是Master High Availability的缩写,它是目前MySQL高可用方面的一个相对成熟的解决方案,其核心是使用perl语言编写的一组脚本,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在0~ 30秒之内自动完成数据库的故障切换操作,并且能在最大程度上保证数据的一致性,以达到真正意义上的高可用。
基于MHA的架构不像MMM那样需要搭建主主复制,只需要搭建基本的主从复制架构即可。因为MHA在主库挂掉时,是在多个从库中选取出一个从库作为新的主库。MHA集群中的各节点彼此之间均需要基于ssh
互信通信,以实现远程控制及数据管理功能。
「MHA提供了什么功能:」
- 可以监控Master节点是否可用
- 当Master不可用时,能在多个Slave中选举出新的Master
- 提供了主从切换和故障转移功能,MHA会尝试在宕机的Master上保存binlog,在最大程度上保证事务不丢失。但如果是Master所在的服务器已经无法访问,或硬件层面出现了问题,则无法成功保存binlog
- MHA可以与半同步复制结合,避免从库之间出现数据不一致的情况
- 支持MySQL基于GTID和基于日志点的两种复制方式
「MHA故障转移过程:」
- 尝试使用
ssh
登录到宕机崩溃的Master节点上保存二进制日志事件(binlog events); - 从多个Slave中识别含有最新更新的Slave,将其作为备选的Master;
- 然后基于该Slave同步差异的中继日志(relaylog)到其他的Slave上;
- 接着同步从原Master上保存的二进制日志事件(binlog events);
- 将备选的Master提升为新的Master;
- 使其他的Slave连接新的Master进行复制;
- 在新的Master启动vip地址,保证前端请求可以发送到新的Master。
「MHA的架构图如下:」
动手搭建MHA架构
「本文中所使用的机器说明:」
名称 | IP | 角色 |
master | 192.168.190.151 | 主库 |
slave-01 | 192.168.190.152 | 从库 |
slave-02 | 192.168.190.154 | 从库 |
manager | 192.168.190.153 | 集群管理节点(MHA) |
「环境版本说明:」
- 操作系统版本:CentOS 7
- MySQL版本:8.0.19
- MHA版本:0.58
「另外的说明:」
- 会来了解MMM架构的小伙伴们想必都已经掌握了MySQL的安装方式,而且介绍 MySQL的安装 也有很多文章,所以本文为了减少不必要的篇幅就不演示MySQL的安装了,文中所用到的机器都已经提前安装好了MySQL。
配置主从节点的配置文件
1、在所有主从节点上使用如下语句创建用于主从复制的MySQL用户,因为每个从库都有可能会被选举为主库,所以都需要拥有用于复制的用户:
create user 'repl'@'%' identified with mysql_native_password by 'Abc_123456'; grant replication slave on *.* to 'repl'@'%'; flush privileges;
2、然后修改master
节点上的MySQL配置文件:
[root@master ~]# vim /etc/my.cnf [mysqld] # 设置当前节点的id server_id=101 # 开启binlog,并指定binlog文件的名称 log_bin=mysql_bin # 开启relay_log,并指定relay_log文件的名称 relay_log=relay_bin # 将relaylog的同步内容记录到binlog中 log_slave_updates=on # 开启GTID复制模式 gtid_mode=ON enforce_gtid_consistency=1
3、在slave-01
的配置文件中也是添加一样配置,只不过server_id
不一样:
[root@slave-01 ~]# vim /etc/my.cnf [mysqld] server_id=102 log_bin=mysql_bin relay_log=relay_bin log_slave_updates=on gtid_mode=ON enforce_gtid_consistency=1
4、接着是配置slave-02
:
[root@slave-02 ~]# vim /etc/my.cnf [mysqld] server_id=103 log_bin=mysql_bin relay_log=relay_bin log_slave_updates=on gtid_mode=ON enforce_gtid_consistency=1
完成以上配置文件的修改后,分别重启这三个节点上的MySQL服务:
[root@master ~]# systemctl restart mysqld [root@slave-01 ~]# systemctl restart mysqld [root@slave-02 ~]# systemctl restart mysqld
配置slave-01
对master
的主从关系
mysql> stop slave; -- 停止主从同步 mysql> change master to master_host='192.168.190.151', master_port=3306, master_user='repl', master_password='Abc_123456', master_auto_position=1; -- 配置master节点的连接信息 mysql> start slave; -- 启动主从同 ----------------------------------- ©著作权归作者所有:来自51CTO博客作者ZeroOne01的原创作品,请联系作者获取转载授权,否则将追究法律责任 基于MHA搭建MySQL Replication集群高可用架构 https://blog.51cto.com/zero01/2468767
进入slave-01
节点的MySQL命令行终端,分别执行如下语句来配置主从复制链路:
配置完主从复制链路后,使用show slave status\G;
语句查看主从同步状态,Slave_IO_Running
和Slave_SQL_Running
的值均为Yes
才能表示主从同步状态是正常的:
配置slave-02
对master
的主从关系
mysql> stop slave; -- 停止主从同步 mysql> change master to master_host='192.168.190.151', master_port=3306, master_user='repl', master_password='Abc_123456', master_auto_position=1; -- 配置master节点的连接信息 mysql> start slave; -- 启动主从同步
同样的步骤,进入slave-02
节点的MySQL命令行终端,分别执行如下语句来配置主从复制链路:
配置完主从复制链路后,使用show slave status\G;
语句查看主从同步状态,Slave_IO_Running
和Slave_SQL_Running
的值均为Yes
才能表示主从同步状态是正常的: