这是有生之年系列的填坑_(:з」∠)_
Nginx的TCP反向代理的联动帖:http://blog.itpub.net/29510932/viewspace-1842929/
-------------------------------------------------------------------------------------正文------------------------------------------------------------------------------------
背景:懒癌晚期,整理好发上来;
环境:
MySQL-5.7.9x 4,
Nging-1.9.7x 1,五台虚拟机
总体思路:
四个MySQL实例组成双主双从的多源复制结构,Nginx放在前端,对应用层屏蔽DB层细节
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24784.jpg)
配置简记:
MySQL的双主配置和普通的双主配置没什么区别,
并且在这次搭建中打开了GTID;
从库开启多源复制需要设置
--master-info-repository=TABLE --relay-log-info-repository=TABLE
从库开启多源复制用的channel,注意一下语法就好;
Nginx的TCP转发功能参考另外一篇博客,这次试验的简单配置如截图
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24785.jpg)
验证:
先是看看复制的情况,建立一个测试表
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24787.jpg)
随便插入几条数据,看看从库的status
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24788.jpg)
可以看到从库的status里面有两个主库的GTID信息
提问:为什么指向67的channel会有两个主库的GTID信息?
解惑:看一下67的relay-log的信息
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24789.jpg)
看到relay-log同时包含了两个主库的事务信息,
原因在于两个主库同时开启了log-slave-updates,所以在relay-log里面包含了两个主库的事务;
追问:那么channel_67的relay-log包含两个主库的事务,是不是这个67主库的channel在复现事务时,
过滤掉了65主库的日志呢?
解惑:关掉channel_67的SQL_THREAD之后,在两个主库上分别执行一下语句,再看看从库的status
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24790.jpg)
发现停掉channel_67的SQL_THREAD之后,67的事务依然被更新了,从对比上来看,是channel_65的SQL_THREAD更新的,那么同时停掉65和67的SQL_THREAD,看看效果;
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24792.jpg)
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24793.jpg)
基本可以得出一个结论:channel的SQL_THREAD并没有过滤掉非master的日志,而是忠实的复现了每一个记录在relay-log里面的事务;
追问:既然两个channel都会执行relay-log的所有事务,那么为什么没有报错?
解惑/
推测:SQL_THREAD在复现relay-log的时候,会检查一下已经执行过的事务,如果是重复的,则会跳过;
提问:在双主的MySQL上关闭log-slave-updates,从库的同步是否会有问题/不同?
解惑:动手测试,关闭slave-log-update之后再观察从库的relay-log;
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24794.jpg)
可以看到relay-log里面没有主库65的事务信息了,那么再看一下slave status
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24795.jpg)
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24796.jpg)
可以发现,各个channel不再收到另外的主库的日志,不过已执行事务的GTID信息还是有同步的;
得出的结论:
没有出现问题,且各个channel都单独处理各自主库的事务信息,为了数据流向的清晰和明确,在双主配置中关闭slave-log-update比较好;延伸提问:假设channel_67的SQL_THREAD停止一段时间,使得67的insert语句没有复现(假设插入值为18),而65的insert全部复现了(插入值为19和21),
从库上的AUTO_INCREMENT计数器是否会出错?
准备完环境以后,处于缺少18的状态,效果如下图
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24797.jpg)
relay-log的信息中包含了缺少的事务;
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24798.jpg)
从结果来看,一切ok
![有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)](/upload/otherpic50/24799.jpg)
试验还在进行中, Nginx的部分留给下半部分,先欠着..._(:з」∠)_...
-------------------------------------------------------------------------------------待续------------------------------------------------------------------------------------
PS
:在5.6.x版本,开启GTID必须要开启log-slave-updates,通过查阅资料,推断为auto_position所需要,所以需要开启这个选项,不过在5.7.9已经不是必要条件了。
本文名称:有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)
本文链接:
http://cdkjz.cn/article/gdpicj.html