从内存控制和以后产品发展的话，建议用ticdc，不过 cdc 的版本和咱们集群版本有强相关性，集群版本太低（v4.0.14以下），不是很建议用
内存oom 的问题，有较大改善了，不过大事务，还是会造成延迟问题
ok. 我后续测试一下。这边主要是tidb同步tidb 不知道是否支持整个集群的同步
初始化不行，如果只是说增量同步，没问题的，可以理解 ticdc 是 binlog 的替代方案
ok. 我先测一下
Go 语言有的时候会延迟返回内存给 OS，造成 top 中看到的 RES 内存比实际使用要高，一般应该会在 OS 面临内存压力的时候被回收。
ref: https://github.com/golang/go/issues/38257#issuecomment-609985233
有个问题想请教下，这个drainer为什么会耗费这么大的内存呢，是把事务变更的数据放到内存中没有及时落盘，还是什么情况，大佬有时间的时候给解答下
峰值内存占用高主要是加载 DDL 历史的时候，drainer 没有做分页；所以会一次性把所有 DDL 的历史加载到内存。看日志楼主那边的集群已经有了几百万个历史了……这应该是启动的时候占用内存的主要原因。
大事务导致的内存泄漏主要是 drainer 某个组件内部有一个 slice，那个东西在处理完一个事务之后只是被 truncate 到 0（slice = slice[0:]），这就导致了原先的一些数据无法被正确 GC。
非常感谢大佬的解答，还有一个问题，这个drainer加载的DDL历史仅仅是DDL的语句，还是DDL所做的数据变更呢，主要想了解下这个DDL是以什么形式同步过去的
差不多可以理解成历史执行过的所有 DDL 语句。
1 个赞
好的，明白了，非常感谢大佬
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。