TiDB TiCDC 变更数据捕获

TiCDC 基本概念

什么是 TiCDC

TiCDC（TiDB Change Data Capture）是 TiDB 生态中的变更数据捕获组件，用于实时捕获 TiKV 中的变更数据，并将这些变更数据以有序、一致的方式输出到下游系统。

TiCDC 的核心功能

实时数据同步：实时捕获 TiDB 中的数据变更，包括插入、更新、删除操作
高可用性：支持集群部署，提供高可用服务
事务一致性：保证下游数据的事务一致性
多下游支持：支持多种下游系统，如 MySQL、Kafka、TiDB、Amazon S3 等
灵活的过滤规则：支持按数据库、表进行数据过滤
DDL 同步：支持同步 DDL 操作
断点续传：支持从断点处恢复同步，避免数据丢失
监控告警：提供完善的监控指标和告警规则

TiCDC 的应用场景

实时数据仓库构建：将 TiDB 数据实时同步到数据仓库
业务数据集成：在多个业务系统间实现数据实时同步
异地灾备：实现跨数据中心的数据灾备
实时数据分析：将变更数据实时发送到流处理系统进行分析
缓存更新：根据数据变更实时更新缓存
审计日志：记录所有数据变更，用于审计和追溯

TiCDC 架构设计

总体架构

核心组件

TiCDC Server

TiCDC Server 是 TiCDC 集群的核心组件，负责：

从 PD 获取 TiKV 集群信息
从 TiKV 捕获变更数据
处理变更数据，保证事务一致性
将变更数据输出到下游系统
提供集群管理和监控接口

Owner

Owner 是 TiCDC Server 中的一个角色，负责：

管理 TiCDC 集群的元数据
协调各个 Processor 的工作
处理 TiCDC 集群的故障转移
管理 Changefeed 的生命周期

Processor

Processor 是 TiCDC Server 中的另一个角色，负责：

从指定的 TiKV 节点捕获变更数据
解析和处理变更数据
将处理后的数据发送到下游系统
维护同步进度

Changefeed

Changefeed 是 TiCDC 中的一个重要概念，代表一个从 TiDB 到下游系统的同步任务，包括：

同步的起始位点
过滤规则
下游配置
同步状态

数据流程

捕获阶段：Processor 从 TiKV 节点的 Raft log 中捕获变更数据
解码阶段：将捕获到的原始数据解码为可读的变更事件
排序阶段：根据事务提交时间对变更事件进行排序
过滤阶段：根据配置的过滤规则过滤不需要的变更事件
输出阶段：将处理后的变更事件输出到下游系统

TiCDC 部署

部署要求

硬件要求

组件	CPU	内存	存储	网络
TiCDC Server	4核及以上	8GB及以上	100GB SSD	10Gbps

软件要求

TiDB 版本：v4.0.0 及以上
TiUP 版本：v1.3.0 及以上（用于部署）
操作系统：Linux（推荐 CentOS 7.3+ 或 Ubuntu 16.04+）

使用 TiUP 部署 TiCDC

1. 准备拓扑文件

在拓扑文件中添加 TiCDC 组件配置：

yaml

cdc_servers:
  - host: 10.0.0.1
    port: 8300
    deploy_dir: /tidb-deploy/cdc-8300
    data_dir: /tidb-data/cdc-8300
    log_dir: /tidb-deploy/cdc-8300/log
  - host: 10.0.0.2
    port: 8300
    deploy_dir: /tidb-deploy/cdc-8300
    data_dir: /tidb-data/cdc-8300
    log_dir: /tidb-deploy/cdc-8300/log
  - host: 10.0.0.3
    port: 8300
    deploy_dir: /tidb-deploy/cdc-8300
    data_dir: /tidb-data/cdc-8300
    log_dir: /tidb-deploy/cdc-8300/log

2. 部署集群

bash

tiup cluster deploy <cluster-name> <tidb-version> <topology-file> --user root -p

3. 启动集群

bash

tiup cluster start <cluster-name>

4. 验证部署

检查 TiCDC 组件状态：

bash

tiup cluster display <cluster-name> | grep cdc

扩容 TiCDC 集群

1. 准备扩容拓扑文件

yaml

cdc_servers:
  - host: 10.0.0.4
    port: 8300
    deploy_dir: /tidb-deploy/cdc-8300
    data_dir: /tidb-data/cdc-8300
    log_dir: /tidb-deploy/cdc-8300/log

