数据管道常见问题

问题描述：

管道运行中报错：ERROR  Exception when realtime job run - com.fr.dp.exception.FineDPException: exception during get all topics from broker.

原因分析：

kafka 未启动，无法获得相关 topics。

解决方案：

检查传输队列的测试连接可不可以成功，同时使用 jps 命令(需要有jdk环境)，查看 kafka 状态。有时候 jps 命令不可用，也可使用命令：ps -ef|grep kafka 查看 kafka 进程

jps 命令结果如下图则 kafka 服务器启动正常：

如果无对应 kafka 进程，则需要启动进程，详情参见： 启动Kafka

问题描述：

原因：

连接没问题，但是表存在问题，有一个表配置了336个字段，实际上这个表只有289个字段。

解决方案：

检查发现同步的表中，目标表有个同名表是已经存在的，但是表结构是不一样的，导致报错。

问题描述：

Kafka 重新启动失败，没有进程。

原因分析：

Kafka 和 zookeeper 关闭先后顺序不对导致的问题。

解决方案：

删除 Kafka 日志文件目录下的 meta.properties 文件，重启 zookeeper 和 Kafka。

重启步骤详情参见：启动Kafka

问题描述：

传输队列测试连接失败，报错 connect timeout

原因分析：

FDL 和 Kafka 不在一台机器上，需要跨服务器访问，而 kafka 默认是 localhost 访问，因此需要在配置文件设置 ip 进行访问

解决方案：

在 server.properties 需要配置 listeners，取消注释，并设置为具体ip

详情参见：增加配置。

问题描述：

FDL只能运行几个管道任务，再运行新的管道任务就报错：“正在运行的任务数量达到上限“

原因分析：

受到资源控制里设置的内存大小影响，一个管道任务运行占用1024M。如资源控制的内存限制设置了2050M，则向下取整，最多执行2个管道任务。 即控制管道任务的运行数量。
定时和管道任务用的内存不会超过资源控制设定的上限，但需要注意的是因为目前定时任务和管道任务共用一个内存限制，内存限制的数值大小等于JVM的大小时，容易产生宕机现象。

解决方案：

在资源控制中根据资源控制内存计算方式修改内存限制。

问题描述：

前端报错如图：

fanruan.log报错SQL执行失败 - No corresponding type for code: 0

原因分析：

缺少了 sys下面的某些权限

解决方案：

给用户赋数据库 onwer 的权限

问题描述：

任务运行失败，日志报错：

MySQLSyntaxErrorException: Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation

解决方案：

给 MySQL 数据库开启复制权限，详情参见：给指定账号开启复制权限

问题描述：

管道任务异常终止：

解决方案：

MySQL 同步的单条数据所用内存 超过了 Kafka 的 max.request.size 参数的值所导致的，这个参数限制了 Kafka 能够处理的最大请求大小。 

该参数由FDL提供给 kafka，但目前在FDL中默认设置为了5MB，无法手动调整。 

需要将来源表中长度较长的字段先在同步中去掉，比如json、longtext等字段，将单条数据的内存量降低。

问题描述：

数据管道任务进行同步全量阶段报错：duplicate key

原因分析：

管道中存在多个数据库，不同数据库中存在同名表。

解决方案：

此问题已经在 4.0.20 修复，用户可升级解决。

问题描述：

任务运行报错：Write table's column number[75] more than db table's column number[73]

原因分析：

实时同步前目标库下已存在有同名表。

解决方案：

删掉目标库中的同名表后再运行管道任务。

问题描述：

fanruan日志里报错：SQL执行失败-.NET Framework运行时停止

解决方案：

排查数据库是不是在管道任务运行期间进行了重启，如果是，需要避免在管道任务运行期间重启数据库。

问题描述：

任务报错：“事务进程[ID 101]与另一个进程被死锁在锁资源上，并且已被选作死锁牺牲品，请重新运行该事务。”

原因：

外置finedb是SQL server，SQL server是块锁，再进行save or update操作时，如果先查询，则会给一块的数据加共享锁，如果两个事务同时给数据加了共享锁。其中一个事务想更新的时候，因为要升级锁，就会导致死锁，就会牺牲掉一个线程，导致任务的失败。

解决方案：

方案一：

1. 设置隔离级别

hibernate.connection.isolation=8

（这个配置是使得事务之间完全隔离，互不影响）

2. 设置SqlServer的行版本控制功能打开

SET ALLOW_SNAPSHOT_ISOLATION ON
SET READ_COMMITTED_SNAPSHOT ON

（第一个配置项是允许事务可以读取其他事务未提交的数据快照；第二个配置项是使读操作不会锁定数据）

方案二：

切换外置finedb为MySQL或者Oracle。

问题描述：

MySQL-GaussDB 200数据管道任务自动建表全部报错为脏数据

原因：

不同数据库中的中文的字符存贮长度不同，GaussDB 200的长度是MySQL库的三倍，截止版本4.0.13，FDL自动建表逻辑是一比一映射，导致目标表的字段长度不够，写进来的数据全部判断为脏数据。

解决方案：

在数据库修改目标表的字段长度。

问题描述：

数据管道任务执行成功，但写入的数据与数据库中的数据存在差异，一些最新数据未被写入。

原因分析：

写入数据库的update_time与FineDataLink的更新时间不一致

解决方案：

用户自行修复数据库的时间设置即可。

问题描述：使用了数据管道，目标库为sql server。在管道任务运行时，该sql server库上的存储过程运行以及查视图等操作会阻塞，执行很慢。关掉管道任务后，运行通畅。 

原因分析：

sql server 自身存在锁的机制，数据写入后，写入的表会上锁，读操作会等待。

该场景中管道任务高频写入，导致数据库表长时间处于锁表状态，读取操作阻塞，原本只需几分钟执行的存储过程，开启管道任务后需要10多个小时才能执行完成。

解决方案有三种，可根据情况选定。

1）存储过程加 with no lock

影响：可能会导致脏读，数据不写入。但是我们管道任务会把这部分数据记录，最终还是可以写入进去的
2）晚上执行存储过程

一般来说白天业务会比较繁忙，数据同步量大。考虑将存储过程放到晚上执行，业务不频繁，存储过程受锁的影响应该会降低。

3）设置 snapshot 快照隔离级别

操作步骤：

• 确认数据库兼容性级别：快照隔离要求数据库兼容性级别至少为90。可以使用以下命令检查当前数据库的兼容性级别：

           SELECT compatibility_level FROM sys.databases WHERE name = 'YourDatabaseName';

            如果兼容性级别低于90，可以使用以下命令将其更改为90或更高：

            ALTER DATABASE YourDatabaseName SET COMPATIBILITY_LEVEL = 90;

• 开启快照隔离：可以使用以下命令在数据库中开启快照隔离：

          ALTER DATABASE YourDatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON;

• 确认开启成功：可以使用以下命令检查是否已经开启了快照隔离：

          SELECT is_read_committed_snapshot_on FROM sys.databases WHERE name = 'YourDatabaseName';

影响：可能会产生额外的数据库存储开销，因为SQL Server会自动创建用于维护快照隔离的版本存储器；可能会影响写入性能。