有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)
这是有生之年系列的填坑_(:з」∠)_
Nginx的TCP反向代理的联动帖:http://blog.itpub.net/29510932/viewspace-1842929/
-------------------------------------------------------------------------------------正文------------------------------------------------------------------------------------
背景:懒癌晚期,整理好发上来;
环境:MySQL-5.7.9x 4,Nging-1.9.7x 1,五台虚拟机
总体思路:
四个MySQL实例组成双主双从的多源复制结构,Nginx放在前端,对应用层屏蔽DB层细节
配置简记:
MySQL的双主配置和普通的双主配置没什么区别,并且在这次搭建中打开了GTID;
从库开启多源复制需要设置
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已经不是必要条件了。
当前标题:有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)
网站路径:http://myzitong.com/article/gdpicj.html
Nginx的TCP反向代理的联动帖:http://blog.itpub.net/29510932/viewspace-1842929/
-------------------------------------------------------------------------------------正文------------------------------------------------------------------------------------
背景:懒癌晚期,整理好发上来;
环境:MySQL-5.7.9x 4,Nging-1.9.7x 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已经不是必要条件了。
当前标题:有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)
网站路径:http://myzitong.com/article/gdpicj.html