TiCDC 新架构

从 TiCDC v8.5.4-release.1 版本起，TiCDC 引入新架构，显著提升了实时数据复制的性能、可扩展性与稳定性，同时降低了资源成本。

新架构在完全兼容 TiCDC 老架构的配置项、使用方式和 API 的基础上，对 TiCDC 核心组件与数据处理流程进行了重构与优化，具有以下优势：

• 更高的单节点性能：单节点可支持最多 50 万张表的同步任务，宽表场景下单节点同步流量最高可达 190 MiB/s。
• 更强的扩展能力：集群同步能力接近线性扩展，单集群可扩展至超过 100 个节点，支持超 1 万个 Changefeed；单个 Changefeed 可支持百万级表的同步任务。
• 更高的稳定性：在高流量、频繁 DDL 操作及集群扩缩容等场景下，Changefeed 的延迟更低且更加稳定。通过资源隔离和优先级调度，减少了多个 Changefeed 任务之间的相互干扰。
• 更低的资源成本：通过改进资源利用率，减少冗余开销。在典型场景下，CPU 和内存等资源的使用量降低高达 50%。

架构设计

TiCDC 新架构由 Log Service 和 Downstream Adapter 两大核心组件构成。

• Log Service：作为核心数据服务层，Log Service 负责实时拉取上游 TiDB 集群的行变更和 DDL 变更等信息，并将变更数据临时存储在本地磁盘上。此外，它还负责响应 Downstream Adapter 的数据请求，定时将 DML 和 DDL 数据合并排序并推送至 Downstream Adapter。
• Downstream Adapter：作为下游数据同步适配层，Downstream Adapter 负责处理用户发起的 Changefeed 运维操作，调度生成相关同步任务，从 Log Service 获取数据并同步至下游系统。

TiCDC 新架构通过将整体架构拆分成有状态和无状态的两部分，显著提升了系统的可扩展性、可靠性和灵活性。Log Service 作为有状态组件，专注于数据的获取、排序和存储，通过与 Changefeed 业务逻辑的解耦，实现了数据在多个 Changefeed 间的共享，有效提高了资源利用率，降低了系统开销。Downstream Adapter 作为无状态组件，采用轻量级调度机制，支持任务在不同实例间的快速迁移，并根据负载变化灵活调整同步任务的拆分与合并，确保在各种场景下都能实现低延迟的数据同步。

新老架构对比

新架构旨在解决系统规模持续扩展过程中常见的性能瓶颈、稳定性不足及扩展性受限等核心问题。相较于老架构，新架构在以下关键维度实现了显著优化：

新老架构选择

如果你的业务满足以下任一条件，建议从 TiCDC 老架构切换至TiCDC 新架构，以获得更优的性能与稳定性：

• 增量扫描存在性能瓶颈：增量扫描任务长时间无法完成，导致同步延迟持续上升。
• 超高流量场景：Changefeed 总体流量超过 700 MiB/s。
• MySQL Sink 中存在超高流量写入的单表：目标表结构满足有且仅有一个主键或非空唯一键。
• 海量表同步场景：同步的表数量超过 10 万张。
• 高频 DDL 操作引发延迟：频繁执行 DDL 语句导致同步延迟显著上升。

新功能介绍

新架构支持为所有类型的 Sink 启用表级任务拆分。你可以通过在 Changefeed 配置中设置 scheduler.enable-table-across-nodes = true 来启用该功能。

启用后，TiCDC 会自动将满足以下任一条件的表拆分并分发到多个节点并行执行同步，从而提升同步效率与资源利用率：

• 表的 Region 数超过配置的阈值（默认 10000，可通过 scheduler.region-threshold 调整）。
• 表的写入流量超过配置的阈值（默认未开启，可通过 scheduler.write-key-threshold 设置）。

表级任务拆分配置建议

切换至 TiCDC 新架构后，不建议继续使用老架构中的拆表相关配置。在绝大多数场景下，建议先采用新架构的默认配置。仅在存在同步性能瓶颈或调度不均的特殊场景下，再基于默认值进行小幅调整。

在拆表模式下，建议重点关注以下配置项：

• scheduler.region-threshold：默认值为 10000。当表的 Region 数量超过该阈值时，TiCDC 会对该表执行拆分。对于 Region 数量较少但表整体写入流量较高的场景，可以适当降低该值。该参数必须大于或等于 scheduler.region-count-per-span，否则可能导致任务频繁调度，并增加同步延迟。
• scheduler.region-count-per-span：默认值为 100。在 Changefeed 初始化阶段，满足拆分条件的表会按照该参数进行拆分。拆分后，每个子表最多包含 region-count-per-span 个 Region。
• scheduler.write-key-threshold：默认值为 0（表示关闭）。当表的 Sink 写入流量超过该阈值时，TiCDC 会触发拆分。建议保持默认值 0。

Storage Sink 文件名变更和消费说明

从 v8.5.5 起，切换至 TiCDC 新架构并且开启表级任务拆分后，对于 Storage Sink，记录数据变更的文件名格式将从 CDC{num}.{extension} 变更为 CDC_{uuid}_{num}.{extension}，Index 文件名格式将从 CDC.index 变更为 CDC_{uuid}.index。其中，uuid 用于标识表拆分后的子同步任务，num 表示文件序号。

• 数据变更记录路径

  {scheme}://{prefix}/{schema}/{table}/{table-version-separator}/{partition-separator}/{date-separator}/CDC_{uuid}_{num}.{extension}
  

• Index 文件路径

  {scheme}://{prefix}/{schema}/{table}/{table-version-separator}/{partition-separator}/{date-separator}/meta/CDC_{uuid}.index
  

