Error creating sync task in main cluster using TiCDC: unknown configuration options in changefeed's config file: cyclic-replication, cyclic-replication.enable, cyclic-replication.replica-id, cyclic-replication.filter-replica-ids, cyclic-replication.sync-d

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

Original topic: 使用ticdc在主库集群创建同步任务时,报错:Error: component TiCDC changefeed’s config file unknown configuration options: cyclic-replication, cyclic-replication.enable, cyclic-replication.replica-id, cyclic-replication.filter-replica-ids, cyclic-replication.sync-ddl

| username: vcdog

【TiDB Usage Environment】Production Environment
【TiDB Version】v6.5.0
【Reproduction Path】Operations performed that led to the issue
【Encountered Issue: Issue Phenomenon and Impact】

# tiup cdc cli changefeed create --pd=http://10.3.xxx.xxx:2379 --sink-uri="mysql://root:xxxxxx@10.3.xxx.227:4000/" --changefeed-id="bj-to-idc-tab1" --sort-engine="unified" --config ./ticdc_sync_to_idc.toml --start-ts='439745457928536072'
tiup is checking updates for component cdc ...
Starting component `cdc`: /root/.tiup/components/cdc/v6.5.0/cdc cli changefeed create --pd=http://10.3.xxx.196:2379 --sink-uri=mysql://root:xxxxxx@10.3.xxx.227:4000/ --changefeed-id=bj-to-idc-tab1 --sort-engine=unified --config ./ticdc_sync_to_idc.toml --start-ts=439745457928536072
Error: component TiCDC changefeed's config file ./ticdc_sync_to_idc.toml contained unknown configuration options: cyclic-replication, cyclic-replication.enable, cyclic-replication.replica-id, cyclic-replication.filter-replica-ids, cyclic-replication.sync-ddl

Based on the above prompt, try removing the cyclic-replication, cyclic-replication.enable, cyclic-replication.replica-id, cyclic-replication.filter-replica-ids, cyclic-replication.sync-ddl configuration options from the configuration file. Then re-execute the create command:

tiup cdc cli changefeed create --pd=http://10.3.xxx.xxx:2379 --sink-uri="mysql://root:xxxxxx@10.3.8.227:4000/" --changefeed-id="bj-to-idc-tab1" --sort-engine="unified" --config ./ticdc_sync_to_idc.toml --start-ts='439745457928536072'
tiup is checking updates for component cdc ...
Starting component `cdc`: /root/.tiup/components/cdc/v6.5.0/cdc cli changefeed create --pd=http://10.3.xxx.196:2379 --sink-uri=mysql://root:xxxxxx@10.3.xxx.227:4000/ --changefeed-id=bj-to-idc-tab1 --sort-engine=unified --config ./ticdc_sync_to_idc.toml --start-ts=439745457928536072

Error: [CDC:ErrSinkURIInvalid]sink uri invalid 'protocol default is incompatible with mysql scheme'

As a result, this time it directly throws an error: Error: [CDC:ErrSinkURIInvalid]sink uri invalid ‘protocol default is incompatible with mysql scheme’
【Resource Configuration】
【Attachments: Screenshots/Logs/Monitoring】

Configuration file:

# Specify whether the database and table names involved in the configuration file are case-sensitive
# This configuration will affect both filter and sink related configurations, default is true
case-sensitive = true

# Whether to output old value, supported since v4.0.5
enable-old-value = false

[filter]
# Filter rules
# Filter rule syntax: https://docs.pingcap.com/zh/tidb/stable/table-filter#表库过滤语法
rules = ['my_db.tb_record_detail']

[mounter]
# Number of mounter threads, used to decode data output from TiKV
worker-num = 16

[sink]
# For MQ type Sinks, event dispatchers can be configured through dispatchers
# Supports four dispatchers: default, ts, rowid, table. The dispatch rules are as follows:
# - default: If there are multiple unique indexes (including primary keys), dispatch in table mode; if there is only one unique index (or primary key), dispatch in rowid mode; if the old value feature is enabled, dispatch in table mode
# - ts: Dispatch events by calculating Hash based on the commitTs of row changes
# - rowid: Dispatch events by calculating Hash based on the selected HandleKey column name and column value
# - table: Dispatch events by calculating Hash based on the schema name and table name of the table
# The matching syntax of matcher is the same as the filter rule syntax
# dispatchers = [
# {matcher = ['test1.*', 'test2.*'], dispatcher = "ts"},
# {matcher = ['test3.*', 'test4.*'], dispatcher = "rowid"},
# ]
# For MQ type Sinks, the message protocol format can be specified
# Currently supports four protocols: default, canal, avro, and maxwell. default is TiCDC Open Protocol
protocol = "default"

