Mysql数据实时同步实践( 三 )


 
疑难杂症下面分享2个上线后遇到的有趣问题
>>>>数据不一致问题,业务使用唯一索引
业务接入一段时间后, 发现部分表会偶尔存在kudu表的数据条目数多于同步的mysql表的数据条目数,我们将多出来的数据与mysql产生的binlog日志经过一一对比,发现用户在mysql表中设置了唯一索引,通过唯一索引修改了主键,而kudu中的数据是通过主键标识或更新一条记录的,于是update操作变成了insert操作,这就造成了原来的1条记录变成了2条 。
解决办法:对于这种类型的表,LCSBinlog服务会把一次Update操作转换成一条Delete数据和一条Insert数据
>>>>Full Dump同步历史数据时,客户端超时
服务刚上线的时候,通过jdbc 执行sql的方式完成全量历史数据的同步,在同步的过程中会发现dump任务会卡顿很长时间才会返回结果,当数据量很大会出现超时同步失败的情况,会造成数据的延迟 。调研后发现使用mysql官方jdbc在客户端查询数据的时候,默认为从服务器一次取出所有数据放在客户端内存中,fetch size参数不起作用,当一条SQL返回数据量较大时可能会出现OOM
解决办法:当statement设置以下属性时,采用的是流数据接收方式,每次只从服务器接收部份数据,直到所有数据处理完毕 。优化后历史数据同步稳定运行,对mysql端的压力也很小

Mysql数据实时同步实践

文章插图
 
总结MySQL以Binlog日志的方式记录数据变化,基于流式数据的Change Data Caputre (CDC)机制实现了LCSBinlog服务,
本文主要对LCSBinlog的服务架构、应用场景以及在小米内部的实践经验进行了介绍,也和大家分享了我们实际中遇到的问题和解决方案




推荐阅读