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已经不是必要条件了。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。