love wife & love life —Roger的Oracle&MySQL技术博客

Phone:18180207355 提供专业Oracle&MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

基于MySQL Group Replication+Consul的高可用架构浅析和测试

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger的Oracle&MySQL技术博客

本文链接地址: 基于MySQL Group Replication+Consul的高可用架构浅析和测试

MySQL Group Replication已经发布2年了;虽然目前来讲还不够成熟和稳定,然而从技术角度来讲,我认为应该是未来的趋势;针对跨IDC容灾的情况,MGR可以很好的应对;相比而言,PXC就逊色的多了。同时PXC性能相比MGR也要差一些,本人亲测过。

MGR主要架构支持多主和单主模式;所谓多主,也就是指每个节点均可读写,不难理解,多主有点类似MySQL 双主。对于MySQL数据库而言,节点之间的数据同步复制其实是逻辑复制,因此多写必须面临的一个问题就是:数据冲突解决。 同时根据我们现在经验来看,多主的问题还是比较多,因此我们都建议客户以单主为主,相对靠谱一些。

那么使用单主,就面临一个问题。解决了数据一致性,那么业务连续性呢?比如比如现在主节点是Node1;Node2、3是Read节点(slave节点);所以写操作都在Node1进行,如果Node1 出现故障,数据库主节点切换到Node2后,怎么办? 此时对于业务来讲,怎么处理?难道还要去修改IP地址吗?

当然,也有人仍然在使用MGR+Keepalive的方式,通过Keepalive来虚拟出一个VIP地址提供给业务使用;当出现节点切换后,VIP会进行飘逸。对于Keepalive来说,是一个比较古老的软件了,本身也有不少问题。因此现在大家更倾向于使用服务发现的Consul来代替了。

实际上不仅仅是MGR这种架构,目前用的最多的MHA架构,也有不少用人在试用MHA+consul.

对于Consul的一些基本知识和原理,这里我就不做过多解释了。如下是我的一个简单的测试,供参考。

1.每个节点都创建对应目录

2. consul解压即可用,无需按照,步骤略
3. consul server端json配置如下:

 

4. mgr 每个节点都配置如下:

 

5. mgr每个节点部署上述2个check mysql状态的脚本

这里我参考了互联网上的一些脚本,大家可以进行随意更改;

 

6. 启动consul server

如果是生产环境,建议至少3个节点的consul集群,这里模拟暂且用一个节点把。
[root@killdb ~]# /etc/consul.d/consul agent -config-dir=/etc/consul.d -enable-script-checks > /opt/consul/consul.log &
[1] 19187
[root@killdb ~]#

7. 启动mgr每个节点的consul angnt

正常启动后会看到如下的类似的信息:

 

8. 当所有节点都启动后后,可以检查整个consul的注册信息,如下:

9.进行验证

–检查域名状态

可以看到,目前写节点在154;读节点在132,133上。接下来我们停掉154,看看写服务是否会转移到其他节点:

—stop mgr node1

—再次检查服务

我们可以看到,写节点已经发生了改变,成功解析到其他节点了。我们不难看出,如果能结合dns,业务通过域名的方式来访问mgr集群,几乎可以完美解决业务连续性问题。

 

Leave a Reply

You must be logged in to post a comment.