2. 执行扩容

bash

tiup cluster scale-out <cluster-name> <scale-out-topology-file>

TiCDC 配置管理

TiCDC Server 配置

主要配置参数

参数	类型	默认值	说明
`addr`	string	"0.0.0.0:8300"	TiCDC Server 监听地址
`advertise-addr`	string	""	TiCDC Server 对外暴露地址
`pd`	string	""	PD 集群地址
`data-dir`	string	"./data"	数据存储目录
`log-file`	string	""	日志文件路径
`log-level`	string	"info"	日志级别
`gc-ttl`	int	86400	GC 安全阈值，单位：秒
`tz`	string	"System"	时区设置
`ca`	string	""	CA 证书路径
`cert`	string	""	客户端证书路径
`key`	string	""	客户端密钥路径

修改配置

使用 TiUP 编辑 TiCDC 配置：

bash

tiup cluster edit-config <cluster-name>

在配置文件中修改 TiCDC 相关参数，然后重启 TiCDC 组件：

bash

tiup cluster restart <cluster-name> -R cdc

Changefeed 配置

基本配置参数

参数	类型	默认值	说明
`sink-uri`	string	""	下游地址
`opts`	map	{}	下游特定选项
`filter-rules`	array	[]	过滤规则
`ignore-txn-start-ts`	array	[]	忽略的事务 ID
`start-ts`	int	0	同步起始位点
`target-ts`	int	0	同步结束位点
`config`	map	{}	高级配置

过滤规则配置

过滤规则支持按数据库和表进行过滤，格式为：

{schema-name}.{table-name}[,{schema-name}.{table-name}]

支持通配符：

*：匹配任意字符
?：匹配单个字符

示例：

json

{
  "filter-rules": [
    "db1.*",
    "db2.table1",
    "db3.tbl_*"
  ]
}

Changefeed 管理

创建 Changefeed

使用 cdc cli 命令创建 Changefeed：

bash

cdc cli changefeed create --pd="${PD_ADDR}" --sink-uri="mysql://root:password@127.0.0.1:3306/" --changefeed-id="simple-replication-task"

查看 Changefeed 状态

bash

cdc cli changefeed list --pd="${PD_ADDR}"
cdc cli changefeed query --pd="${PD_ADDR}" --changefeed-id="simple-replication-task"

暂停 Changefeed

bash

cdc cli changefeed pause --pd="${PD_ADDR}" --changefeed-id="simple-replication-task"

恢复 Changefeed

bash

cdc cli changefeed resume --pd="${PD_ADDR}" --changefeed-id="simple-replication-task"

删除 Changefeed

bash

cdc cli changefeed remove --pd="${PD_ADDR}" --changefeed-id="simple-replication-task"

修改 Changefeed

bash

cdc cli changefeed update --pd="${PD_ADDR}" --changefeed-id="simple-replication-task" --sink-uri="mysql://root:password@127.0.0.1:3307/"

下游系统配置

MySQL 下游

配置示例

bash

cdc cli changefeed create --pd="${PD_ADDR}" --sink-uri="mysql://root:password@127.0.0.1:3306/?max-txn-row=2000&worker-count=4" --changefeed-id="mysql-replication"

主要选项

选项	说明
`max-txn-row`	单个事务最大行数
`worker-count`	并发 worker 数量
`batch-size`	批量提交大小
`enable-old-value`	是否输出旧值
`force-replicate`	是否强制复制
`skip-txn-start-ts`	跳过特定事务

Kafka 下游

配置示例

bash

cdc cli changefeed create --pd="${PD_ADDR}" --sink-uri="kafka://127.0.0.1:9092/cdc-topic?partition-num=3&replication-factor=1&max-message-bytes=67108864" --changefeed-id="kafka-replication"

主要选项

选项	说明
`partition-num`	分区数量
`replication-factor`	副本因子
`max-message-bytes`	最大消息大小
`protocol`	消息协议，支持 `default`、`canal`、`avro`、`maxwell`
`enable-tidb-extension`	是否启用 TiDB 扩展

TiDB 下游

配置示例

bash

cdc cli changefeed create --pd="${PD_ADDR}" --sink-uri="tidb://root:password@127.0.0.1:4000/?max-txn-row=2000&worker-count=4" --changefeed-id="tidb-replication"

主要选项

选项	说明
`max-txn-row`	单个事务最大行数
`worker-count`	并发 worker 数量
`batch-size`	批量提交大小
`enable-old-value`	是否输出旧值

