TiCDC 源码阅读(三)TiCDC 集群工作过程解析

内容概要

TiCDC 是一款 TiDB 增量数据同步工具,通过拉取上游 TiKV 的数据变更日志,TiCDC 可以将数据解析为有序的行级变更数据输出到下游。

本文是 TiCDC 源码解读的第三篇,主要内容是讲述 TiCDC 集群的启动及基本工作过程,将从如下几个方面展开:

  1. TiCDC Server 启动过程,以及 Server / Capture / Owner / Processor Manager 概念和关系
  2. TiCDC Changefeed 创建过程
  3. Etcd 在 TiCDC 集群中的作用
  4. Owner 和 Processor Manager 概念介绍,以及 Owner 选举和切换过程
  5. Etcd Worker 在 TiCDC 中的作用

完整视频回顾

启动 TiCDC Server

启动一个 TiCDC Server 时,使用的命令如下,需要传入当前上游 TiDB 集群的 PD 地址。

cdc server --pd=http://127.0.0.1:2379

它会启动一个 TiCDC Server 运行实例,并且向 PD 的 ETCD Server 写入 TiCDC 相关的元数据,具体的 Key 如下:

/tidb/cdc/default/__cdc_meta__/capture/${capture_id}

/tidb/cdc/default/__cdc_meta__/owner/${session_id}

第一个 Key 是 Capture Key,用于注册一个 TiCDC Server 上运行的 Capture 信息,每次启动一个 Capture 时都会写入相应的 Key 和 Value。

第二个 Key 是 Campaign Key,每个 Capture 都会注册这样一个 Key 用于竞选 Owner。第一个写入 Owner Key 的 Capture 将成为 Owner 节点。

Server 启动,经过了解析 Server 启动参数,验证参数合法性,然后创建并且运行 TiCDC Server。Server 运行的过程中,会启动多个运行线程。首先启动一个 Http Server 线程,对外提供 Http OpenAPI 访问能力。其次,会创建一系列运行在 Server 级别的资源,主要作用是辅助 Capture 线程运行。最重要的是创建并且运行 Capture 线程,它是 TiCDC Server 运行的主要功能提供者。

image.png

Capture 运行时,首先会将自己的 Capture Information 投入到 ETCD 中。然后启动两个线程,一个运行 ProcessorManager,负责所有 Processor 的管理工作。另外一个运行 campaignOwner,其内部会负责竞选 Owner,以及运行 Owner 职责。如下所示,TiCDC Server 启动之后,会创建一个 Capture 线程,而 Capture 在运行过程中又会创建 ProcessorManager 和 Owner 两个线程,各自负责不同的工作任务。

image (1).png

创建 TiCDC Changefeed

创建 changefeed 时使用的命令如下:

cdc changefeed create --server=http://127.0.0.1:8300 --sink-uri="blackhole://" --changefeed-id="blackhole-test"

其中的 server 参数标识了一个运行中的 TiCDC 节点,它记录了启动时候的 PD 地址。在创建 changefeed 时,server 会访问该 PD 内的 ETCD Server,写入一个 Changefeed 的元数据信息。

/tidb/cdc/default/default/changefeed/info/${changefeed_id}

/tidb/cdc/default/default/changefeed/status/${changefeed_id}
  • 第一个 Key 标识了一个 Changefeed,包括该 Changefeed 的各种静态元数据信息,比如 changefeed-idsink-uri,以及一些其他标识运行时是为的数据。
  • 第二个 Key 标识了该 Changefeed 的运行时进度,主要是记录了 CheckpointResolvedTs 的推进情况,会不断地周期性地更新。

Etcd 的作用

image (2).png

ETCD 在整个 TiCDC 集群中承担了非常重要的元数据存储功能,它记录了 Capture 和 Changefeed 等重要信息。同时通过不断记录并且更新 Changefeed 的 Checkpoint 和 ResolvedTs,保证 Changefeed 能够稳步向前推进工作。从上图中我们可以知道,Capture 在启动的时候,自行将自己的元数据信息写入到 ETCD 中,在此之后,Changefeed 的创建,暂停,删除等操作,都是经由已经启动的 TiCDC Owner 来执行的,后者负责更新 ETCD。

Owner 选举和切换

一个 TiCDC 集群中可以存在着多个 TiCDC 节点,每个节点上都运行着一个 campaignOwner 线程,负责竞选 Owner,如果竞选成功,则履行 Owner 的工作职责。集群中只有一个节点会竞选成功,然后执行 Owner 的工作逻辑,其他节点上的该线程会阻塞在竞选 Owner 上。

image (3).png

TiCDC Owner 的选举过程是基于 ETCD Election 实现的。每个 Capture 在启动之后,会创建 ETCD Session,然后使用该 Session,调用 NewElection 方法,创建到 Owner Key /tidb/cdc/${ClusterID}/__cdc_meta/owner 的竞选,然后调用 Election.Campaign 开始竞选。基本的相关代码过程如下:

sess, err := concurrency.NewSession(etcdClient, ttl) // ttl is set to 10s
if err != nil {
    return err
}

election := concurrency.NewElection(sess, key) // key is `/tidb/cdc/${ClusterID}/__cdc_meta/owner`

if err := election.Campaign(ctx); err != nil {
    return err
}

...

