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则完全同步了.
解决方案:只使用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/