TiCDC 监控与告警

监控指标

TiCDC 提供了丰富的监控指标，主要包括：

核心指标

指标名	说明
`cdc_server_owner_leader_changes`	Owner 领导权变更次数
`cdc_server_processor_count`	Processor 数量
`cdc_server_changefeed_count`	Changefeed 数量
`cdc_processor_checkpoint_ts`	Processor 检查点 TS
`cdc_processor_event_count`	处理的事件数量
`cdc_processor_resolved_ts`	Processor 已解析 TS
`cdc_sink_event_count`	发送到下游的事件数量
`cdc_sink_lag`	下游延迟，单位：毫秒

Kafka 下游指标

指标名	说明
`cdc_kafka_sink_message_count`	发送到 Kafka 的消息数量
`cdc_kafka_sink_batch_size`	Kafka 批量发送大小
`cdc_kafka_sink_batch_duration`	Kafka 批量发送延迟

MySQL 下游指标

指标名	说明
`cdc_mysql_sink_executor_count`	MySQL 执行器数量
`cdc_mysql_sink_retry_count`	MySQL 重试次数
`cdc_mysql_sink_execution_duration`	MySQL 执行延迟

告警规则

关键告警

告警名称	触发条件	级别	说明
`CDCOwnerLeaderChangeFrequent`	`rate(cdc_server_owner_leader_changes[5m]) > 1`	警告	Owner 领导权频繁变更
`CDCProcessorDown`	`cdc_server_processor_count` < expected_count`	严重	Processor 数量不足
`CDCSinkLagTooHigh`	`cdc_sink_lag >` 300000`	严重	下游延迟过高
`CDCChangefeedError`	`cdc_changefeed_error_count > 0`	严重	Changefeed 出现错误
`CDCGCSafePointExceeded`	`cdc_gc_safe_point < tidb_current_ts - gc_ttl`	警告	GC 安全点过期

监控面板

TiCDC 提供了 Grafana 监控面板，包括：

TiCDC 集群概览
Changefeed 详情
Processor 详情
下游延迟监控
错误监控

TiCDC 最佳实践

部署最佳实践

1. 集群规模

建议部署至少 3 个 TiCDC Server 节点，以保证高可用性
根据数据量和同步需求调整 TiCDC Server 数量
每个 TiCDC Server 建议处理不超过 5 万 QPS 的变更数据

2. 硬件选型

CPU：选择多核 CPU，推荐 8 核及以上
内存：根据数据量调整，推荐 16GB 及以上
存储：使用 SSD 存储，推荐 NVMe SSD
网络：使用 10Gbps 网络，确保低延迟

3. 部署位置

建议将 TiCDC 部署在与 TiKV 相同的可用区，减少网络延迟
避免将 TiCDC 与 TiKV 部署在同一台物理机上，减少资源竞争

配置最佳实践

1. GC 安全阈值

bash

# 设置合适的 GC 安全阈值，确保 TiCDC 有足够时间处理变更数据
cdc cli changefeed create --pd="${PD_ADDR}" --sink-uri="mysql://root:password@127.0.0.1:3306/" --config="${CONFIG_FILE}"

配置文件中设置：

json

{
  "gc-ttl": 86400
}

2. 过滤规则

只同步需要的数据库和表，减少数据传输量
使用精确的过滤规则，避免使用过于宽泛的通配符
定期 review 过滤规则，移除不再需要的表

3. 下游配置

根据下游系统的性能调整并发数和批量大小
对于 MySQL 下游，建议将 max-txn-row 设置为 2000-5000
对于 Kafka 下游，根据消息大小调整 max-message-bytes

运维最佳实践

1. 监控告警

配置完善的监控告警规则
关注下游延迟指标，及时发现同步问题
定期检查 Changefeed 状态

2. 备份与恢复

定期备份 TiCDC 的元数据
测试从断点处恢复同步
制定灾难恢复计划

3. 升级管理

遵循 TiDB 升级指南，先升级 PD、TiKV，再升级 TiCDC
在测试环境验证升级流程
采用滚动升级方式，减少对业务的影响

4. 性能优化

对于大规模同步任务，考虑拆分多个 Changefeed
合理调整 TiCDC Server 数量和配置
优化下游系统性能，确保能够处理 TiCDC 发送的数据

常见问题处理

1. 下游延迟过高

可能原因：

下游系统性能不足
TiCDC 配置不当
数据量过大

