TiCDC是什么？
TICDC 是一款 TiDB 增量数据同步工具，通过拉取上游 TiKV 的数据变更日志，TiCDC 可以将数据解析为有序的行级变更数据输出到下游。
TiCDC 提供了以下核心能力：
- 提供 TiDB -> TiDB 之间数据容灾复制的能力，实现秒级别 RPO 和分钟级别 RTO
- 提供 TiDB 之间双向复制的能力，支持通过 TiCDC 构建多写多活的 TiDB 集群
- 提供 TiDB -> MySQL（或其他兼容 MySQL 协议的数据库）的低延迟的增量数据同步能力
- 提供 TiDB -> Kafka 增量数据同步能力，推荐的数据格式包含Canal-JSON，Avro，Debezium 等
- 提供 TiDB -> 存储服务（如：Amazon S3、GCS、Azure Blob Storage 和 NFS）增量数据同步能力
- 提供表级别数据同步能力，支持同步过程中过滤数据库、表、DML、DDL 的能力
- 高可用架构，无单点故障；支持动态添加、删除 TiCDC 节点
- 支持通过 Open API 进行集群管理，包括查询任务状态；动态修改任务配置；动态创建、删除任务等
聊聊运行原理
TiCDC 作为 TiDB 的增量数据同步工具，通过 PD 内部的 etcd 实现高可用，通过多个 TiCDC 进程获取 TiKV 节点上的数据改变，在内部进行排序、合并等处理之后，通过多个同步任务 (Changefeed)，同时向多个下游系统进行数据同步。
在以上架构图中：
- TiKV Server：代表 TiDB 集群中的 TiKV 节点，当数据发生改变时 TiKV 节点会主动将发生的数据改变以变更日志（KV change logs，简称 change logs）的方式发送给 TiCDC 节点。当然，当 TiCDC 节点发现收到的 change logs 并不是连续的，也会主动发起请求，获得需要的 change logs。
- TiCDC：代表运行了 TiCDC 进程的各个节点。每个节点都运行一个 TiCDC 进程，每个进程会从 TiKV 节点中拉取一个或者多个表中的数据改变，并通过 Sink 模块同步到下游系统。
- PD：代表 TiDB 集群中的调度模块，负责集群数据的事实调度，这个模块通常是由 3 个 PD 节点构成的，内部通过 etcd 集群来实现选举等高可用相关的能力。 TiCDC 集群使用了 PD 集群内置的 etcd 集群来保存自己的元数据信息，例如：节点的状态信息，changefeed 配置信息等。
另外，从上面的架构图中也可以看到，目前 TiCDC 支持将数据同步到 TiDB、MySQL 数据库、Kafka 以及存储服务等。
聊聊最佳场景
TiCDC的最佳场景主要集中在数据同步与容灾方面，以下是具体的几个最佳场景：
1. 数据库灾备
- 同构数据库灾备：TiCDC 可用于实现 TiDB 集群间的数据容灾方案，保证在灾难发生时主备集群数据的最终一致性。这对于需要高可用性和数据持久性的应用场景至关重要。
- 跨区域数据高可用：通过 TiCDC，可以在不同的地理区域部署 TiDB 集群，并利用 TiCDC 实现跨区域的数据同步，从而提高数据的高可用性和容灾能力。
2. 数据集成
- 实时数据同步到异构系统：TiCDC 支持将 TiDB 的数据实时同步到各种异构系统，如 MySQL、Kafka、S3、GCS、NFS 等。这为监控、缓存、全文索引、数据分析等场景提供了强大的数据源支持。
- 增量数据抽取：在数仓ETL场景中，TiCDC 可以用于实现增量数据的抽取，避免全量数据抽取带来的高负载和资源消耗问题。这对于需要高效处理大量数据的业务场景尤为重要。
3. 流处理与实时分析
- 支持流处理框架：TiCDC 可以将 TiDB 的数据变更实时同步到 Kafka 等消息队列中，进而支持 Flink 等流处理框架进行实时数据处理和分析。这为需要快速响应数据变化的业务场景提供了强大的技术支持。
4. 业务连续性保障
- 同城双中心需求：在同城双中心部署场景下，TiCDC 可以实现两个 TiDB 集群之间的数据同步，确保在主集群发生故障时备用集群能够立即接管服务，保障业务的连续性。
5. 多写多活场景
- TiDB之间的双向复制：TiCDC 支持 TiDB 之间的双向复制，可以实现多写多活的 TiDB 集群架构。这对于需要高可用性和灵活扩展性的分布式数据库应用场景具有重要意义。
聊聊最佳实践
TiCDC 的最佳实践涉及多个方面，包括部署、配置、监控以及故障处理等。以下是一些关键的最佳实践建议：
1. 部署与配置
- 合理规划资源：根据业务需求和预期的数据同步量，合理规划 TiCDC 节点的数量和资源分配，确保系统在高负载下仍能稳定运行。
- 部署位置选择：对于 TiCDC 节点的部署位置，建议根据业务场景和网络环境进行选择。一般来说，如果上下游集群之间的网络延迟较大，推荐将 TiCDC 部署在下游集群所在区域以减少延迟。
- 配置优化：针对 TiCDC 的配置参数进行调优，如 Sorter 算子内存参数（per-table-memory-quota）和 Sink 同步并发数（worker-count）等，以提高同步性能。同时，注意合理配置 gc-ttl 参数以防止数据被过早清理。
2. 数据同步
- 初始化数据同步：对于需要全量数据同步的场景，可以使用 Dumpling 和 TiDB Lightning 等工具进行初始化数据导出和导入，然后再启动 TiCDC 进行增量数据同步。
- 表级同步控制：利用 TiCDC 的表级同步能力，可以精细控制需要同步的数据库和表，减少不必要的数据传输和存储开销。
- 监控同步延迟：定期监控 TiCDC 同步任务的延迟情况，及时发现并解决延迟问题。对于延迟较高的同步任务，可以考虑增加 TiCDC 节点或优化网络配置。
3. 监控与故障处理
- 使用监控工具：利用 Grafana 等监控工具对 TiCDC 的运行状态进行实时监控，包括同步任务的延迟、错误日志等信息。
- 故障排查与恢复：当 TiCDC 出现故障时，及时排查故障原因并进行恢复。对于无法自动恢复的故障，可以手动重启同步任务或调整配置参数。
- 日志分析：定期分析 TiCDC 的日志文件，了解系统的运行状况和潜在问题。对于频繁出现的错误或警告信息，应及时处理以防止问题扩大。
4. 性能调优
- 内存和并发优化：针对 TiCDC 的内存使用和并发处理能力进行优化，如调整 Sorter 算子的内存限制和 Sink 同步的并发数等，以提高同步性能。
- 网络优化：优化 TiCDC 节点与上下游集群之间的网络连接，减少网络延迟和丢包率，提高数据传输效率。
- 定期评估与调整：根据业务发展和数据量的变化，定期评估 TiCDC 的性能和资源使用情况，并适时调整配置参数以优化系统性能。
聊聊问题诊断
1.同步状态问题
检查 TiCDC 同步任务的状态，可以通过以下方式进行：
- 使用 cdc cli 工具：通过 cdc cli changefeed list 和 cdc cli changefeed query 命令查看同步任务的状态信息。如果任务状态为 stopped，则表示同步中断，此时可以通过 error项查看具体的错误信息。
- 查看 Grafana 监控：通过 Grafana 检查同步任务的 changefeed checkpoint 监控项。注意选择正确的 changefeed id。如果该值不发生变化或者查看 checkpoint lag 是否不断增大，可能同步任务出现中断。同时，检查 exit error count 监控项，该监控项大于 0 代表同步任务出现错误。
2.同步延迟问题
负责监听 kv change event，经过 pipeline 处理后发送到下游，首先我们需要大概了解这几个时间点： Checkpoint-TS：表示在此 TS 前的数据已经全部同步到下游，checkpoint-ts 表示一个闭区间的上界。 Resolved-TS：表示在此 TS 前的 TiKV 已经提交的事务数据都已经收到，即可以还原为完整事务，resolved-ts 表示一个闭区间的上界。 Start-TS: 表示从 TiKV 拉取数据的起点，TiKV 将此参数视为表示一个开区间的下界。 如果发生同步卡顿或者延迟可以根据TiKV resolved TS lag、Puller resolved TS lag、Global resolved TS lag和checkpoint lag判断瓶颈并快速确认问题的具体位置。
聊聊常见问题
1.大事务
问题描述：
在V6.2之前的版本，TiCDC对大事务支持较差。在遇到大事务时经常会出现同步卡住的情况。在v6.2开始TiCDC会自动拆分大事务。可通过sink uri参数控制
transaction-atomicity：指定事务的原子性级别（可选，默认值为 none）。当该值为 table 时 TiCDC 保证单表事务的原子性，当该值为 none 时 TiCDC 会拆分单表事务。
监控：
大事务确认 dashboard ->日志搜索 “BIG_TXN”
grafana -> TiDB -> Transaction Write KV NUM
2.上游TiDB OOM导致残留锁
问题描述：
TiDB服务器发生OOM时，系统可能会尝试通过杀死一些进程来释放内存。在这个过程中，正在执行的SQL语句或事务可能会被中断，导致一些锁（如乐观锁或悲观锁）未能正常释放。如果TiDB服务器OOM导致锁未释放，这些锁可能会阻塞TiKV节点中的resolve lock过程，进而影响Resolved TS的推进，可以通过手动解锁的方式进行释放。
监控：
可以通过Grafana监控查看监控延迟TiKV -> Resolved-TS
3.上游PD/TiKV异常
问题描述：
上游PD/TiKV 节点 crash 或重启， TiKV 节点上的 region leader 没有在停机之前迁移走，TiCDC 会重建这些 region 的链接并且进行同步任务表初始化
监控：
可以通过Grafana监控查看监控延迟TiCDC -> TiKV -> Min resolved ts，查看是否正常推进
4.磁盘性能差影响Disk排序慢
问题描述：
TiCDC在同步数据过程中，涉及到数据的读取、排序、转换和写入等多个环节，其中排序是确保数据一致性和有序性的关键步骤之一。当磁盘性能不佳时，Disk排序的速度会受到影响，进而增加TiCDC的同步延迟
监控：
可以通过监控查看TiCDC机器磁盘的IO效率，也可以监控Global resolve TS的效率。
