mysql mmm读写分离_MySQL-MMM的读写分离及高可用

用途

mmm是基于信息探测方式进行mysql主从复制架构的监测与故障转移

mmm可以做到负载均衡,100%的数据可用性

mmm所涉及的检查项   服务器可达性,服务可达性,复制线程可控性

如图: 当 master1在宕机时, mmm可以将之前分摊的流量进行转移,甚至于将从服务器提升为主

延续双主模型.mmm-agent端状态一览

online 节点可用

replication_delay 复制延迟或无法进行(检查req_backlog文件)

replication_fail 复制失败

awating_recovery 等待恢复

hard_offline  主机离线

admin_offline  主控端离线

unknown  未知错误规划如下

172.16.43.200  主控机器负责监测与资源的管理

172.16.43.1  vip(172.16.43.11)  master1 主主复制第一台(可读写)

172.16.43.2  vip(172.16.43.12)  master2 主主复制第二台(只读)

172.16.43.3  vip(172.16.43.13)  slave   主从方式复制 1 , 2 的信息(只读)

实验过程如下

主控安装安装: ansible, mysql客户端, mysql-mmm

集群节点安装如下: mariadb, mysql-agent

i)  主机互信,ansible部署的关键

ii) 安装 mariadb, mysql-agent安装与配置

不熟yaml的童鞋可以 yaml.org

iii) 实现双主复制与主从复制

iv) 启动测试

测试1

如图: 让 master2 离线,读写均不受影响 (抱歉此图没有截图下来,,但最后结果图中有所显示  : )

测试2:

再来一次测试,将master1主节点下线,我们观察一下情况, 在图中我们可以看到读写资源已经迁移到了master2节点

总结

经过测试可以看出MMM在mysql的高可用表现非常良好,无论是只剩一主还是一主一从,数据的同步确实比较及时准确

生产环境还需观察...

本文转自My_King1 51CTO博客，原文链接：http://blog.51cto.com/apprentice/1399141，如需转载请自行联系原作者