本篇文章给大家分享的是有关MySQL5.7中多源复制及Nginx中间件是怎么样的，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。

成都创新互联公司长期为近千家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为巩留企业提供专业的网站设计制作、成都网站制作，巩留网站改版等技术服务。拥有10多年丰富建站经验和众多成功案例,为您定制开发。

之前有写了一点验证多源复制的东西，下半篇写点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那样，主库挂了需要一段时间来重建主从结构；

以上就是MySQL5.7中多源复制及Nginx中间件是怎么样的，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联-成都网站建设公司行业资讯频道。

分享文章：MySQL5.7中多源复制及Nginx中间件是怎么样的-创新互联
文章起源：http://kswjz.com/article/cshhpp.html