开启表级任务拆分后，在 {schema}/{table}/{table-version-separator}/ 目录下，同一张表可能存在多个 uuid 不同、序号相同的数据文件。例如：

├── metadata
└── test
    ├── tbl_1
    │   ├── 437752935075545091
    │   │   ├── CDC_11_000001.json
    │   │   ├── CDC_11_000002.json
    │   │   ├── CDC_22_000001.json
    │   │   └── meta
    │   │       ├── CDC_11.index
    │   │       └── CDC_22.index
    │   ├── 437752935075546092
    │   │   ├── CDC_33_000001.json
    │   │   ├── CDC_44_000001.json
    │   │   └── meta
    │   │       ├── CDC_33.index
    │   │       └── CDC_44.index

由于多个子同步任务并行写文件，可能会出现某个数据文件尚未完全写入就被下游读取的情况，导致这部分数据未被成功读取。为了避免这种情况，编写下游消费程序时，请按照以下顺序读取数据：

1. 读取各个子同步任务对应的 meta/CDC_{uuid}.index 文件（例如，CDC_11.index），获取当前已经写入完成的文件名（例如，CDC_11_000002.json）。
2. 依次读取与该 Index 文件对应的 uuid 相同，且文件序号小于或等于该文件名中序号的文件（例如，CDC_11_000001.json 和 CDC_11_000002.json）。
3. 从所有子任务的文件中读取 DML 事件后，将 DML 事件按 commit-ts 排序，然后按排序后的顺序在下游处理。

兼容性说明

TiCDC 新架构除以下特殊说明外，其余部分与老架构完全兼容。

DDL 进度表

在 TiCDC 的老架构中，DDL 的同步是完全串行进行的，因此同步进度仅需通过 Changefeed 的 CheckpointTs 来标识。然而，在新架构中，为了提高 DDL 同步效率，TiCDC 会尽可能并行同步不同表的 DDL 变更。为了在下游 MySQL 兼容数据库中准确记录各表的 DDL 同步进度，TiCDC 新架构会在下游数据库中创建一张名为 tidb_cdc.ddl_ts_v1 的表，专门用于存储 Changefeed 的 DDL 同步进度信息。

DDL 同步行为变更

TiCDC 新老架构在 RENAME DDL 的同步行为上有以下差异：

• 互换表名：对于使用中间表名来交换两个表名的 DDL（例如 RENAME TABLE a TO c, b TO a, c TO b;），老架构不支持同步，新架构支持同步。同步时，必须保留所有相互依赖的重命名步骤。
• 表过滤：两种架构均以旧表名是否匹配过滤规则决定是否同步 Rename。旧表名不匹配而新表名匹配时，Changefeed 会报错并停止同步。对于多表 Rename，老架构还要求目标库位于同步范围内；新架构按各个重命名步骤分别判断。例如，当 filter.rules = ['test.t*'] 时，新架构可以同步 RENAME TABLE test.t1 TO ignore.t1, test.t2 TO test.t22;，随后停止同步改名后的 ignore.t1。详情参见 Rename table 类型的 DDL 注意事项。

DDL SQL 文本差异

TiCDC 同步到下游的 DDL SQL 文本不保证与上游原语句或老架构输出逐字一致。新架构会将单表 Rename 统一重建为带完整库表名的 RENAME TABLE，并在拆分多表 Rename 和批量建表事件时为每条子语句添加尾部分号。视图、跨库 CREATE TABLE ... LIKE ...、匿名索引和表路由等场景也可能发生 SQL 改写。

如果下游消费者需要解析 DDL SQL，或者升级时需要比较新老架构输出，请参见 DDL SQL 文本的处理。

使用限制

TiCDC 新架构目前暂不支持将大事务拆分为多个批次同步至下游，因此在处理超大事务时仍存在 OOM 风险，请在使用前评估相关影响。

升级指南

TiCDC 新架构仅支持 v7.5.0 或者以上版本的 TiDB 集群，使用之前需要确保 TiDB 集群版本满足该要求。

你可以通过 TiUP 或 TiDB Operator 部署 TiCDC 新架构。

部署启用新架构 TiCDC 的全新 TiDB 集群

cdc_servers:
  - host: 10.0.1.20
    config:
      newarch: true
  - host: 10.0.1.21
    config:
      newarch: true

spec:
  ticdc:
    baseImage: pingcap/ticdc
    version: v8.5.8
    replicas: 3
    config:
      newarch = true

在原有 TiDB 集群中部署启用新架构的 TiCDC 组件

使用指南

在 TiCDC 新架构的节点部署完成后，即可使用相应的命令进行操作。新架构沿用了旧架构的 TiCDC 使用方式，因此无需额外学习新的命令，也无需修改旧架构中使用到的命令。

例如，要在新架构的 TiCDC 节点中创建同步任务，可执行以下命令：

cdc cli changefeed create --server=http://127.0.0.1:8300 --sink-uri="mysql://root:123456@127.0.0.1:3306/" --changefeed-id="simple-replication-task"

若需查询特定同步任务的信息，可执行：

cdc cli changefeed query -s --server=http://127.0.0.1:8300 --changefeed-id=simple-replication-task

更多命令的使用方法和细节，可以参考管理 Changefeed。

监控

TiCDC 新架构的监控面板为 TiCDC-New-Arch。对于 v8.5.4 及以上版本的 TiDB 集群，该监控面板已在集群部署或升级时自动集成到 Grafana 中，无需手动操作。如果你的集群版本低于 v8.5.4，需手动导入 TiCDC 监控指标文件以启用监控。

导入步骤以及各监控指标的详细说明，请参考 TiCDC 新架构监控指标。