CDC does not synchronize data

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

Original topic: cdc 不同步数据

| username: HACK

【TiDB Usage Environment】Production Environment or Test Environment or POC
【TiDB Version】
【Encountered Problem】
Cluster Version: 4.0.6
After setting up CDC, data inserted into the upstream table is not found in the downstream query. I don’t know where the problem is.
Below is my configuration process:

  1. Create database and table upstream
    create database cdcdb;
    use cdcdb;

create table test(id int not null primary key, name varchar(100));

  1. Create database and table downstream
    create database cdcdb;
    use cdcdb;

create table test(id int not null primary key, name varchar(100));

  1. Add replication user to downstream database
    mysql> create user ‘root’@‘xxx.xxx.xxx.136’ identified by ‘admin’;
    Query OK, 0 rows affected (0.03 sec)

mysql> grant all on . to ‘root’@‘xxx.xxx.xxx.136’;
Query OK, 0 rows affected (0.02 sec)

Test, can connect from upstream to downstream database!
[tidb@TIDBjsjdsjkxt01 ~]$ /home/tidb/tidb_init/mysql-5.7.26-el7-x86_64/bin/mysql -h xxx.xxx.xxx.128 -uroot -P 4000 -p

  1. Create sync task without configuration file
    [tidb@TIDBjsjdsjkxt01 ~]$ cdc cli changefeed create --pd=http://xxx.xxx.xxx.136:2379 --sink-uri=“tidb://root:admin@xxx.xxx.xxx.128:4000/” --changefeed-id=“cdc2” --sort-engine=“unified”
    [WARN] some tables are not eligible to replicate, model.TableName{model.TableName{Schema:“dbs”, Table:“t4”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“g4”, TableID:0, IsPartition:false}, model.TableName{Schema:“zjp”, Table:“zjps”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“yf10.29”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“t22”, TableID:0, IsPartition:false}, model.TableName{Schema:“gpxtest”, Table:“zhang100”, TableID:0, IsPartition:false}, model.TableName{Schema:“zjp”, Table:“test”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“g6”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“g2”, TableID:0, IsPartition:false}, model.TableName{Schema:“gpxtest”, Table:“t1”, TableID:0, IsPartition:false}, model.TableName{Schema:“gpxtest”, Table:“guo001”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“bbb”, TableID:0, IsPartition:false}, model.TableName{Schema:“zjp”, Table:“seq_test”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“t33”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“t01”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“yftest1”, TableID:0, IsPartition:false}, model.TableName{Schema:“gpxtest”, Table:“guo004”, TableID:0, IsPartition:false}, model.TableName{Schema:“dbs”, Table:“t2”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“t2”, TableID:0, IsPartition:false}, model.TableName{Schema:“gpxtest”, Table:“guo002”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“g5”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“zhang100”, TableID:0, IsPartition:false}, model.TableName{Schema:“zjp”, Table:“time”, TableID:0, IsPartition:false}, model.TableName{Schema:“gpxtest”, Table:“zhang1001”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“yftest”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“ee”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“g3”, TableID:0, IsPartition:false}, model.TableName{Schema:“dbs”, Table:“t3”, TableID:0, IsPartition:false}, model.TableName{Schema:“zjp”, Table:“zhang2”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“t333”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“g7”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“a”, TableID:0, IsPartition:false}, model.TableName{Schema:“gpxtest”, Table:“guo003”, TableID:0, IsPartition:false}, model.TableName{Schema:“zjp”, Table:“t2”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“g1”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“test”, TableID:0, IsPartition:false}, model.TableName{Schema:“dbs”, Table:“t5”, TableID:0, IsPartition:false}, model.TableName{Schema:“zjp”, Table:“seq_zjp”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“backup_status”, TableID:0, IsPartition:false}, model.TableName{Schema:“test”, Table:“zhang”, TableID:0, IsPartition:false}}
    Could you agree to ignore those tables, and continue to replicate [Y/N]
    Y
    Create changefeed successfully!
    ID: cdc2
    Info: {“sink-uri”:“tidb://root:admin@xxx.xxx.xxx.128:4000/”,“opts”:{},“create-time”:“2022-06-22T11:24:42.813427811+08:00”,“start-ts”:434075935120556033,“target-ts”:0,“admin-job-type”:0,“sort-engine”:“unified”,“sort-dir”:“.”,“config”:{“case-sensitive”:true,“enable-old-value”:false,“filter”:{“rules”:[“.”],“ignore-txn-start-ts”:null,“ddl-allow-list”:null},“mounter”:{“worker-num”:16},“sink”:{“dispatchers”:null,“protocol”:“default”},“cyclic-replication”:{“enable”:false,“replica-id”:0,“filter-replica-ids”:null,“id-buckets”:0,“sync-ddl”:false},“scheduler”:{“type”:“table-number”,“polling-time”:-1}},“state”:“normal”,“history”:null,“error”:null}

  2. Query sync status
    [tidb@TIDBjsjdsjkxt01 ~]$ cdc cli changefeed list --pd=http://xxx.xxx.xxx.136:2379
    [
    {
    “id”: “cdc2”,
    “summary”: {
    “state”: “normal”,
    “tso”: 434075935120556033,
    “checkpoint”: “2022-06-22 11:24:42.778”,
    “error”: null
    }
    }
    ]

  3. Insert test data, no data found downstream.

No error information found in the relevant CDC logs, please see the attachment.
cdc.log (9.9 KB)

【Reproduction Path】What operations were performed to cause the problem
【Problem Phenomenon and Impact】

【Attachment】

Please provide the version information of each component, such as cdc/tikv, which can be obtained by executing cdc version/tikv-server --version.

| username: songxuecheng | Original post link

Check if there is an issue with the CDC owner.

| username: HACK | Original post link

Which aspect are you referring to?

| username: songxuecheng | Original post link

cdc cli capture list --pd=http://10.0.10.25:2379 Find the owner node and check the logs.

| username: wfxxh | Original post link

I have also encountered this issue when I was using version 4.0.15. Later, I found out that it was a design problem with CDC requesting PD, which was fixed in version 4.0.16.

| username: xiaohetao | Original post link

Will this issue occur in versions prior to 4.0.16?

| username: ShawnYan | Original post link

There is this log in cdc.log, this table is ignored and will not be synchronized:
[2022/06/22 13:15:45.841 +08:00] [INFO] [owner.go:306] ["ignore known table"] [tid=455] [table=cdcdb.test] [ts=434075935120556033]

Check the changefeed or configuration, has it been synchronized before?

| username: HACK | Original post link

This table has not been synchronized before; it is a newly set up synchronization task.

Comparing the CDC log content:
[2022/06/22 13:15:45.841 +08:00] [WARN] [owner.go:298] [“skip ineligible table”] [tid=287] [table=test.g1]
[2022/06/22 13:15:45.841 +08:00] [WARN] [owner.go:298] [“skip ineligible table”] [tid=363] [table=dbs.t3]
[2022/06/22 13:15:45.841 +08:00] [INFO] [owner.go:306] [“ignore known table”] [tid=455] [table=cdcdb.test] [ts=434075935120556033]

skip ineligible table: This means the table is ignored and not synchronized.
ignore known table: I have seen this information before. Compared to the skip warning information, I thought this was not an issue.

My table has a primary key, so there shouldn’t be a problem, right?

Also, when I created the synchronization task, [WARN] some tables are not eligible to replicate, this prompt did not mention my table.

| username: wakaka | Original post link

It prompted.

| username: wakaka | Original post link

What does your configuration file look like? What is the default behavior if no configuration file is specified?

| username: ShawnYan | Original post link

Could it be that test.test and cdcdb.test are conflicting?

| username: HACK | Original post link

I did not specify a configuration file and directly created a synchronization task via the command line as follows:
cdc cli changefeed create --pd=http://xxx.xxx.xxx.136:2379 --sink-uri=“tidb://root:admin@xxx.xxx.xxx.128:4000/” --changefeed-id=“cdc2” --sort-engine=“unified”

| username: HACK | Original post link

After creating the synchronization task, I created a table in the upstream that does not exist in any database, and this table was not synchronized to the downstream.

| username: HACK | Original post link

Occasionally, the following warning messages appear in the TiKV logs:
[2022/06/23 09:02:23.765 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.765 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.765 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.765 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.765 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.765 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.765 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.773 +08:00] [INFO] [owner.go:1159] [“cleanup stale task”] [captureid=891cda67-f042-4027-a1b5-da80cdd13204] [changefeedid=cdc2]
[2022/06/23 09:02:23.773 +08:00] [WARN] [owner.go:1135] [“task position not found, fallback to use original start ts”] [capture=f292a158-03e5-4b79-a6cc-461076b567a6] [changefeed=cdc2] [“task status”=“{"tables":{"258":{"start-ts":434075935120556033,"mark-table-id":0},"260":{"start-ts":434075935120556033,"mark-table-id":0},"288":{"start-ts":434075935120556033,"mark-table-id":0},"291":{"start-ts":434075935120556033,"mark-table-id":0},"369":{"start-ts":434075935120556033,"mark-table-id":0},"389":{"start-ts":434075935120556033,"mark-table-id":0},"443":{"start-ts":434075935120556033,"mark-table-id":0}},"operation":{"258":{"delete":false,"boundary_ts":434075935120556033,"done":false},"260":{"delete":false,"boundary_ts":434075935120556033,"done":false},"288":{"delete":false,"boundary_ts":434075935120556033,"done":false},"291":{"delete":false,"boundary_ts":434075935120556033,"done":false},"369":{"delete":false,"boundary_ts":434075935120556033,"done":false},"389":{"delete":false,"boundary_ts":434075935120556033,"done":false},"443":{"delete":false,"boundary_ts":434075935120556033,"done":false}},"admin-job-type":1}”]
[2022/06/23 09:02:23.773 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.773 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.773 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.773 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.773 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.773 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.773 +08:00] [WARN] [owner.go:186] [“changefeed not found”] [changefeed=cdc2]
[2022/06/23 09:02:23.781 +08:00] [INFO] [owner.go:1159] [“cleanup stale task”] [captureid=f292a158-03e5-4b79-a6cc-461076b567a6] [changefeedid=cdc2]
[2022/06/23 09:02:23.781 +08:00] [INFO] [owner.go:1196] [“monitoring captures”] [key=/tidb/cdc/capture] [rev=23938946]

| username: HACK | Original post link

Creating a synchronization task using tiup ctl cdc doesn’t work either.
Can someone help me with this issue?

| username: HACK | Original post link

After testing, the conclusions are as follows:
After configuring the CDC synchronization task in the v4.0.6 environment, data synchronization cannot be synchronized to the downstream.
After upgrading the cluster to v4.0.16, data synchronization is normal.

It seems you were right.

| username: system | Original post link

This topic was automatically closed 1 minute after the last reply. No new replies are allowed.