有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)
发表于:2025-11-07 作者:千家信息网编辑
千家信息网最后更新 2025年11月07日,这是有生之年系列的填坑_(:з」∠)_Nginx的TCP反向代理的联动帖:http://blog.itpub.net/29510932/viewspace-1842929/--------------
千家信息网最后更新 2025年11月07日有生之年系列----MySQL5.7之多源复制&Nginx中间件(上)这是有生之年系列的填坑_(:з」∠)_
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;
从库开启多源复制需要设置
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已经不是必要条件了。
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已经不是必要条件了。
事务
两个
信息
配置
多源
同时
日志
效果
数据
环境
结论
语句
问题
同步
更新
测试
试验
有生之年
之年
不同
数据库的安全要保护哪些东西
数据库安全各自的含义是什么
生产安全数据库录入
数据库的安全性及管理
数据库安全策略包含哪些
海淀数据库安全审计系统
建立农村房屋安全信息数据库
易用的数据库客户端支持安全管理
连接数据库失败ssl安全错误
数据库的锁怎样保障安全
服务器管理平台怎么样
奇安信网络安全基础
数据库中如何添加约束
数据库aoe是什么意思
遵守网络安全法征文1000
网络安全模式没有蓝屏
朱批奏折数据库
图书馆数据库入库库存处理
上海丑牛网络技术有限公司
有效网络技术
弹性云服务器
数据库只在参数变化时做记录
关于网络技术的论文课件
网络技术侦察大队
实现网络安全目标需要
公司网络安全注意事项简短
游戏服务器多进程代码启动顺序
支微网络技术有限公司
成单数据库表
数据与网络技术的优势
构筑网络安全的新气象
数据库附加到服务器失败
数据库中的输入输出格式在哪
什么是网络安全整体性原则
操作系统数据库哪个复杂
软件开发工程师与算法工程师
国内 时间同步服务器
网络安全与新经济
出现网络安全问题该怎么办
网络技术英语单词