[cyclic-replication]
# Whether to enable cyclic replication
enable = false
# The replication ID of the current TiCDC
replica-id = 1
# IDs to be filtered out
filter-replica-ids = [2,3]
# Whether to sync DDL
sync-ddl = true
| username: 裤衩儿飞上天 | Original post link

Reference: TiCDC Changefeed Command Line Parameters and Configuration Parameters | PingCAP Documentation Center

| username: vcdog | Original post link

Currently, the downstream where I am experiencing issues is a TiDB cluster. Does TiDB support canal-json as a downstream?
Previously, when I was using version v5.4.0:

  1. When the downstream was Kafka, the protocol used was canal-json;
  2. When the downstream was TiDB, the protocol used was default.
| username: vcdog | Original post link

Additionally, I want to confirm, in the new version v6.5.0, do we need to specify the CDC service IP and port when creating a task using TiCDC? I saw the documentation on GitHub:

| username: tidb菜鸟一只 | Original post link

Try changing the protocol to canal.

| username: vcdog | Original post link

Error: [CDC:ErrSinkURIInvalid]sink uri invalid 'protocol canal-json is incompatible with mysql scheme'

I referred to the official configuration file, used the latest configuration, changed the protocol to canal-json, and recreated the synchronization task, but the error still occurs.

The latest configuration file is as follows:

Specify whether the database and table names involved in the configuration file are case-sensitive

This configuration will affect both filter and sink related configurations, default is true

case-sensitive = true

Whether to output old value, supported since v4.0.5, default is true since v5.0

enable-old-value = true

Whether to enable Syncpoint feature, supported since v6.3.0, this feature is disabled by default.

Since v6.4.0, using the Syncpoint feature requires the synchronization task to have SYSTEM_VARIABLES_ADMIN or SUPER privileges on the downstream cluster

enable-sync-point = false

The interval for aligning snapshots between upstream and downstream using the Syncpoint feature

The configuration format is h m s, e.g., “1h30m30s”

Default value is 10m, minimum value is 30s

sync-point-interval = “5m”

The retention period for data saved in the downstream table by the Syncpoint feature, data exceeding this time will be cleaned up

The configuration format is h m s, e.g., “24h30m30s”

Default value is 24h

sync-point-retention = “1h”

[mounter]

Number of threads for mounter to decode KV data, default value is 16

worker-num = 16

[filter]

Ignore transactions with specified start_ts

ignore-txn-start-ts = [1, 2]

Filter rules

Filter rule syntax: 表库过滤 | PingCAP 文档中心

rules = [‘my_db.tb_record_detail’]

Event filter rules

Detailed configuration rules for event filters are described in the Event Filter configuration rules below

First event filter rule

#[[filter.event-filters]]
#matcher = [“test.worker”] # matcher is a whitelist, indicating that this filter rule only applies to the worker table in the test database
#ignore-event = [“insert”] # Filter out insert events
#ignore-sql = [“^drop”, “add column”] # Filter out DDLs starting with “drop” or containing “add column”
#ignore-delete-value-expr = “name = ‘john’” # Filter out delete DMLs containing the condition name = ‘john’
#ignore-insert-value-expr = “id >= 100” # Filter out insert DMLs containing the condition id >= 100
#ignore-update-old-value-expr = “age < 18” # Filter out update DMLs with old value age < 18
#ignore-update-new-value-expr = “gender = ‘male’” # Filter out update DMLs with new value gender = ‘male’

Second event filter rule

#[[filter.event-filters]]
#matcher = [“test.fruit”] # This event filter only applies to the test.fruit table
#ignore-event = [“drop table”] # Ignore drop table events
#ignore-sql = [“delete”] # Ignore delete DMLs
#ignore-insert-value-expr = “price > 1000 and origin = ‘no where’” # Ignore insert DMLs containing the conditions price > 1000 and origin = ‘no where’

[sink]

For MQ type sinks, event dispatchers can be configured through dispatchers

