最近在搞数据实时同步的活把Oracle的业务数据实时同步到StarRocks给分析用。用的阿里云Flink最新版本 vvr-11.7-jdk11-flink-1.20。选型没什么好说的Flink CDC 读 Oracle写 StarRocks方案很成熟。但阿里云原生不带 Oracle CDC 的 Connector得自己上传开源社区的flink-sql-connector-oracle-cdc-3.0.1上去这个倒还好早有心理准备。结果一上手就是连环坑。先说第一个JDBC 驱动的问题。SQL 写好了建好表点启动直接报错——说无法解析 Oracle 数据库版本找不到 JDBC 驱动。测试环境我们是自建Flink所以版本没问题。我当时想这还不简单传个 ojdbc 上去呗。传了还是报。换了个版本报了另一个错ClassNotFound。再换又来个方法找不到。来来回回试了好几个版本的组合才跑通。阿里云官方也没个明确的依赖推荐列表这东西就是靠试。最后用的ojdbc8-19.3.0.0 版本后面建任务直接复制不想再折腾第二遍。反正就是一句话用阿里云 Flink 跑 Oracle CDC驱动这块一定要提前留出时间来调试别想着一把过。然后第二个问题比较头疼从 Savepoint 恢复任务的时候特别慢。任务跑起来之后同步是没问题的但有次需要重启一下从 Savepoint 恢复等了好几分钟才真正开始跑数据。一开始以为是偶发的没在意后来手动停了再重启还是慢。试了几次都这样那就不是运气问题了。后来排查下来原因是 Savepoint 的状态文件存在 OSS 上恢复的时候要从远程把这些文件拉回来再重建状态引擎。全量快照阶段的状态文件挺大的好几个 G光下载就要好一会儿。解决思路有两个。一个是开 Local RecoveryTaskManager 本地会保留一份状态副本Failover 的时候读本地的不走远程下载速度很快。但这玩意有个坑——它只对 Failover 和动态参数更新有效手动停任务再启动它是不管的还是老老实实走远程。另一个是用 GeminiStateBackend 的懒加载这个对手动重启也管用。原理是状态文件异步下载不用等全加载完作业就能跑起来。代价是刚起来那一阵性能会差一点状态是边用边拉的。不过对于同步任务来说起步慢一点总比卡在那里干等强。最后在部署详情的运行参数配置里加了 Gemini 懒加载的参数恢复时间确实压下来了从好几分钟降到几十秒。这两个方案的适用场景不一样别搞混了。Local Recovery 管意外挂掉的情况Gemini 懒加载管你主动重启的情况。第三个坑比较隐蔽VARCHAR2 的长度映射。Oracle 那边字段类型是VARCHAR2(100)我在 StarRocks 建表的时候直接写了VARCHAR(100)数字一样嘛觉得没问题。跑了一段时间之后发现有些记录写入 StarRocks 报错了提示字段超长。一开始还纳闷100 对 100 怎么就不够了后来想明白了。Oracle 的 VARCHAR2 长度是按字节算的StarRocks 的 VARCHAR 是按字符算的。一个中文字在 UTF-8 下占 3 个字节所以这里面的换算关系不是 1:1。简单粗暴的做法就是映射的时候 StarRocks 那边长度直接乘 3Oracle 的 VARCHAR2(100) 在 StarRocks 建 VARCHAR(300)省得后面一个个去排查。这种事不踩一次还真不知道。第四个坑是最狠的归档日志过期。有天任务突然挂了报错信息里有个offset scn not found大概意思是 CDC 上次记录的那个读取位点对应的 Oracle 归档日志已经被清掉了。去问了下 DBA归档日志只保留了 2 天。偏偏这次任务停了两天多才恢复日志早就没了LogMiner 没法接着读。增量链路断了没别的办法只能清掉 Checkpoint 状态重新跑全量。数据量大全量跑了好久但那会儿也只能等着。事后做了两件事。一是让 DBA 把归档保留策略从 2 天延到了 7 天CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;二是给 CDC 任务加了 SCN 回退参数留点容错空间debezium.log.mining.scn.rewind.distance 50000 debezium.log.mining.scn.rewind.time.ms 300000这个坑的教训就是用 CDC 读 Oracle归档保留时间一定要比任务可能的最长中断时间长不然断了就只能全量重来很痛苦。但还是有个隐患归档保留策略从2天延到了7天会导致服务器磁盘占用很大 后期一定要注意磁盘使用的增量问题否则会导致整个库异常。搞完之后回头看这些问题单个拿出来都不算什么大事但堆在一起确实磨人。尤其是一些细节上的东西像 Local Recovery 只管 Failover 不管手动重启、VARCHAR2 按字节不算字符、归档日志默认只留 2 天这种事不看文档不踩坑根本不会注意。就记这么多吧下次再搞类似的同步任务直接翻这篇省得重复踩坑。
最近在搞数据实时同步的活把Oracle的业务数据实时同步到StarRocks给分析用。用的阿里云Flink最新版本 vvr-11.7-jdk11-flink-1.20。选型没什么好说的Flink CDC 读 Oracle写 StarRocks方案很成熟。但阿里云原生不带 Oracle CDC 的 Connector得自己上传开源社区的flink-sql-connector-oracle-cdc-3.0.1上去这个倒还好早有心理准备。结果一上手就是连环坑。先说第一个JDBC 驱动的问题。SQL 写好了建好表点启动直接报错——说无法解析 Oracle 数据库版本找不到 JDBC 驱动。测试环境我们是自建Flink所以版本没问题。我当时想这还不简单传个 ojdbc 上去呗。传了还是报。换了个版本报了另一个错ClassNotFound。再换又来个方法找不到。来来回回试了好几个版本的组合才跑通。阿里云官方也没个明确的依赖推荐列表这东西就是靠试。最后用的ojdbc8-19.3.0.0 版本后面建任务直接复制不想再折腾第二遍。反正就是一句话用阿里云 Flink 跑 Oracle CDC驱动这块一定要提前留出时间来调试别想着一把过。然后第二个问题比较头疼从 Savepoint 恢复任务的时候特别慢。任务跑起来之后同步是没问题的但有次需要重启一下从 Savepoint 恢复等了好几分钟才真正开始跑数据。一开始以为是偶发的没在意后来手动停了再重启还是慢。试了几次都这样那就不是运气问题了。后来排查下来原因是 Savepoint 的状态文件存在 OSS 上恢复的时候要从远程把这些文件拉回来再重建状态引擎。全量快照阶段的状态文件挺大的好几个 G光下载就要好一会儿。解决思路有两个。一个是开 Local RecoveryTaskManager 本地会保留一份状态副本Failover 的时候读本地的不走远程下载速度很快。但这玩意有个坑——它只对 Failover 和动态参数更新有效手动停任务再启动它是不管的还是老老实实走远程。另一个是用 GeminiStateBackend 的懒加载这个对手动重启也管用。原理是状态文件异步下载不用等全加载完作业就能跑起来。代价是刚起来那一阵性能会差一点状态是边用边拉的。不过对于同步任务来说起步慢一点总比卡在那里干等强。最后在部署详情的运行参数配置里加了 Gemini 懒加载的参数恢复时间确实压下来了从好几分钟降到几十秒。这两个方案的适用场景不一样别搞混了。Local Recovery 管意外挂掉的情况Gemini 懒加载管你主动重启的情况。第三个坑比较隐蔽VARCHAR2 的长度映射。Oracle 那边字段类型是VARCHAR2(100)我在 StarRocks 建表的时候直接写了VARCHAR(100)数字一样嘛觉得没问题。跑了一段时间之后发现有些记录写入 StarRocks 报错了提示字段超长。一开始还纳闷100 对 100 怎么就不够了后来想明白了。Oracle 的 VARCHAR2 长度是按字节算的StarRocks 的 VARCHAR 是按字符算的。一个中文字在 UTF-8 下占 3 个字节所以这里面的换算关系不是 1:1。简单粗暴的做法就是映射的时候 StarRocks 那边长度直接乘 3Oracle 的 VARCHAR2(100) 在 StarRocks 建 VARCHAR(300)省得后面一个个去排查。这种事不踩一次还真不知道。第四个坑是最狠的归档日志过期。有天任务突然挂了报错信息里有个offset scn not found大概意思是 CDC 上次记录的那个读取位点对应的 Oracle 归档日志已经被清掉了。去问了下 DBA归档日志只保留了 2 天。偏偏这次任务停了两天多才恢复日志早就没了LogMiner 没法接着读。增量链路断了没别的办法只能清掉 Checkpoint 状态重新跑全量。数据量大全量跑了好久但那会儿也只能等着。事后做了两件事。一是让 DBA 把归档保留策略从 2 天延到了 7 天CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;二是给 CDC 任务加了 SCN 回退参数留点容错空间debezium.log.mining.scn.rewind.distance 50000 debezium.log.mining.scn.rewind.time.ms 300000这个坑的教训就是用 CDC 读 Oracle归档保留时间一定要比任务可能的最长中断时间长不然断了就只能全量重来很痛苦。但还是有个隐患归档保留策略从2天延到了7天会导致服务器磁盘占用很大 后期一定要注意磁盘使用的增量问题否则会导致整个库异常。搞完之后回头看这些问题单个拿出来都不算什么大事但堆在一起确实磨人。尤其是一些细节上的东西像 Local Recovery 只管 Failover 不管手动重启、VARCHAR2 按字节不算字符、归档日志默认只留 2 天这种事不看文档不踩坑根本不会注意。就记这么多吧下次再搞类似的同步任务直接翻这篇省得重复踩坑。