解决方法：

优化下游系统性能
增加 TiCDC Server 数量
调整下游配置，增加并发数和批量大小
检查网络连接，确保网络带宽充足

2. Changefeed 报错

可能原因：

下游系统不可用
权限不足
数据冲突

解决方法：

检查下游系统状态
验证连接字符串和权限
查看详细日志，定位具体错误
根据错误信息进行修复

3. Processor 频繁重启

可能原因：

TiKV 节点不稳定
网络问题
TiCDC 配置不当

解决方法：

检查 TiKV 节点状态
排查网络问题
调整 TiCDC 配置，增加超时时间

常见问题（FAQ）

Q1: TiCDC 支持同步哪些类型的变更？

A1: TiCDC 支持同步以下类型的变更：

DML 操作：INSERT、UPDATE、DELETE
DDL 操作：CREATE TABLE、ALTER TABLE、DROP TABLE 等
事务操作：保证事务的原子性和一致性

Q2: TiCDC 与 TiDB Binlog 有什么区别？

A2: TiCDC 与 TiDB Binlog 的主要区别：

架构：TiCDC 采用无状态设计，TiDB Binlog 采用主从架构
性能：TiCDC 性能更高，支持更高的 QPS
可用性：TiCDC 支持集群部署，可用性更高
下游支持：TiCDC 支持更多下游系统
DDL 支持：TiCDC 对 DDL 支持更完善

Q3: 如何选择 TiCDC 的起始同步位点？

A3: 可以通过以下方式指定起始同步位点：

使用 --start-ts 参数指定具体的 TS
使用 --start-time 参数指定开始时间
如果不指定，默认从当前时间开始同步

Q4: TiCDC 如何处理 DDL 操作？

A4: TiCDC 处理 DDL 操作的方式：

捕获 DDL 事件
确保 DDL 操作在所有相关 DML 操作之前执行
将 DDL 事件发送到下游系统
下游系统执行 DDL 操作

Q5: 如何监控 TiCDC 的同步延迟？

A5: 可以通过以下方式监控同步延迟：

查看 Grafana 面板中的 cdc_sink_lag 指标
使用 cdc cli changefeed query 命令查看延迟
配置告警规则，当延迟超过阈值时触发告警

Q6: TiCDC 支持跨版本同步吗？

A6: TiCDC 支持跨版本同步，但建议遵循以下原则：

下游 TiDB 版本不低于上游 TiDB 版本
对于跨大版本同步，建议先在测试环境验证
参考官方文档中的版本兼容性矩阵

Q7: 如何暂停和恢复 TiCDC 同步？

A7: 可以使用以下命令暂停和恢复同步：

bash

# 暂停同步
cdc cli changefeed pause --pd="${PD_ADDR}" --changefeed-id="${CHANGFEED_ID}"

# 恢复同步
cdc cli changefeed resume --pd="${PD_ADDR}" --changefeed-id="${CHANGFEED_ID}"

Q8: TiCDC 如何保证数据一致性？

A8: TiCDC 通过以下机制保证数据一致性：

基于 TiKV 的 MVCC 机制，确保读取的是已提交的数据
按照事务提交时间排序，保证事务的顺序性
对事务进行完整处理，保证事务的原子性
断点续传机制，避免数据丢失

Q9: 如何迁移 TiCDC 到新的服务器？

A9: 迁移 TiCDC 到新服务器的步骤：

在新服务器上部署 TiCDC Server
将旧服务器上的 TiCDC Server 从集群中移除
确保新服务器上的 TiCDC Server 正常运行
验证 Changefeed 状态正常

Q10: TiCDC 支持 SSL/TLS 加密吗？

A10: 是的，TiCDC 支持 SSL/TLS 加密：

可以配置 TiCDC Server 使用 SSL/TLS 连接 PD 和 TiKV
可以配置下游连接使用 SSL/TLS 加密
需要提供相应的证书和密钥文件

Q11: 如何调整 TiCDC 的日志级别？

A11: 可以通过以下方式调整日志级别：

在启动时使用 --log-level 参数
修改配置文件中的 log-level 参数
支持的日志级别：debug、info、warn、error

Q12: TiCDC 会影响 TiDB 集群的性能吗？

A12: TiCDC 对 TiDB 集群性能的影响很小：

TiCDC 只读取 TiKV 的 Raft log，不影响 TiKV 的正常写入
可以通过调整 gc-ttl 参数控制对 TiKV 的资源占用
建议监控 TiKV 的性能指标，确保 TiCDC 不会对业务造成明显影响

