Flink CDC里这是什么问题？

在Flink CDC中遇到问题时，通常需要结合具体的错误信息、使用场景和配置来分析原因并提供解决方案。以下是针对常见问题的详细解析与解决方法：

1. MySQL CDC读取全量数据后不读增量数据

问题描述：

• MySQL CDC作业在完成全量数据读取后，无法继续读取增量数据。

可能原因及解决方案：

1. RDS MySQL 5.6备库或只读实例：

   • 原因：这些实例未向日志文件写入数据。
   • 解决方案：建议使用可写实例或升级RDS MySQL至更高版本。

2. 全量阶段读取时间过长导致OOM：

   • 原因：全量阶段最后一个分片数据量过大，导致内存溢出。
   • 解决方案：增加MySQL Source端的并发度，加快全量读取速度。

3. Checkpoint间隔时间设置过大：

   • 原因：进入增量阶段前需等待一个Checkpoint，若间隔时间过长会导致作业卡住。
   • 解决方案：根据业务需求设置合理的Checkpoint间隔时间。

2. Binlog格式为Mixed导致报错

报错信息：

binlog probably contains events generated with statement or mixed based replication format

问题原因：

• MySQL的Binlog格式为Mixed，而Flink CDC要求Binlog格式为ROW。

解决方案：

1. 检查当前Binlog格式：

   SHOW VARIABLES LIKE "binlog_format";
   

2. 修改Binlog格式为ROW：

   SET GLOBAL binlog_format=ROW;
   

3. Replication Slot冲突

报错信息：

Replication slot "xxxx" is active

问题原因：

• PostgreSQL的Replication Slot被占用，导致CDC作业无法启动。

解决方案：

1. 手动释放Slot：

   SELECT pg_drop_replication_slot('rep_slot');
   

2. 自动清理Slot：在Postgres Source配置中添加以下参数：

   'debezium.slot.drop.on.stop' = 'true'
   

4. 表名正则表达式无法解析逗号

问题描述：

• 使用table-name正则表达式时，包含逗号的表达式无法正确解析。

问题原因：

• Debezium使用逗号作为分隔符，不支持带逗号的正则表达式。

解决方案：

• 使用括号将多个正则表达式组合起来。例如：

  'table-name' = '(t_process_wi_history_\d{1}|t_process_wi_history_\d{2})'
  

5. 增量阶段读取的timestamp字段时区相差8小时

问题描述：

• 在增量阶段读取的timestamp字段时区与预期不符，相差8小时。

问题原因：

• CDC作业中配置的server-time-zone参数未与MySQL服务器时区一致。

解决方案：

• 确保在DataStream API中使用自定义序列化器时，正确配置serverTimeZone参数。例如：

  .deserializer(new JsonDebeziumDeserializationSchema())
  .option("server-time-zone", "Asia/Shanghai")
  

6. 无法下载SNAPSHOT版本依赖

问题描述：

• 无法下载flink-sql-connector-mysql-cdc-2.2-SNAPSHOT.jar。

问题原因：

• xxx-SNAPSHOT版本对应开发分支代码，未发布到Maven中央仓库。

解决方案：

• 使用稳定版本，例如flink-sql-connector-mysql-cdc-2.1.0.jar，可直接从Maven中央仓库获取。

7. 多个CDC作业导致数据库压力过大

问题描述：

• 多个CDC作业同时运行，导致数据库压力过大。

解决方案：

1. 通过Kafka解耦：

   • 将表同步到Kafka消息队列中，再通过消费Kafka中的数据进行解耦。

2. 合并CTAS作业：

   • 将多个CTAS作业合并为一个作业运行，并为每个MySQL CDC源表配置相同的Server ID，实现数据源复用，减小数据库压力。

8. 数据量不大但Flink读取时消耗大量带宽

问题描述：

• MySQL源表数据更新量不大，但Flink读取时消耗了大量带宽。

问题原因：

• Binlog是实例级别的，记录所有数据库和表的变更。Flink CDC通过配置过滤特定表的变更记录，但过滤过程发生在Debezium或Flink CDC连接器层面。

解决方案：

• 通过Source复用避免更多的带宽使用。

9. Encountered change event for table whose schema isn't known

报错信息：

Encountered change event for table xxx.xxx whose schema isn't known to this connector

问题原因：

• 数据库用户权限不足，或未正确捕获表结构变更。

解决方案：

1. 确认数据库用户是否具有对应作业中全部数据库的相应权限。
2. 避免使用'debezium.snapshot.mode'='never'，可通过以下参数避免报错：

   'debezium.inconsistent.schema.handling.mode' = 'warn'
   

10. The connector is trying to read binlog starting at GTIDs, but this is no longer available

报错信息：

The connector is trying to read binlog starting at GTIDs ..., but this is no longer available on the server

问题原因：

• MySQL服务器上设置的Binlog文件过期时间太短，或CDC作业处理Binlog的速度过慢。

解决方案：

1. 增加Binlog的保留时间：

   SET GLOBAL expire_logs_days=7;
   

2. 分配更多资源给Flink作业，加快处理速度。

以上是对Flink CDC常见问题的详细解析与解决方案。如果您的问题未涵盖在上述内容中，请提供更多具体信息以便进一步分析。