这是有生之年系列的填坑_(:з」∠)_
Nginx的TCP反向代理的联动帖：http://blog.itpub.net/29510932/viewspace-1842929/
-------------------------------------------------------------------------------------正文------------------------------------------------------------------------------------
背景：懒癌晚期，整理好发上来；
环境：MySQL-5.7.9 x 4，Nging-1.9.7 x 1，五台虚拟机
总体思路：
四个MySQL实例组成双主双从的多源复制结构，Nginx放在前端，对应用层屏蔽DB层细节

配置简记：
MySQL的双主配置和普通的双主配置没什么区别，并且在这次搭建中打开了GTID；
从库开启多源复制需要设置

--master-info-repository=TABLE --relay-log-info-repository=TABLE

从库开启多源复制用的channel，注意一下语法就好；

Nginx的TCP转发功能参考另外一篇博客，这次试验的简单配置如截图

验证：
先是看看复制的情况，建立一个测试表

随便插入几条数据，看看从库的status

可以看到从库的status里面有两个主库的GTID信息
提问：为什么指向67的channel会有两个主库的GTID信息？
解惑：看一下67的relay-log的信息

看到relay-log同时包含了两个主库的事务信息，原因在于两个主库同时开启了log-slave-updates，所以在relay-log里面包含了两个主库的事务；
追问：那么channel_67的relay-log包含两个主库的事务，是不是这个67主库的channel在复现事务时，过滤掉了65主库的日志呢？
解惑：关掉channel_67的SQL_THREAD之后，在两个主库上分别执行一下语句，再看看从库的status

发现停掉channel_67的SQL_THREAD之后，67的事务依然被更新了，从对比上来看，是channel_65的SQL_THREAD更新的，
那么同时停掉65和67的SQL_THREAD，看看效果；

基本可以得出一个结论：channel的SQL_THREAD并没有过滤掉非master的日志，而是忠实的复现了每一个记录在relay-log里面的事务；
追问：既然两个channel都会执行relay-log的所有事务，那么为什么没有报错？
解惑/推测：SQL_THREAD在复现relay-log的时候，会检查一下已经执行过的事务，如果是重复的，则会跳过；

提问：在双主的MySQL上关闭log-slave-updates，从库的同步是否会有问题/不同？
解惑：动手测试，关闭slave-log-update之后再观察从库的relay-log；

可以看到relay-log里面没有主库65的事务信息了，那么再看一下slave status

可以发现，各个channel不再收到另外的主库的日志，不过已执行事务的GTID信息还是有同步的；
得出的结论：没有出现问题，且各个channel都单独处理各自主库的事务信息，为了数据流向的清晰和明确，在双主配置中关闭slave-log-update比较好；

延伸提问：假设channel_67的SQL_THREAD停止一段时间，使得67的insert语句没有复现（假设插入值为18），而65的insert全部复现了（插入值为19和21），
从库上的AUTO_INCREMENT计数器是否会出错？
准备完环境以后，处于缺少18的状态，效果如下图

relay-log的信息中包含了缺少的事务；

从结果来看，一切ok

试验还在进行中， Nginx的部分留给下半部分，先欠着..._(:з」∠)_...
-------------------------------------------------------------------------------------待续------------------------------------------------------------------------------------
PS:在5.6.x版本，开启GTID必须要开启log-slave-updates，通过查阅资料，推断为auto_position所需要，所以需要开启这个选项，不过在5.7.9已经不是必要条件了。