What did you do?
When two TiCDC clusters use cluster-id values with a prefix relationship (e.g., new-arch-for-fs and new-arch-for-fs-index) and share the same PD/etcd, a changefeed created in one cluster becomes visible in the other cluster after it restarts. This occurs because etcd keys are scanned by prefix (/tidb/cdc/<cluster-id>) without a path-segment boundary, so /tidb/ cdc/new-arch-for-fs also matches /tidb/cdc/new-arch-for-fs-index.
- Deploy two TiCDC servers on the same PD/etcd:
- cdc-8505 with --cluster-id new-arch-for-fs-index
- cdc-8510 with --cluster-id new-arch-for-fs
- Confirm initial changefeeds:
tiup cdc:v8.5.4 cli changefeed list --server http://10.2.4.11:8505
tiup cdc:v8.5.4 cli changefeed list --server http://10.2.4.11:8510
- Create a changefeed on the new-arch-for-fs-index cluster:
tiup cdc:v8.5.4 cli changefeed create \
--server http://10.2.4.11:8505 \
--changefeed-id prefix-collision-test \
--sink-uri blackhole://
- Verify it appears only on new-arch-for-fs-index:
tiup cdc:v8.5.4 cli changefeed list --server http://10.2.4.11:8505
- Restart the new-arch-for-fs TiCDC server:
tiup cluster restart ds-test -R cdc --node 10.2.4.11:8510 -y
- After restart, list changefeeds on new-arch-for-fs:
tiup cdc:v8.5.4 cli changefeed list --server http://10.2.4.11:8510
Observed: prefix-collision-test now appears in new-arch-for-fs cluster.
What did you expect to see?
Changefeeds created under new-arch-for-fs-index should never appear in new-arch-for-fs.
What did you see instead?
After restarting new-arch-for-fs, it loads the changefeed created under new-arch-for-fs-index.
Versions of the cluster
Upstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):
(paste TiDB cluster version here)
Upstream TiKV version (execute tikv-server --version):
(paste TiKV version here)
TiCDC version (execute cdc version):
(paste TiCDC version here)
What did you do?
When two TiCDC clusters use cluster-id values with a prefix relationship (e.g.,
new-arch-for-fsandnew-arch-for-fs-index) and share the same PD/etcd, a changefeed created in one cluster becomes visible in the other cluster after it restarts. This occurs because etcd keys are scanned by prefix (/tidb/cdc/<cluster-id>) without a path-segment boundary, so/tidb/ cdc/new-arch-for-fsalso matches/tidb/cdc/new-arch-for-fs-index.Observed: prefix-collision-test now appears in new-arch-for-fs cluster.
What did you expect to see?
Changefeeds created under new-arch-for-fs-index should never appear in new-arch-for-fs.
What did you see instead?
After restarting new-arch-for-fs, it loads the changefeed created under new-arch-for-fs-index.
Versions of the cluster
Upstream TiDB cluster version (execute
SELECT tidb_version();in a MySQL client):(paste TiDB cluster version here)Upstream TiKV version (execute
tikv-server --version):(paste TiKV version here)TiCDC version (execute
cdc version):(paste TiCDC version here)