ITPub博客

首页 > 数据库 > MySQL > 有生之年系列----MySQL5.7之多源复制&Nginx中间件(下)

有生之年系列----MySQL5.7之多源复制&Nginx中间件(下)

原创 MySQL 作者:wangwenan6 时间:2016-01-15 13:52:06 0 删除 编辑
前文:http://blog.itpub.net/29510932/viewspace-1974937/
-------------------------------------------------------------------------------------正文------------------------------------------------------------------------------------
之前有写了一点验证多源复制的东西,下半篇写点Nginx的东西;
背景:赶
环境:MySQL-5.7.9 x 4,Nging-1.9.7 x 1,五台虚拟机
总体思路:
四个MySQL实例组成双主双从的多源复制结构,Nginx放在前端,对应用层屏蔽DB层细节,同时由Nginx来完成负载均衡/读写分离和“伪HA”



使用的Nginx配置


简单试一下功能,连接的时候指定host,使用TCP的方式去连接61上面的Nginx,可以看到成功的登录了MySQL,

在两台主库上面找一找,发现这个链接发送到了67上面

既然连进来了,通过一个纯粹做请求转发的Nginx之后, 普通的操作应该是没什么问题,试验略过;
连接write的upstream和连接read的upstream没什么本质上的区别,试验略过;
通过Nginx做中间件来实现读写分离的话,只需要在URL中连接不同的端口就可以了,试验略过;
多个连接同时连到这个Nginx的写库(主库),可以看到连接被分到了不同的服务器上,


提问:如果有session连接在某一台主库上,然后那台主库出问题挂掉了,客户端的状态?
解惑:kill主库的mysql进程,模拟down机;

有两个客户端出现了重连的提示,另外两个一切正常;


存活的主库状态,可以看到请求都转到了存活的主库上;

结论:对客户端来说,虽然保持连接的那个主库挂掉了,但是在前端来看,就像是连接超时被断开了一样,并不会感受到端口为13579的主库已经挂掉了;
读库同理,验证略过;

额外发现的断开连接现象在Nginx设置的timeout也会有一定的影响,接上图的状态,一直不去操作这几个客户端,在超时时间之后,会在MySQL端输出如下错误日志;

重新操作一下几个客户端,会看到所有的连接其实都断开了;


解惑:连接建立以后,空闲的时间超过Nginx(proxy_timeout)和MySQL的设置中比较短的那个之后,就会自行断开;
结论:和Nginx+Tomcat的反向代理一样,超时时间的设置也要注意一下;

提问:某一个库(以上面挂掉的那个主库为例)挂掉之后,fail_timeout的时间之后这个主库恢复了,会不会自动加回列表?
解惑:为了方便测试,改一下fail_timeout的时间,然后关掉主库67,重启Nginx以后,再启动67,等待一段时间,


间隔的时间稍微久了点, 不过重新开启连接以后,可以看到有连接重新进来了,fail_timeout的设置还是ok的,在超过这个时间段以后,Nginx会去检测后端服务器的状况,把启动起来的服务器重新加进来;
结论:Nginx作为一个中间件,可以做到“自动移除挂掉的机器/自动加回恢复的机器”;
PS:如果是启动了,正在恢复数据的话,最好还是把出问题的库从upstream移除比较好;

提问:在upstream的配置中,写的是通过hash的方式去转发连接,那么是否可以像Nginx+Tomcat的反向代理一样,采用权重等其他的方式来转发连接
解惑:试一下;为了方便看效果,简单改一下Nginx的配置

连接四个客户端以后,看看两个主库的连接;

可以看到连接都转发到了65主库上面去了;
结论:权重的配置是可以生效的,这样的话,可以根据实际要求,用不同配置的MySQL实例来搭建这种类似的架构;

提问:既然使用Nginx作为中间件,可以做到“自动移除挂掉的机器/自动加回恢复的机器”,也对前端屏蔽了后端DB架构上的细节,不会发现某个DB不可用,为什么要描述成“伪HA”?
解惑:个人观点,确实,通过Nginx的中间件,去访问后端的MySQL,确实是具备了HA的样子;某个MySQL实例挂掉了,不会导致整个DB系统无法运行;失败的MySQL实例恢复以后能自动加入;
但是用Nginx做中间件有两个很明显的短板:Nginx的端口是作为对外的唯一出口暴露给应用层的, Nginx本身的HA需要其他方式去保障(不像VIP,就算admin或者worker挂掉了,也不影响数据库访问
);
另一个更重要的缺点,就是两个主库全部挂了以后,Nginx本身不能新选举一个从库作为新的master来重新搭建新的主从架构;
这两个短板,尤其是第二个短板,如果是很严格的HA环境和要求,这第二个短板是非常致命的,想要弥补这个,自行开发一套/修改开源工具也许能做到;

追问:存在这么明显/严重的短板,多源复制+Nginx的中间件,到底好用么?
解惑:个人观点,还不错;
1.Nginx的单出口问题,完全可以通过启动多个实例(分开的指向同一套后端数据库来提高可用性(keepalived也可以)
2.不能选举新Master的问题,在5.7的多源复制功能中,可以横向增加Master的数量,完全靠更多的实例来提高可用性
这么做,可能会使N主之间的数据一致性受到影响,不过只需要在读库的upstream里面剔除掉这些主库就行了
3.完全用提高实例数的方式去提高可用性,个别的实例(不管主或者从)挂掉了,基本上不会影响到业务,所表现出来的,只是“某些事务异常中断了”,需要应用层重试,
而不是mha那样,主库挂了需要一段时间来重建主从结构
-------------------------------------------------------------------------------------尾声------------------------------------------------------------------------------------
总算是写完了,写之前很痛苦,觉得好多东西要整理;写的时候也很痛苦,真正想表达出来的一些时候,觉得好多东西要考证;写完以后也很痛苦,觉得有更多的东西可以尝试;_(:з」∠)_
不管怎么样,这种多源复制+Nginx中间件的做法,走的是一种用数量来提高整个DB系统的可用性的思路,也许能蹭到一点“集群”的边?(倒下了一个主库,还有千千万个主库
--------------------------------------------------------------------------------------赶-------------------------------------------------------------------------------------

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29510932/viewspace-1977034/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2014-02-28

  • 博文量
    102
  • 访问量
    1351262