mysql 主从同步原理 以及陷阱
2014-12-29 14:49
323 查看
http://www.percona.com/blog/2013/01/09/how-does-mysql-replication-really-work/
http://ssmax.net/archives/1185.html/comment-page-1#comment-506263
下面说下查找问题的过程
按照最新的说法,大家觉得是主从库(新旧库的关系就是主从)版本不一致导致的问题,这个问题我从一开始就不认为是个问题,如果主库是低版本,从库是高版本(指小版本的差异,非大版本),这样的同步是没有问题的,因为高版本的mysql会向下兼容,但是反过来的话就可能有问题,我们主库是5.5.38,从库是5.5.40,这样的同步是没有问题的,而且小版本的更新也从来没有过SQL不兼容这样的大改动.另外我也没有找到5.5.38或者5.5.40的相关bug或者特性冲突会导致不同步的问题.
但是和朝建分析下来后感觉除了版本问题外好像找不到其他原因了,所以死马当活马医,下午我在新库的SLAVE上把5.5.40,降级为5.5.38,同步fdd_dot_log表后发现仍然是一部分同步过来了,一部分没有同步过来.
排除了数据库版本的问题,那么新库SLAVE和旧库SLAVE的唯一差别就是,旧库SLAVE是所有库全部同步,新库SALVE是指定个别库表同步.
在新库上的MySQL配置指定同步的库用到了如下参数
replicate-do-db=DB_NAME
replicate-wild-do-table=DB_NAME.% //表示同步该DB下的所有TABLE,且该参数支持跨库同步
这2个参数的意思是,replicate-do-db指定需要同步的库,但是DB_NAME.TABLE_NAME这样的跨库操作就会被忽略,我知道我们应该会有很多跨库操作,所以又加了replicate-wild-do-table=DB_NAME.%来支持跨库操作的同步.这个配置我在以前的公司一直使用从未出现过问题,所以这次同步我也同时使用了这2个参数.但是为什么会出问题呢.....(仍然可以参考http://ssmax.net/archives/1185.html/comment-page-1#comment-506263)
后来我问了以前的同事,他表示以前公司的程序没有任何跨库操作的行为和需求,因为一般情况下在与数据库建立链接的时候就已经指定库了.所以不需要再使用INSERT DB_NAME.TABLE_NAME这样的动作,直接操作TABLE_NAME就OK了.
也就是说replicate-wild-do-table在以前公司的环境根本就是个摆设.
为了验证这个问题,测试了以下几组配置(测试table为当时出现问题的fdd_dot_log)
1.同时使用replicate-do-db和replicate-wild-do-table
2.只使用replicate-do-db
3.只使用replicate-wild-do-table
结果证明除了配置3,其他2组配置均会发生一部分数据同步,而且另一部分没有同步的现象.而配置3则完全同步了.
也就是说在配置1的情况下,如果我们有跨库的操作,过滤规则上会直接匹配replicate-do-db而忽略replicate-wild-do-table,这也是为什么我和朝建单独测试个别数据的时候没有这个问题的原因,因为单独测试个别数据的时候不涉及到跨库操作的问题.(但是按照MYSQL的官方文档解释如果存在replicate-wild-do-table这样的表级同步的参数,最终会去匹配这个表级的同步参数的策略,大家有兴趣可以看下这个链接里的流程图http://dev.mysql.com/doc/refman/5.5/en/replication-rules-db-options.html)
解决方案:只使用replicate-wild-do-table即可.(业务端如果能杜绝不必要的跨库操作就更好了)
主从同步例子
http://wanghaipeng1124.blog.51cto.com/2500801/874651
http://wanghaipeng1124.blog.51cto.com/2500801/874661
陷阱
#新库
event_scheduler = OFF 当设置主从同步的时候,,主库的event默认会同步到从库,,如果从库不需要 event,,就可以配置这个属性
http://dev.mysql.com/doc/refman/5.1/en/replication-features-triggers.html
Mysql trigger,event,function,
STORED PROCEDURES 如何同步到slave
http://www.percona.com/blog/2011/12/16/statement-based-replication-with-stored-functions-triggers-and-events/
新的坑
http://bugs.mysql.com/bug.php?id=72682
从库的配置
replicate-wild-do-table=DB1.%
replicate-wild-do-table=DB2.%
主库,在 DB3创建一个使用DB3的存储过程,,,结果会同步到slave,导致主从同步失败,,,(mysql版本是5.5.3.7)
解决方案很土:在slave上把主库上所有的库都重新建一遍
因为涉及到跨库操作,,所以必须用replicate-wild-do-table
如果没有涉及到跨库操作,,,replicate-do-db 可以解决这个问题
再一个坑
master A ——> slave B ——> slave C 的坑
log_slave_updates
http://www.ttlsa.com/mysql/mysql-cascading-replication-_a-_b-_c/
MYSQL 主从同步文档的大坑
http://ssmax.net/archives/1185.html/comment-page-1#comment-506263下面说下查找问题的过程
按照最新的说法,大家觉得是主从库(新旧库的关系就是主从)版本不一致导致的问题,这个问题我从一开始就不认为是个问题,如果主库是低版本,从库是高版本(指小版本的差异,非大版本),这样的同步是没有问题的,因为高版本的mysql会向下兼容,但是反过来的话就可能有问题,我们主库是5.5.38,从库是5.5.40,这样的同步是没有问题的,而且小版本的更新也从来没有过SQL不兼容这样的大改动.另外我也没有找到5.5.38或者5.5.40的相关bug或者特性冲突会导致不同步的问题.
但是和朝建分析下来后感觉除了版本问题外好像找不到其他原因了,所以死马当活马医,下午我在新库的SLAVE上把5.5.40,降级为5.5.38,同步fdd_dot_log表后发现仍然是一部分同步过来了,一部分没有同步过来.
排除了数据库版本的问题,那么新库SLAVE和旧库SLAVE的唯一差别就是,旧库SLAVE是所有库全部同步,新库SALVE是指定个别库表同步.
在新库上的MySQL配置指定同步的库用到了如下参数
replicate-do-db=DB_NAME
replicate-wild-do-table=DB_NAME.% //表示同步该DB下的所有TABLE,且该参数支持跨库同步
这2个参数的意思是,replicate-do-db指定需要同步的库,但是DB_NAME.TABLE_NAME这样的跨库操作就会被忽略,我知道我们应该会有很多跨库操作,所以又加了replicate-wild-do-table=DB_NAME.%来支持跨库操作的同步.这个配置我在以前的公司一直使用从未出现过问题,所以这次同步我也同时使用了这2个参数.但是为什么会出问题呢.....(仍然可以参考http://ssmax.net/archives/1185.html/comment-page-1#comment-506263)
后来我问了以前的同事,他表示以前公司的程序没有任何跨库操作的行为和需求,因为一般情况下在与数据库建立链接的时候就已经指定库了.所以不需要再使用INSERT DB_NAME.TABLE_NAME这样的动作,直接操作TABLE_NAME就OK了.
也就是说replicate-wild-do-table在以前公司的环境根本就是个摆设.
为了验证这个问题,测试了以下几组配置(测试table为当时出现问题的fdd_dot_log)
1.同时使用replicate-do-db和replicate-wild-do-table
2.只使用replicate-do-db
3.只使用replicate-wild-do-table
结果证明除了配置3,其他2组配置均会发生一部分数据同步,而且另一部分没有同步的现象.而配置3则完全同步了.
也就是说在配置1的情况下,如果我们有跨库的操作,过滤规则上会直接匹配replicate-do-db而忽略replicate-wild-do-table,这也是为什么我和朝建单独测试个别数据的时候没有这个问题的原因,因为单独测试个别数据的时候不涉及到跨库操作的问题.(但是按照MYSQL的官方文档解释如果存在replicate-wild-do-table这样的表级同步的参数,最终会去匹配这个表级的同步参数的策略,大家有兴趣可以看下这个链接里的流程图http://dev.mysql.com/doc/refman/5.5/en/replication-rules-db-options.html)
解决方案:只使用replicate-wild-do-table即可.(业务端如果能杜绝不必要的跨库操作就更好了)
主从同步例子
http://wanghaipeng1124.blog.51cto.com/2500801/874651
http://wanghaipeng1124.blog.51cto.com/2500801/874661
陷阱
#新库
event_scheduler = OFF 当设置主从同步的时候,,主库的event默认会同步到从库,,如果从库不需要 event,,就可以配置这个属性
http://dev.mysql.com/doc/refman/5.1/en/replication-features-triggers.html
Mysql trigger,event,function,
STORED PROCEDURES 如何同步到slave
http://www.percona.com/blog/2011/12/16/statement-based-replication-with-stored-functions-triggers-and-events/
新的坑
http://bugs.mysql.com/bug.php?id=72682
从库的配置
replicate-wild-do-table=DB1.%
replicate-wild-do-table=DB2.%
主库,在 DB3创建一个使用DB3的存储过程,,,结果会同步到slave,导致主从同步失败,,,(mysql版本是5.5.3.7)
解决方案很土:在slave上把主库上所有的库都重新建一遍
因为涉及到跨库操作,,所以必须用replicate-wild-do-table
如果没有涉及到跨库操作,,,replicate-do-db 可以解决这个问题
再一个坑
master A ——> slave B ——> slave C 的坑
log_slave_updates
http://www.ttlsa.com/mysql/mysql-cascading-replication-_a-_b-_c/
相关文章推荐
- Linux(Ubuntu)环境MYSQL->master/slave主从同步设置以及注意事项
- mysql 主从同步原理 [转]
- MYSQL主从不同步延迟原理
- MySQL主从复制原理、主从复制(异步)、半同步复制、基于SSL复制
- MYSQL主从不同步延迟原理
- Linux(Ubuntu)环境MYSQL->master/slave主从同步设置以及注意事项
- MySQL 5.5 主从复制异步、半同步以及注意事项详解
- mysql 主从同步原理
- Mysql原理、主从复制、半同步复制及基于SSL复制
- MySQL主从复制原理、主从复制(异步)、半同步复制、基于SSL复制 推荐
- Mysql主从库同步原理分析和多线程同步
- MYSQL主从复制原理以及架构
- mysql 主从同步原理
- MySQL主从同步原理+部署
- MYSQL主从不同步延迟原理分析及解决方案
- Mysql 主从数据库 数据同步 原理
- MySQL主从复制的原理及实现过程(mysql-5.5的同步、半步复制过程) 推荐
- mysql主从同步原理
- mysql 主从同步过程详解、主从延迟原理分析
- mysql 主从 同步原理及配置