【Q&A 回顾】TiCDC 源码解读#4 | TiCDC Scheduler 工作原理解析

本文为 TiCDC 源码解读第四期 - TiCDC Scheduler 工作原理解析 分享的现场 Q&A 整理以及视频回顾、分享资料下载合集。对于本期分享内容有更多想要交流的,也欢迎在本帖下留言。

视频回放:https://www.bilibili.com/video/BV1hY411U7Z2/
分享资料下载:https://asktug.com/t/topic/995759

本期 Q&A 回顾

以下是本期 《TiCDC Scheduler 工作原理解析》的 Q&A 回顾:

Q:TiCDC 可以跨大版本升级吗?例如从 5.4 升到 6.4,5.4.0 到 5.4.3?
A:可以跨大版本升级,但是不具备滚动升级能力。

Q:TiDB v6.3 之前 TiCDC 的升级貌似很慢
A:升级过程完成很快,就是节点下线,然后上线。但是会有同步任务重新启动的耗时,在大工作负载的情况下,在节点升级完成之后,会有同步延迟明显上升的过程。

Q:TiCDC 与 DM 的区分是什么呢?
A:TiCDC 主要用于将上游 TiDB 集群的增量数据变更,同步到下游目标节点。TiDB 是数据源。DM 是以 MySQL 为数据源,进行合库合表操作,输入到下游目标 TiDB,TiDB 是数据目的地。

Q:如果上游 TiCDC 和 TiDB 集群彻底挂掉,上游的彻底完全不能访问的情况下,比如机房灾难,有什么方法能再下游判断同步到的位点?
A:有以下几种方案:

  • 如果下游是 MySQL / TiDB,可以使用 sync point 功能获取到之前同步到的 checkpoint。如果下游是 Kafka,可以查看 Topic 中最后写写入的数据的 CommitTs,即为对应的 Checkpoint。
  • 可以考虑使用 TiCDC 提供的 Redo Log 功能,在灾难发生的时候,将数据同步到下游。

Q:针对本期分享,推荐可以一起参考的学习资料有哪些?
A:Scheduler 模块的单元测试覆盖率很高,可以通过运行单元测试的方式,了解内部实现细节。可以参考 https://github.com/pingcap/tiflow/tree/v6.4.0/cdc/scheduler/internal/v3 下所有以 _test.go 结尾的文件。

直播互动获奖用户公示

恭喜以下参与互动的获奖用户~可以获得 100 TiDB 社区积分/题

以下用户可以在2023年1月15日前,添加 微信号:Oneandtwii,回复:您的视频号昵称 + TiDB 社区昵称,即可进行积分兑换

序号 视频号用户
1 魔幻之翼
2 土豆

对于本期分享内容有更多想要交流的,也欢迎在本帖下留言。

@xfworld 恭喜恭喜~

额… :rofl:

可以,说的还挺清晰的。

1 Like