flink cdc读取tidb binlog无法解析字节码

🪐 TiDB 技术问题
1

【TiDB 使用环境】生产环境 /测试/ Poc
【TiDB 版本】8.0.11-TiDB-v8.5.1
【操作系统】centos
【部署方式】单机部署
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】

image
image1394×760 111 KB

        <dependency>
            <groupId>org.apache.flink</groupId>
            <artifactId>flink-connector-tidb-cdc</artifactId>
            <version>3.5.0</version>
        </dependency>

        <flink.version>1.19.1</flink.version>
        <flink-cdc.version>3.2.0-1.19</flink-cdc.version>
        <cdc.version>3.2.0</cdc.version>

flink cdc官网原生写法解析出来是乱码，找gpt写了点解析逻辑还是不行。

官方写法应该是什么样子的？

2

image
从7.5开始已经不支持binlog了

3

谢谢分享

4

怎么对tidb做历史全量同步呢？整实例同步到doris，上千张表

6

1/ 现在flinkcdc和 SeaTunnel 对tidb得支持仅限于v6版本,我看flink2.1 支持jdbc了，你可以测试下
2.1 改代码双写
2.2 ticdc --kafka — doris （没有revolution）
2.3 ticdc – kafka —flink – paimon --doris catalog （支持revolution）
3/ 自己实现flink cdc connector

7

另外，上千张表 不是都要跑AP吧，你可以简单得跑tiflash, 复杂得 再入doris，这样同步得表就少了。

还有第四点，等tidb9, tidb9会发布新的ticdc，可以二次开发自定义下游

8

我们是多个边缘服务器服务器采用tidb，然后全量同步所有数据到中心服务器doris，增量应该可以走ticdc发kafka-》flink-》doris的模式

目前全量的还没有思路，尝试用flink cdc mysql source的snapshot模式来读tidb，底层报错，没搞定

9

全量离线导入不就行了，记录个时间戳，cdc再接

10

全量导入是指dumping成文件，再scp到doris集群，然后导入到doris吗？

  1. 不知道会不会文件太大，几十上百G，跨服务器（美国传到新加坡）
  2. 会对表的数据做处理，加几个额外常量字段，对date类型的业务字段，统一转为毫秒值
  3. 存在多个边缘集群往一个中心doris的同一张表写
  4. 故障恢复，比如极端情况ticdc的binlog接不起来，中间断了几分钟数据，此时要重跑全量，不然会丢
11

而且是上千张表都要同步，需要通用，自动的操作，手动一个一个搞，搞不过来

12

我能想到得 就是 你再做一个tidb（压力不大，直接换成mysql） 存储所有边缘得tidb数据
是不是aws啊，用s3挂载备份恢复也快

13

业务是打算把mysql换成tidb，分布式的，后面好扩缩容，但是下游大数据目前没有什么好的办法抽数到doris，抽到大数据做中心服务器的管理后台以及大数据实时和离线报表

14

开源 我能想到得就这些， 好像dors商业版支持tidb。

15

字符编码格式 有问题

16

应该是

17

TiDB binlog 格式与 Flink CDC 期望的解析格式不兼容，或 版本不匹配、配置缺失 导致解析失败

18

这是 Flink CDC 与 TiDB binlog 格式、版本兼容性或序列化配置不匹配导致的核心问题，常见于 TiDB 高版本（ v8.5.x、v8.1.x）与 Flink CDC 版本适配不当的场景

19

实时采用了ticdc → kafka → flink → doris
这个kafka的数据结构和flink mysql cdc的数据结构和对时间类型的处理还不一样
ticdc的kafka数据是原生的debezium的消息结构
flink mysql cdc对debezium的数据做了封装，对4种时间类型的数据做了转换格式。

需要自己适配对时间类型的转换逻辑

离线采用的是flink mysql cdc snapshot模式的改造方案

大部分源码基于flink mysql cdc snapshot的代码，
tidb的binlog和mysql的binlog差异比较大，部分需要的功能不存在，导致mysql cdc源码不能完全适配，会报错。
注释和修改了部分关于binlog，gtid相关的一些逻辑，从而能跑通离线抽数。
但是引入了极端情况下的数据异常，snapshot期间，主键发生变更，可能数据多条的场景。

但是这种异常可以接受，人工可以处理。

初步是这种方案。后面还要跑起来验证稳定性和问题

20

flink 任务采用streampark管理，这种方式不用手动执行mysql dump类似的导入导出操作。

避免了scp 几十上百G文档的操作，交给flink做快照慢慢抽取数据

21

新版本就别折腾 binlog 了，binlog 已经基本不维护了。
当前这个思路可以的。

至于存量的话，dumpling 可以的，会有一个 snapshot，cdc 用这个 tso 来增量同步数据即可。
存量 dumpling 导出 csv 导入 Doris 呗。
csv 可以压缩一下，跨网络传输到 Doris 服务器上，加载进去我理解就好了。