Switching the Owner Node in TiCDC?

This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: ticdc 的 owner 节点切换?

| username: ShawnYan

[TiDB Usage Environment] Production Environment / Testing / PoC
[TiDB Version]
[Reproduction Path] What operations were performed when the issue occurred
[Encountered Issue: Issue Phenomenon and Impact]
[Resource Configuration]
[Attachments: Screenshots / Logs / Monitoring]

TiCDC can evict the owner node and re-elect a new owner.

The following request will evict the current TiCDC owner node and trigger a new round of elections to generate a new owner node.

curl -X POST

However, is it possible to designate a specific server’s CDC node as the new owner?

Or from another perspective, can a specific CDC node be designated to not participate in the election?

| username: 像风一样的男子 | Original post link

You can’t specify it. Evicting the current owner node requires the remaining nodes to hold an election, which reflects the principle of democracy. Pre-determining it would be unfair.

| username: Fly-bird | Original post link

The system automatically designates it, individuals cannot participate in the election.

| username: 大飞哥online | Original post link

You can’t manually specify it, you can only switch. You can switch several times to get to the place you want :face_with_peeking_eye:

| username: 随缘天空 | Original post link

It is not supported. CDC is a distributed system that will automatically select a CDC node as the owner. Try restarting multiple times to see if it can switch the owner.

| username: TiDBer_小阿飞 | Original post link

A TiCDC cluster can have multiple TiCDC nodes, each running a campaignOwner thread responsible for competing for the Owner role. If a node successfully wins the election, it assumes the Owner’s responsibilities. Only one node in the cluster will win the election and execute the Owner’s logic, while the threads on other nodes will be blocked in the Owner election process.

The TiCDC Owner election process is implemented based on ETCD Election. After each Capture starts, it creates an ETCD Session, then uses this Session to call the NewElection method to create a campaign for the Owner Key, and then calls Election.Campaign to start the election. The basic related code process is as follows:

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

You can use the Capture.Run method as an entry point to browse this part of the code flow and deepen your understanding of the process.

In a real cluster operation, multiple TiCDC nodes come online one after another and start competing for the Owner role at different times. The instance that first writes the Owner Key into ETCD will become the Owner.

For example:
TiCDC-0 writes the Owner Key at time t=1 and will become the Owner. If it encounters a failure and relinquishes its Ownership during subsequent operations, TiCDC-1 will become the new Owner node. The old Owner node will come back online, call the method to re-compete for the Owner role, and the cycle repeats.

| username: 喵父666 | Original post link

It’s not possible.

| username: 喵父666 | Original post link

The underlying layer is not supported.

| username: ShawnYan | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.