TiCDC抽取datetime、timestamp类型的数据的问题

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【TiDB 版本】v4.0.9

【问题描述】ticdc抽取datetime、timestamp类型时,系统时区为东八区;抽到kafka后,这两种类型对应的是long类型,cdc会在此基础上再添加8个小时的偏移值吗?这会导致数值不对


若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

  1. TiCDC 中的数值类型 https://docs.pingcap.com/zh/tidb/stable/ticdc-open-protocol#column-的类型码
    DATETIME 12 {“t”:12,“v”:“2015-12-20 23:58:58”}
    TIMESTAMP 7 {“t”:7,“v”:“1973-12-30 15:30:00”}
  2. 具体问题能展示一下吗? 什么数值不对? 展示一下tidb和kafka中的值


这个抽取的表数据,moment和moment1都是2021-04-01的9点;

然后avro形式抽到kafka:
{“id”:1,“name”:{“string”:“One”},“phone”:{“string”:“11111111111”},“birthday”:{“long”:1617235200000},“moment”:{“long”:1617268149000},“moment1”:{“long”:1617269227000},“money”:{“string”:“1.00”}}

都是long类型,我们在程序上直接对两个long转换成date对象,不管是datetime还是timestamp,都会变成2021-04-01的下午5点:

我们现在不考虑时区设置,想请教下ticdc是怎么处理时区问题的,谢谢:grinning:

https://docs.pingcap.com/zh/tidb/stable/deploy-ticdc#使用-binary-在原有-tidb-集群上新增-ticdc-组件(不推荐)
对于 cdc server 命令中可用选项解释如下:

  • gc-ttl :TiCDC 在 PD 设置的服务级别 GC safepoint 的 TTL (Time To Live) 时长,单位为秒,默认值为 86400 ,即 24 小时。
  • pd :PD client 的 URL。
  • addr :TiCDC 的监听地址,提供服务的 HTTP API 查询地址和 Prometheus 查询地址。
  • advertise-addr :TiCDC 对外访问地址。
  • tz :TiCDC 服务使用的时区。TiCDC 在内部转换 timestamp 等时间数据类型和向下游同步数据时使用该时区,默认为进程运行本地时区。(注意如果同时指定 tz 参数和 sink-uri 中的 time-zone 参数,TiCDC 进程内部使用 tz 指定的时区,sink 向下游执行时使用 time-zone 指定的时区)
  • log-file :TiCDC 进程运行日志的地址,默认为 cdc.log
  • log-level :TiCDC 进程运行时默认的日志级别,默认为 info
  • ca :TiCDC 使用的 CA 证书文件路径,PEM 格式,可选。
  • cert :TiCDC 使用的证书文件路径,PEM 格式,可选。
  • key :TiCDC 使用的证书密钥文件路径,PEM 格式,可选。

请教一下,你们使用 avro 的时候,kafka 的 register 是怎么配置的。

那如果是这样,ticdc转换datetime类型还是有问题吧;cdc server和tidb设置的时区都是一样的,不应该再加8个小时。

  1. 查看 SELECT @@global.time_zone, @@session.time_zone;
  2. cat /etc/localtime
  3. sink-uri 中的 time-zone 参数 ,麻烦展示下,多谢。

1.都是SYSTEM
2.cat出来,能看到CST-8的字样(应该是二进制文件不好cat);我们的设置是通过软连接方式:
/etc/localtime -> …/user/share/zoneinfo/Asia/Shanghai
3.sink-uri中没有设置time-zone信息

还请大神,帮忙看看是不是我们配置的方式需要调整,谢谢~~~

加上 --opts registry=“http://${connector的ip}:8081/”

  1. 那 ticdc 输出感觉是没有问题的,之前有用过mysql同步吗? 是正常的吗?
  2. 麻烦看下 cdc cli capture list 和 cdc cli changefeed list 的结果
  3. 不知道这个环境是测试环境还是正式环境,是否有可能开启 debug ,反馈下 log,看看有没有更多信息
    https://docs.pingcap.com/zh/tidb/stable/manage-ticdc#动态调整-ticdc-server-日志级别

1.没有cdc到mysql过;
2.这个都显示很正常
3.生产环境

针对您说的第1条,cdc输出没有问题;我是这样想的,我们所有的服务器时区设置都是一致的,tidb时区自身也没有做改动;那我在消费导出到kafka数据的时候,时间类型的字段的值,默认应该也能保持一致,可现在偏差了8个小时;

hi, @BinLi1988 确认了一下,这个时区错乱的问题是目前 cdc 在进行时间类型转换的时候,丢失了 timezone 信息导致的,我们会尽快 fix 这个 bug, 感谢反馈~

1赞

会在这个 PR 修复 https://github.com/pingcap/ticdc/pull/1615