前文：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系统的可用性的思路，也许能蹭到一点“集群”的边？（倒下了一个主库，还有千千万个主库
）
--------------------------------------------------------------------------------------赶-------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------正文------------------------------------------------------------------------------------
之前有写了一点验证多源复制的东西，下半篇写点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系统的可用性的思路，也许能蹭到一点“集群”的边？（倒下了一个主库，还有千千万个主库
）--------------------------------------------------------------------------------------赶-------------------------------------------------------------------------------------
