MySql的高可用之路--7.MHA架构介绍及实现及优缺点及maxScale的部署实现最终的高可用架构

MHA架构：

MHA（Master High Availability）

 MHA提供的功能：

监控主数据库服务器是否可用

当主DB不可用时，从多个从服务器中选举出新的主数据库服务器

提供了主从切换和故障转移功能

尝试从出故障的主数据库保存二进制日志

从多个备选从服务器中选举出新的备选主服务器（可人为的设置一些服务器不参与选举）

 

MHA架构

 该架构采用的是GTID的复制模式

 配置步骤：

 

 实现架构模型：

 数据库操作：

第一步建立GTID（请看这篇博客https://blog.csdn.net/qq_37909508/article/details/94905661）

第二步建立复制的用户repl：

 

 然后就是进行数据库数据统一，具体操作请看https://blog.csdn.net/qq_37909508/article/details/94905661。

服务器192.168.3.101

启动复制链路

 服务器192.168.3.102

 

服务器192.168.3.100

 生成ssh密钥：

 

 

 

 

注意：配置好ssh后可以在一台服务器上切换不同的服务器，实现免认证登录

服务器192.168.3.101、192.168.3.102

 生成ssh密钥：

 同理

服务器192.168.3.102

三台服务器都执行以下两条命令： 

 

 

 服务器192.168.3.102（安装监控软件包）

 

 修改配置文件：

 服务器192.168.3.102：

红框请参考 192.168.3.100（主服务器）：

 该脚本根据自己的服务器进行手动编写

 

 

查看脚本（该脚本在官网下的） 

主要是修改虚拟ip

  服务器192.168.3.100：

创建一个具有所有权限的用户

 

   服务器192.168.3.101：

检测MHA是否已经安装完毕

   服务器192.168.3.102：

 

启动MHA：

 

服务器192.168.3.100：

配置虚拟ip：

 

 停止服务器

 查看服务器192.168.3.101，我们可以看到它自动继承了192.168.3.100的虚拟ip成为master

 总结：

优点：

同样是由Perl语言开发的开源工具

可以支持基于GTID的复制模式

MHA在进行故障转移时更不易产生数据丢失

同一个监控节点可以监控多个集群

缺点：

需要编写脚本或利用第三方工具实现Vip的配置

MHA启动后只会对主数据库进行监控

需要基于ssh免认证配置，存在一定的安全隐患

没有提供从服务器的读负载均衡功能

 

为什么要进行读写分离？

只能在主上进行写操做，读操作主从都可以进行。

 程序实现的读写分离

优点：

由开发人员控制什么样查询在从库中执行，因此比较灵活

由程序直接连接数据库，所以性能损耗比较少

缺点：增加了开发的工作量，使得程序代码更加复杂，认为控制，容易出错。

 

中间件实现读写分离：

优点：

由中间件根据查询语法分析，自动完成读写分离

对程序透明，对于已有程序不用做任何调整

缺点：

由于增加了中间层，查询效率有损耗

对于延迟敏感业务无法自动在主库执行

 

中间件（maxScale）

 

数据库部署： 

从服务器：192.168.3.102

 

 

 

在主服务器上（192.168.3.101）

 

 

 

 

从服务器：192.168.3.102

 

 

 

 

 

我们采用读写分离，所以删除掉或者注解所有的[Read-Only Service] 

 

 启动maxscale

 

最终的高可用架构：