随着金融行业发展，金融机构将多个业务系统整合到一套分布式数据库集群中。TiDB通过多租户资源管控和容灾技术，帮助金融机构实现高效业务整合和容灾能力。TiCDC工具用于跨区域数据同步。实际测试验证了基于TiDB的资源管控和TiCDC的多业务融合容灾方案的可行性。

本文介绍了商业银行如何利用TiCDC Syncpoint功能，在TiDB平台上构建一体化架构，优化零售资格业务系统，解决数据分布复杂性和跨库关联查询的挑战，提升数据处理效率和应用性能，确保实时交易的快速响应和数据分析处理的计算资源需求。

TiCDC的Scheduler模块由Coordinator和Agent两部分组成，它们使用两阶段调度机制实现表调度任务，以减少挪动表过程耗时，降低对同步延迟的影响。Coordinator维护Capture的状态，ReplicationSet跟踪一张表在多个Capture上的表同步单元的状态，并且根据收到的Checkpoint和ResolvedTs保证二者均不会退。通过上述内容，读者可以对TiCDC的Scheduler模块有一个基本的了解。

以上就是本文的全部内容。TiCDC Server 启动，创建 Changefeed 和 ETCD 的交互过程。EtcdWorker 如何读取 ETCD 数据并且驱动 Owner 和 Processor Manager 运行。TiCDC Owner 的竞选和切换过程。下一次我们将向大家介绍 TiCDC Changefeed 内部的 Scheduler 模块的工作原理。

作为 TiDB 版本 6 的第二个长期支持版，TiDB 6.5 已经发布。我们希望借助这个版本为更多用户提供更易用且更成熟的企业级数据库。更详细的变更情况请参阅。欢迎各位和我们一起开启新的奇妙旅程。

我们需要定义完整是什么。在这里，“完整”的主体是 TiDB 中的事务，我们知道 TiDB 的事务会有两个写入事件，第一个是 prewrite，第二是 commit 或者 rollback。同时，TiDB 事务可能会涉及多个 key，这些有可能分布在不同的 region 上。所以，我们说“完整”地捕捉一个事务需要捕捉它涉及的所有的 key和所有的写入事件。上图描绘了一个涉及了三个 key...

这一次 TiCDC 阅读系列文章将会从源码层面来讲解 TiCDC 的基本原理，希望能够帮助读者深入地了解 TiCDC。本篇文章是这一系列文章的第一期，主要叙述了 TiCDC 的目的、架构和数据同步链路，旨在让读者能够初步了解 TiCDC，为阅读其他源码阅读文章起到一个引子的作用。