本文为 TiCDC 源码解读第四期 - TiCDC Scheduler 工作原理解析 分享的现场 Q&A 整理以及视频回顾、分享资料下载合集。对于本期分享内容有更多想要交流的，也欢迎在本帖下留言。
- 视频回放：TiCDC 源码解读#4 TiCDC Scheduler 工作原理解析_哔哩哔哩_bilibili
- 分享资料下载：TiCDC 源码解读#4 TiCDC Scheduler 工作原理解析.pdf (3.3 MB)
- 文章整理：专栏 - TiCDC 源码解读（4）-- TiCDC Scheduler 工作原理解析 | TiDB 社区
- TiCDC 源码解读全系列详细回顾：【资源汇总】TiCDC 源码解读系列最全资源！！！
本期 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 模块的单元测试覆盖率很高，可以通过运行单元测试的方式，了解内部实现细节。可以参考 tiflow/cdc/scheduler/internal/v3 at v6.4.0 · pingcap/tiflow · GitHub 下所有以 _test.go 结尾的文件。
直播互动获奖用户公示
恭喜以下参与互动的获奖用户～可以获得 100 TiDB 社区积分/题
以下用户可以在2023年1月15日前，添加 微信号：Oneandtwii，回复：您的视频号昵称 + TiDB 社区昵称，即可进行积分兑换
| 序号 | 视频号用户 |
|---|---|
| 1 | 魔幻之翼 |
| 2 | 土豆 |
对于本期分享内容有更多想要交流的，也欢迎在本帖下留言。
