MySQL5.7中多源复制及Nginx中间件是怎么样的

共计 2285 个字符，预计需要花费 6 分钟才能阅读完成。

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

之前有写了一点验证多源复制的东西，下半篇写点 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 中间件是怎么样的，丸趣 TV 小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注丸趣 TV 行业资讯频道。