意思是当 有 binlog 就意味着 已经读完了 snapshot
casel.chen 于2023年12月19日周二 16:45写道：
> 我在阅读flink-connector-mysql-cdc项目源码过程中遇到一个不清楚的地方，还请大佬指点，谢谢！
>
>
> MySqlSplitReader类有一段代码如下，注释“(1) Reads binlog split firstly and then read
> snapshot split”这一句话我不理解。
> 为什么要先读binlog split再读snapshot
1、为什么source 默认要从 earliest 开始消费，是为了能够找到或者 补全 update before 数据？ kafka
数据也有清理周期，给我感觉是 如果 state 找不到 就是 insert . 如果下游sink 能做 upsert 处理 比如 hbase 是不是
source 就可以解除这限制
2、翻了下 代码 没找到维护 sate 的源码位置，请指导下 核心类
3、Upsert kafka 作为 source 是否有严格要求 消息生产端必须对 消息进行 分区，使得 相同主键的 数据发送到同一个 kafka
partition.
谢谢。看了相关文章 和邮件列表类似的问题，中心思路都是调大堆外内存。 还是有几个疑问
1、在 flink 1.10 中 在state 不断增长的情况下 是否没办法控制 rocksdb 内存的增长？ 导致 有container 被
kill 的风险。rocksdb 没有当内存不足时就clear 内存刷磁盘的动作？
2、当使用 rocksdbStateBackend 时 如果配置的是 hdfs 路径。rocksdb 是否还会有本地文件生成。在 tm
节点上一直没有找到相关文件。
zhiyezou <1530130...@qq.com> 于2021年2月7日周日 上午9:41写道：
>
谢谢 回答.
是指的这个参数 taskmanager.memory.jvm-overhead 调整吗（微信连接有点问题）？
我看邮件列表很多大佬的回答基本上都是要调大堆外内存。
难道 rocksdb 就申请内存的时候就控制不住上限吗？我的state 是会一直增长，但是我希望rocksDB 内存能在我设置的范围内，不至于被
yarn kill . 这块要能实现吗？
zhiyezou <1530130...@qq.com> 于2021年2月5日周五 下午1:25写道：
> Hi
> 可以先jvm-overhead相关配置，具体原理及参数请参考这篇文章，
>
各位大佬好
rocksDB state 场景下 state 过大 被杀。 有啥好的解决办法？ 为啥在 flink 1.10.1 中
taskmanager.memory.managed.size 限制不住 rocksDB 内存申请？改如何控制上线？
java.lang.Exception: Container
[pid=137231,containerID=container_e118_1611713951789_92045_01_03]
is running beyond physical memory limits. Current usage: 4.1 GB of 4
proccess
并行度为N， start 会开启一个事务 编号proccess 用这个事务 编号
去做预处理(赞一批处理一次，并把这一次处理结果下发，给下游做事务提交)， submit 收到上游批处理的结果 用 同样的事务编号去提交
Congxian Qiu 于2020年8月17日周一 上午10:42写道：
> Hi
> 上游 snapshot 的逻辑和下游收到之前的 notifyCheckpointComplete
> 之间是没有必然联系的，所以这个从理论上是不保证先后顺序的。
> Best,
> Congxian
>
&
各位大佬：
在如下代码中： FCombine 执行snapshot collect 发送数据之后如果不执行sleep 则 FSubmit
在执行 notifyCheckpointComplete 方法时，list 集合 ls 为空。
如果在 FCombine 执行snapshot collect 发送数据之后如果执行sleep，
在执行 notifyCheckpointComplete 方法时 则就可以收到 snapshot collect 发送的数据。
我之前的理解是每个算子在执行完checkpoint 之后 才会把 barrier 广播到下游算子。
