有大佬解答下，Flink CDC中这个情况怎么办呀？

根据您提供的问题描述，以下是针对 Flink CDC 中常见问题的详细解答和解决方案：

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

如果 MySQL CDC 在完成全量数据同步后没有继续读取增量数据，可能是以下原因导致的： - Binlog配置问题：检查 MySQL 的 binlog 是否开启，并确认 binlog_format 设置为 ROW 模式。 - 作业状态异常：确保 Flink 作业在全量阶段完成后正确切换到增量阶段。可以通过监控指标 currentEmitEventTimeLag 判断是否进入增量阶段。

解决方案： 1. 确认 MySQL 配置：

SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'log_bin';

如果未启用或格式不正确，请修改 MySQL 配置文件并重启服务。 2. 检查 Flink 日志中是否有 BinlogSplitReader is created 的日志输出，确认是否成功切换到增量阶段。

2. Flink CDC作业失败后持续重启

默认情况下，Flink 作业会在失败后尝试重启。如果您希望作业失败后彻底退出，可以调整 Flink 的重启策略。

解决方案： 通过以下配置指定重启策略，限制最大重启次数：

restart-strategy: fixed-delay
restart-strategy.fixed-delay.attempts: 2
restart-strategy.fixed-delay.delay: 10 s

上述配置表示最多尝试重启两次，每次间隔 10 秒。如果两次重启均失败，则作业将彻底退出。

3. MySQL CDC使用正则表达式无法解析逗号

当使用 table-name 参数时，Debezium 不支持带逗号的正则表达式。

解决方案： 将正则表达式改写为逻辑“或”的形式。例如：

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

这样可以避免逗号解析错误的问题。

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

当多个 CDC 作业同时运行时，可能会对 MySQL 数据库造成较大压力。

解决方案： 1. 通过 Kafka 解耦：将表数据同步到 Kafka 消息队列中，再通过消费 Kafka 数据进行解耦。 2. 合并 CTAS 作业：将多个 CTAS（Create Table As Select）作业合并为一个作业运行，并为每个 MySQL CDC 源表配置相同的 server-id，实现数据源复用。

5. Flink读取MySQL CDC时消耗大量带宽

即使数据量不大，Flink 读取 MySQL CDC 时仍可能消耗大量带宽，原因是 Binlog 是实例级别的，记录了所有数据库和表的变更。

解决方案： 1. 启用 Source 复用：通过复用 CDC Source 减少重复读取 Binlog 的开销。 2. 优化网络传输：确保网络环境稳定，并检查是否有其他不必要的流量占用带宽。

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

如果增量阶段读取的 timestamp 字段时区与预期不符，可能是由于 server-time-zone 参数未正确配置。

解决方案： 在 Flink CDC 配置中明确指定时区。例如：

'server-time-zone' = 'Asia/Shanghai'

确保该参数与 MySQL 服务器的时区一致。

7. Postgres CDC磁盘使用率高，WAL日志不释放

Postgres CDC 只会在 checkpoint 完成时更新 slot 中的 LSN（Log Sequence Number）。如果磁盘使用率过高，可能是 checkpoint 未正常运行或存在未使用的 slot。

解决方案： 1. 检查 Postgres 的 checkpoint 配置，确保其已启用。 2. 删除未使用或延迟的 slot：

SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot('slot_name');

8. DECIMAL类型数据精度超出范围

当 Postgres CDC 同步 DECIMAL 类型数据时，如果精度超出声明范围，数据会被处理为 NULL。

解决方案： 通过以下配置将 DECIMAL 数据以字符串形式处理：

'debezium.decimal.handling.mode' = 'string'

这样可以避免精度丢失问题。

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

此问题通常是由于 Debezium 无法解析某些表的 schema 导致的。

解决方案： 1. 避免使用 'debezium.snapshot.mode'='never'，改为：

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

1. 检查日志中具体的 schema 解析错误，例如 DEFAULT (now())，并根据提示调整表结构。

10. 报错：The "before" field of UPDATE/DELETE message is null

此问题通常发生在 Postgres 表的 REPLICA IDENTITY 设置不为 FULL 时。

解决方案： 执行以下 SQL 命令，将表的 REPLICA IDENTITY 设置为 FULL：

ALTER TABLE yourTableName REPLICA IDENTITY FULL;

如果问题仍然存在，可以尝试添加以下参数：

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

总结

以上是针对 Flink CDC 常见问题的详细解决方案。请根据具体场景选择合适的解决方法。如果问题仍未解决，建议进一步检查日志信息或联系技术支持团队获取帮助。