你好，除了这些运维手段外，flink cdc本身有什么解法吗，比如说增量阶段不用从头开始读binlog，因为其实很多都是重复读到的数据
> 2023年9月20日 21:00，Jiabao Sun <jiabao....@xtransfer.cn.INVALID> 写道： > > Hi, > 生产环境的binlog还是建议至少保留7天，可以提高故障恢复时间容忍度。 > 另外，可以尝试增加snapshot的并行度和资源来提升snapshot速度，snapshot完成后可以从savepoint恢复并减少资源。 > Best, > Jiabao > ------------------------------------------------------------------ > From:jinzhuguang <jinzhuguan...@163.com> > Send Time:2023年9月20日(星期三) 20:56 > To:user-zh <user-zh@flink.apache.org> > Subject:Flink cdc 2.0 历史数据太大，导致log积压怎么解决 > 以mysql > cdc为例，现在的f整体流程是先同步全量数据，再开启增量同步；我看代码目前增量的初始offset选择的是所有全量split的最小的highwatermark。那我如果全量数据很大，TB级别，全量同步可能需要很久，但是binlog又不能删除，这样堆积起来会占用很大的空间，不知道这个问题现在有什么常见的解法吗？