TiDB TiCDC 变更数据捕获 ​

TiCDC 基本概念 ​

什么是 TiCDC ​

TiCDC 的核心功能 ​

TiCDC 的应用场景 ​

TiCDC 架构设计 ​

总体架构 ​

核心组件 ​

TiCDC Server ​

Owner ​

Processor ​

Changefeed ​

数据流程 ​

TiCDC 部署 ​

部署要求 ​

硬件要求 ​

软件要求 ​

使用 TiUP 部署 TiCDC ​

1. 准备拓扑文件 ​

2. 部署集群 ​

3. 启动集群 ​

4. 验证部署 ​

扩容 TiCDC 集群 ​

1. 准备扩容拓扑文件 ​

2. 执行扩容 ​

TiCDC 配置管理 ​

TiCDC Server 配置 ​

主要配置参数 ​

修改配置 ​

Changefeed 配置 ​

基本配置参数 ​

过滤规则配置 ​

Changefeed 管理 ​

创建 Changefeed ​

查看 Changefeed 状态 ​

暂停 Changefeed ​

恢复 Changefeed ​

删除 Changefeed ​

修改 Changefeed ​

下游系统配置 ​

MySQL 下游 ​

配置示例 ​

主要选项 ​

Kafka 下游 ​

配置示例 ​

主要选项 ​

TiDB 下游 ​

配置示例 ​

主要选项 ​

TiCDC 监控与告警 ​

监控指标 ​

核心指标 ​

Kafka 下游指标 ​

MySQL 下游指标 ​

告警规则 ​

关键告警 ​

监控面板 ​

TiCDC 最佳实践 ​

部署最佳实践 ​

1. 集群规模 ​

2. 硬件选型 ​

3. 部署位置 ​

配置最佳实践 ​

1. GC 安全阈值 ​

2. 过滤规则 ​

3. 下游配置 ​

运维最佳实践 ​

1. 监控告警 ​

2. 备份与恢复 ​

3. 升级管理 ​

4. 性能优化 ​

常见问题处理 ​

1. 下游延迟过高 ​

2. Changefeed 报错 ​

3. Processor 频繁重启 ​

常见问题（FAQ） ​

Q1: TiCDC 支持同步哪些类型的变更？ ​

Q2: TiCDC 与 TiDB Binlog 有什么区别？ ​

Q3: 如何选择 TiCDC 的起始同步位点？ ​

Q4: TiCDC 如何处理 DDL 操作？ ​

TiDB TiCDC 变更数据捕获

TiCDC 基本概念

什么是 TiCDC

TiCDC 的核心功能

TiCDC 的应用场景

TiCDC 架构设计

总体架构

核心组件

TiCDC Server

Owner

Processor

Changefeed

数据流程

TiCDC 部署

部署要求

硬件要求

软件要求

使用 TiUP 部署 TiCDC

1. 准备拓扑文件

2. 部署集群

3. 启动集群

4. 验证部署

扩容 TiCDC 集群

1. 准备扩容拓扑文件

2. 执行扩容

TiCDC 配置管理

TiCDC Server 配置

主要配置参数

修改配置

Changefeed 配置

基本配置参数

过滤规则配置

Changefeed 管理

创建 Changefeed

查看 Changefeed 状态

暂停 Changefeed

恢复 Changefeed

删除 Changefeed

修改 Changefeed

下游系统配置

MySQL 下游

配置示例

主要选项

Kafka 下游

配置示例

主要选项

TiDB 下游

配置示例

主要选项

TiCDC 监控与告警

监控指标

核心指标

Kafka 下游指标

MySQL 下游指标

告警规则

关键告警

监控面板

TiCDC 最佳实践

部署最佳实践

1. 集群规模

2. 硬件选型

3. 部署位置

配置最佳实践

1. GC 安全阈值

2. 过滤规则

3. 下游配置

运维最佳实践

1. 监控告警

2. 备份与恢复

3. 升级管理

4. 性能优化

常见问题处理

1. 下游延迟过高

2. Changefeed 报错

3. Processor 频繁重启

常见问题（FAQ）

Q1: TiCDC 支持同步哪些类型的变更？

Q2: TiCDC 与 TiDB Binlog 有什么区别？

Q3: 如何选择 TiCDC 的起始同步位点？

Q4: TiCDC 如何处理 DDL 操作？