感兴趣的读者 ,可以通过 Capture.Run 方法作为入口,浏览这部分代码流程,加深对该过程的理解。在真实的集群运行过程中,多个 TiCDC 节点先后上线,在不同的时刻开始竞选 Owner,第一个向 ETCD 中写入 Owner Key 的实例将成为 Owner。如下图所示,TiCDC-0 在 t=1 时刻写入 Owner Key,将会成为 Owner,它在后续运行过程中如果遇到故障辞去了自己的 Ownership,那么 TiCDC-1 将会成为新的 Owner 节点。老旧的 Owner 节点重新上线,调用 Election.Campaign 方法重新竞选 Owner,循环往复。

image (4).png

EtcdWorker 模块

EtcdWorker 是 TiCDC 内部一个非常重要的模块,它主要负责从 ETCD 中读取数据,映射到 TiCDC 内存中,然后驱动 Owner 和 ProcessorManager 运行。在具体的实现中,EtcdWorker 通过调用 ETCD Watch 接口,周期性地获取到所有和 TiCDC 相关的 Key 的变化情况,然后映射到其自身维护的 GlobalReactorState 结构体中,其定义如下所示,其中记录了 Capture,Changefeed,Owner 等信息。

type GlobalReactorState struct {
    ClusterID      string
    Owner          map[string]struct{}
    Captures       map[model.CaptureID]*model.CaptureInfo
    Upstreams      map[model.UpstreamID]*model.UpstreamInfo
    Changefeeds    map[model.ChangeFeedID]*ChangefeedReactorState
    
    ....
}

Owner 和 ProcessorManager 都是一个 Reactor 接口的实现,二者都借助 GlobalReactorState 提供的信息来推进工作进度。具体地,Owner 通过轮询每一个记录在 GlobalReactorState 中的 Changefeed,让每一个 Changefeed 都能够被稳步推进同步状态。同时也负责诸如 Pause / Resume / Remove 等和 Changefeed 的运行状态相关的工作。ProcessorManager 则轮询每一个 Processor,让它们能够及时更新自身的运行状态。

总结

以上就是本文的全部内容。希望读者能够理解如下几个问题:

  • TiCDC Server 启动,创建 Changefeed 和 ETCD 的交互过程。
  • EtcdWorker 如何读取 ETCD 数据并且驱动 Owner 和 Processor Manager 运行。
  • TiCDC Owner 的竞选和切换过程。

下一次我们将向大家介绍 TiCDC Changefeed 内部的 Scheduler 模块的工作原理。


开源分布式关系型数据库 TiDB
TiDB 是一款定位于在线事务处理/在线分析处理( HTAP: Hybrid Transactional/Analytical Processing)的...

PingCAP 是国内开源的新型分布式数据库公司,秉承开源是基础软件的未来这一理念,PingCAP 持续扩大社区...

1.9k 声望
4.9k 粉丝
0 条评论
推荐阅读
PingCAP 成为中国唯一入选 Forrester Wave 数据库厂商,被评为卓越表现者
2022 年 12 月 6 日,国际权威研究机构 Forrester 发布了「Forrester Wave™: Translytical Data Platforms, Q4 2022 」报告,企业级开源分布式数据库厂商 PingCAP 作为中国唯一入围的数据库厂商,首次参评该报告...

PingCAP1阅读 303评论 1

Mysql到TiDB迁移,双写数据库兜底方案
TiDB 作为开源 NewSQL 数据库的典型代表之一,同样支持 SQL,支持事务 ACID 特性。在通讯协议上,TiDB 选择与 MySQL 完全兼容,并尽可能兼容 MySQL 的语法。因此,基于 MySQL 数据库开发的系统,大多数可以平滑迁...

京东云开发者阅读 815

封面图
如何构建企业内的 TiDB 自运维体系
得物 App 从创立之初,关系型数据库一直使用的开源数据库产品 MySQL。和绝大部分互联网公司一样,随着业务高速增长、数据量逐步增多,单实例、单库、单表出现性能瓶颈和存储瓶颈。从选型和架构设计角度来看这很符...

得物技术阅读 687

属于 PingCAP 用户和开发者的 2022 年度记忆
2022 年,我们一起穿越了许多荆棘时刻,面对着前所未有的不确定性。在这些挑战面前,我们发现技术和开发者扮演了重要角色。 技术为我们提供了穿越周期的桥梁,开发者帮助我们更好地应对挑战,解决问题并赋予这个...

PingCAP阅读 577

TiCDC 在大单表场景下的性能优化:我们如何将吞吐量提升 7 倍?
在2023 伊始,我们很高兴向大家宣布,TiDB 6.5 LTS 版本已经发布了。这是 TiDB V6 的第二个长期支持版(上一个是 TiDB 6.1),除了携带了诸多备受期待的新特性,同时也将得到 TiDB 开发社区的长期维护,是推荐企...

PingCAP阅读 566

LiveMe x TiDB丨单表数据量 39 亿条,简化架构新体验
近些年,由于互联网的快速发展以及线上需求的爆发,直播在国内已经成为一个非常成熟的商业模式。在娱乐、教育、办公等场景中涌现出许多优秀的视频直播产品。随着国内市场竞争日益白热化,加之企业出海渐成趋势,...

PingCAP阅读 556

TiDB 首批通过信通院 HTAP 数据库基础能力评测
随着数字经济的快速发展,数据已成为重要生产要素,挖掘数据价值成为了用户的普遍需求。HTAP(混合事务和分析处理)是近年来提出的一种新型的数据库架构,旨在打破事务处理和分析之间界限, 在一份数据上保证事务...

PingCAP阅读 547

PingCAP 是国内开源的新型分布式数据库公司,秉承开源是基础软件的未来这一理念,PingCAP 持续扩大社区...

1.9k 声望
4.9k 粉丝
宣传栏