Supports two types of event dispatchers: partition and topic (supported since v6.1). Detailed descriptions of both are in the next section.

The matching syntax of matcher is the same as the filter rule syntax, detailed description of matcher matching rules is in the next section.

#dispatchers = [

{matcher = [‘test1.', 'test2.’], topic = “Topic expression 1”, partition = “ts” },

{matcher = [‘test3.', 'test4.’], topic = “Topic expression 2”, partition = “index-value” },

{matcher = [‘test1.', 'test5.’], topic = “Topic expression 3”, partition = “table”},

{matcher = [‘test6.*’], partition = “ts”}

#]

protocol is used to specify the protocol format passed to the downstream

When the downstream type is Kafka, it supports canal-json and avro protocols.

When the downstream type is storage service, it currently only supports canal-json and csv protocols.

protocol = “canal-json”
#protocol = “default”

The following three configuration items are only used in sinks that synchronize to storage services, and do not need to be set in MQ and MySQL type sinks.

Line terminator, used to separate two data change events. Default value is empty, meaning “\r\n” is used as the line terminator.

#terminator = ‘’

Date separator type for file paths. Optional types are none, year, month, and day. Default value is none, meaning no date separator is used. See https://docs.pingcap.com/zh/tidb/dev/ticdc-sink-to-cloud-storage#data-change-records.

#date-separator = ‘none’

Whether to use partition as a separator string. Default value is false, meaning data from different partitions in a table will not be stored in different directories. See https://docs.pingcap.com/zh/tidb/dev/ticdc-sink-to-cloud-storage#data-change-records.

#enable-partition-separator = false

Since v6.5.0, TiCDC supports saving data change records to storage services in CSV format, no need to set in MQ and MySQL type sinks.

#[sink.csv]

Separator between fields. Must be an ASCII character, default value is ,.

#delimiter = ‘,’

Quote character used to wrap fields. Empty value means no quote character is used. Default value is ".

#quote = ‘"’

Character used to represent NULL in CSV columns. Default value is \N.

#null = ‘\N’

Whether to include commit-ts in CSV rows. Default value is false.

#include-commit-ts = false

| username: 裤衩儿飞上天 | Original post link

  1. If the downstream is TiDB or MySQL, this does not need to be configured and will directly use the default.
  2. Regarding the cdc cli parameters, you can check from which specific version the --server option started being used. The usage is as follows:
| username: vcdog | Original post link

Finally succeeded! Thank you very much for your guidance.

What’s strange is that in version v5.4.0, there was this line: protocol = "default", and it could be created successfully.

But in version v6.5.0, you have to comment out these two lines:

#protocol = "canal-json"
#protocol = "default"

Then recreate the synchronization task, and it succeeds.

--sink-uri: The address of the downstream synchronization task needs to be configured in the following format. Currently, the scheme supports mysql, tidb, and kafka.

I want to ask, what is the difference between mysql and tidb here? We have always used mysql before, and it can also synchronize to downstream tidb.

| username: vcdog | Original post link

After creating the CDC synchronization task, when trying to query the data of this synchronized table in the downstream TiDB replica cluster, an error is reported:

mysql> select count(*) from my_db.record_detail1;
ERROR 1105 (HY000): rpc error: code = Unavailable desc = keepalive ping failed to receive ACK within timeout
| username: vcdog | Original post link

After creating this new synchronization task, TiFlash gets stuck at 98% loading progress. Attempting to restart TiFlash triggers the previous bug again, continuously generating new core files.

| username: 裤衩儿飞上天 | Original post link

  1. When the downstream is TiDB or a MySQL-compatible protocol database, use --sink-uri with mysql.
    When the downstream is Kafka, use kafka.
    When the downstream is file storage, configure the path.
    For specific details, refer to the documentation: Synchronize Data to MySQL Compatible Databases | PingCAP Documentation Center
  2. The error in your query is because TiDB is using a proxy on the frontend, and it timed out due to inactivity.
| username: tidb菜鸟一只 | Original post link

Is your cluster status normal?

| username: vcdog | Original post link

Direct queries on the TiDB database instance were performed without using a front-end proxy. I don’t know why this issue occurred. However, after forcibly restarting TiFlash, the query results were normal. Checking the execution plan showed that it used KV and did not use TiFlash.

| username: system | Original post link

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