1、有必要考虑其他方案了，如果是单表存量数据很大，且不说下游sink的问题，单单是snapshot阶段可能耗时过长，如果一旦失败，就只能整体重来(因为此时不能做checkpoint)，任务的成功率就很值得怀疑(当然主要还看存量数据到底有多大)。另外，如果能获取全局锁还好，如果无法获取，则会锁表直到存量数据全部拷贝完毕，基本等于业务down掉。 2、如果只是简单的insert into xxx select xxx，就不用担心，runtime在遇到上下游并行度不一致时，如果有主键会按照主键hash的。
在 2021-06-08 14:05:17，"casel.chen" <casel_c...@126.com> 写道： >flink 1.12的jdbc connector不支持 sink.parallism 参数，是不是说只能和上游cdc >connector保持相同的并行度1？如果是的话，下游sink会有瓶颈，因为表中存有大量的历史数据，将存量数据同步到目标表需要花费不少时间，而新的业务数据也源源不断进来，导致追不上。这要如何解决？ >flink 1.13的jdbc connector新增 sink.parallism 参数，问题是如果增大并行度的话能否确保同一个主键记录发到同一个sink >task呢？SQL正确的写法是什么？
