Streamsets FAQ（五）关于SS增量同步mysql数据过程中offset值时间偏差问题

1、问题描述

CDH-6.2.0，SS-3.13.0。在使用SS同步mysql数据到kudu时使用JDBC Query Consumer，因为mysql的datetime数据到kudu的timestamp后少了8小时，给JDBC Query Consumer中JDBC配置添加了额外配置项，在最后的Additional JDBC Configuration Properties中增加2个配置

serverTimezone    UTC
useTimezone    true

 

添加这2个配置后刚启动pipeline时MySQL存量数据到kudu的话数据都没问题了，但是该pipeline中配置的SQL语句是每隔3秒运行一次，根据update_at取最近变化的数据，这里发生问题了。因为SQL每次循环执行的时候offset值是在变化，offset的column选择的是update_at这种时间字段，当配置了serverTimezone为UTC之后，offset的值会比当前真实值大8小时。比如给定的offset初始值为2020-04-07 11:31:50，当前所有记录中update_at值最大的为2020-04-08 11:31:50，那么理论上该值会被作为offset值保留下来，那么下一次执行的SQL应该为

select * from test where update_at>'2020-04-08 11:31:50' order by update_at;

但是实际上因为serverTimezone的原因offset值被增加了8小时，变成了2020-04-08 19:31:50，实际执行的SQL为

select * from test where update_at>'2020-04-08 19:31:50' order by update_at;

这就有问题了，这8小时内所有变化的数据都无法获取到了，导致两边数据出现了不一致。

 

2、解决方案

试了好几种方式，包括设置serverTimezone为Aisa/shanghai等等，最终都不生效，因为我需要首先保证数据到kudu是正确的。最终采用的方案是修改JDBC Query Consumer中的SQL，使用mysql的DATE_SUB函数对offset减去8小时，虽然每次SS保留的offset依然多了8小时，但是传递给mysql引擎的update_at是减去8小时后的正确值，因此数据不会丢失了。

select * from test where update_at>DATE_SUB('${OFFSET}',INTERVAL 8 HOUR) order by update_at