Flink1.15.4 flinksql CDC设置TTL问题？

看了您的建议后，将flink升级到1.18，flinksql设置ttl后，CDC同步mysql数据到kafka后，任务停止，再从checkpoint恢复增量同步问题已解决。然后又开始测试mongo-cdc同步mongo数据到kafka，还是设置TTL，再从chekcpoint恢复，依然无效，直到增加参数：'scan.incremental.snapshot.enabled' = 'true'后，才能正常从checkpoint恢复后 支持增量数据同步

在Flink SQL中使用table.exec.state.ttl配置项来设置状态的生命周期，这个设置会影响作业中维护的各种状态的存活时间，包括但不限于source reader的状态。当一个状态超过了其TTL（Time To Live）之后，Flink将会清除这些状态。这意味着如果一个作业因为某些原因（例如手动停止）重启后，如果之前的状态已经因为超时被清理，那么作业可能无法从上次离开的地方继续执行，因为它依赖的一些状态信息可能已经丢失。

具体到您的场景，设置了table.exec.state.ttl为48小时，并且在停止任务后尝试通过checkpoint或savepoint恢复作业。理论上，使用checkpoint或savepoint应该能够恢复作业的执行状态并继续增量同步，因为checkpoint/savepoint包含了作业执行的所有必要状态，它们独立于table.exec.state.ttl之外。

但是，如果在使用checkpoint/savepoint恢复作业时仍然看到从头开始同步数据，这可能有几个潜在的原因：

1. Checkpoint/Savepoint 不完整或损坏：确认保存的checkpoint或savepoint是否包含了所有必要的状态信息，有时候这些点可能会因为各种原因（如网络问题、磁盘空间不足等）未能正确完成。

2. 配置冲突或误解：虽然一般情况下table.exec.state.ttl不应该直接影响从checkpoint/savepoint恢复的能力，但可能存在某种配置上的误解或不兼容性，导致系统错误地处理了状态恢复流程。

3. RocksDB 状态后端的特殊行为：使用RocksDB作为状态后端时，如果配置不当或存在已知bug，可能会影响到状态的恢复逻辑，尤其是当涉及到TTL管理和状态清理时。

4. Flink版本特定问题：特定于Flink 1.15.4的bug或未文档化的特性可能导致了这一行为，建议查阅Flink的官方issue跟踪系统看是否有相关的问题报告。

解决此问题的建议步骤：

• 检查和验证Checkpoint/Savepoint：确保用于恢复的checkpoint或savepoint是完整且有效的。
• 查阅官方文档和发行说明：查看Flink 1.15.4的文档和发行说明，确认是否有与table.exec.state.ttl和状态恢复相关的已知问题或注意事项。
• 测试不同的配置组合：尝试在不设置table.exec.state.ttl的情况下恢复作业，看是否能够正常增量同步，以此来进一步定位问题。
• 社区求助：在Flink的用户邮件列表或社区论坛中描述问题，寻求帮助，可能有其他用户遇到过类似的情况并找到了解决方案。
• 升级Flink版本：如果上述方法都无法解决问题，考虑升级到Flink的新版本，看是否修复了潜在的bug。