[qiancai]

First-time contributors' checklist

• I've signed the Contributor License Agreement, which is required for the repository owners to accept my contribution.

What is changed, added, or deleted? (Required)

Which TiDB version(s) do your changes apply to? (Required)

Tips for choosing the affected version(s):

By default, CHOOSE MASTER ONLY so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER.

For details, see tips for choosing the affected versions (in Chinese).

• master (the latest development version)
• v9.0 (TiDB 9.0 versions)
• v8.5 (TiDB 8.5 versions)
• v8.1 (TiDB 8.1 versions)
• v7.5 (TiDB 7.5 versions)
• v7.1 (TiDB 7.1 versions)
• v6.5 (TiDB 6.5 versions)

What is the related PR or file link(s)?

• Related code change PR links (if applicable):
• This PR is translated from: cdc: update rename ddl behaviour docs-cn#21993
• Other reference link(s):

AI agent involvement

• The changes in this PR were primarily made by an AI agent on behalf of the PR author.

Do your changes match any of the following descriptions?

• Delete files
• Change aliases
• Need modification after applied to another branch
• Might cause conflicts after applied to another branch

Summary by CodeRabbit

• Documentation
  • Clarified how table renames are handled across both architectures, including filter matching, multi-table rename steps, table swaps, and cases that stop replication.
  • Documented that DDL statements sent to Kafka and Pulsar may be reformatted or reconstructed. Split rename statements may need to be processed in order and are not guaranteed to be atomic.
  • Added details on how rename SQL is rebuilt, including fully qualified names, and documented differences in replication-scope requirements between architectures.

[github-actions]

Auto-sync completed successfully

Source PR: pingcap/docs-cn#21993
Target PR: #24610

English documentation has been updated based on Chinese documentation changes.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign kissmydb for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

• Last reviewed commit: 0d03892
• Latest commit, not reviewed: a399153

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• Resume reviews
• Trigger review

Walkthrough

The TiCDC documentation now describes rename filtering and multi-table rename behavior in both architectures. It also documents how downstream DDL SQL may be reconstructed or split, including delivery format, ordering requirements, and atomicity limitations.

Changes: Rename behavior and output

Layer / File(s)	Summary
Rename filtering and architecture behavior ticdc/ticdc-ddl.md, ticdc/ticdc-architecture.md	The documentation compares filtering rules and outcomes for single- and multi-table renames. It also describes architecture differences and ignore-sql matching.
Multi-table rename output ticdc/ticdc-ddl.md, ticdc/ticdc-architecture.md, ticdc/ticdc-sink-to-kafka.md, ticdc/ticdc-sink-to-pulsar.md	The documentation describes rebuilt or split rename SQL, downstream delivery, semicolons, and requirements for processing related steps in order. It states that split rename statements do not guarantee atomic execution.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Other

Suggested reviewers: oreoxmt

Merge Risk: Low · previous review 0d038

Scope the trailing-semicolon documentation to new-architecture messages so Kafka and Pulsar consumers are not misled about classic output.

Pre-merge checks: 4 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Description check		The description follows the template and identifies the affected versions and source PR, but the required change summary is empty. It does not explain the documentation updates to rename DDL behavior.	Complete the required “What is changed, added, or deleted?” section with a concise summary of the updated rename DDL behavior, affected architectures, and sink documentation.

Passed checks: 4 passed

Check name	Status	Explanation
Title check		The title clearly identifies the main change: updating CDC rename DDL behavior.
Docstring Coverage		No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 0 files. (4 skipped: 4 unsupported.)

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

CodeRabbit Verify

• Run CodeRabbit Verify to test the changes in this pull request.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingcap/docs
• Branch: master
• File: .coderabbit.yaml
• Commit: 46bad36
• Layers: Repository YAML
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 216ecef1-dbfb-4ff2-9289-367fa375d222

Commits

Reviewing files that changed from the base of the PR and between 4a00043 and 0d03892.

Files selected for processing: 4

• ticdc/ticdc-architecture.md
• ticdc/ticdc-ddl.md
• ticdc/ticdc-sink-to-kafka.md
• ticdc/ticdc-sink-to-pulsar.md

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 1 remain after this review.

[coderabbitai]

Minor · Functional Correctness · Quick win

Document the DDL execution-coordination difference.

The translated source includes a separate rule for RENAME execution coordination: the classic architecture waits for the entire changefeed CheckpointTs, while the new architecture coordinates only related tables or partitions and allows unrelated DML to continue. The English bullet list currently documents only table swaps and filtering, so users can misjudge blocking and CheckpointTs behavior during a rename. (github.com)

Add this rule before Table filtering.

As per coding guidelines, preserve existing English source intent and terminology in translated-content workflows.

Proposed replacement

--- "a/ticdc/ticdc-architecture.md"
+++ "b/ticdc/ticdc-architecture.md"
@@ -132,7 +132,9 @@
 TiCDC's new and classic architectures differ in the replication behavior of `RENAME` DDLs as follows:
 
 - **Swapping table names**: For DDLs that use an intermediate table name to swap two table names (for example, `RENAME TABLE a TO c, b TO a, c TO b;`), the classic architecture does not support replication, while the new architecture does. During replication, all interdependent renaming steps must be preserved.
+- **Execution coordination**: In the classic architecture, TiCDC waits for the entire changefeed's `CheckpointTs` to reach the DDL execution point before executing a `RENAME` DDL. In the new architecture, TiCDC coordinates only the participating tables or partitions and related DDL scheduling tasks, so DML for unrelated tables can continue. The global `CheckpointTs` still depends on the slowest replication progress and is not guaranteed to advance continuously while the rename waits.
+
 - **Table filtering**: In both architectures, whether to replicate a `RENAME` statement is determined by whether the old table name matches the filter rule. If the old table name does not match but the new table name does, the changefeed reports an error and stops replicating. For multi-table `RENAME`, the classic architecture also requires the target database to be within the replication scope, while the new architecture evaluates each renaming step separately. For example, when `filter.rules = ['test.t*']`, the new architecture can replicate `RENAME TABLE test.t1 TO ignore.t1, test.t2 TO test.t22;` and then stop replicating the renamed `ignore.t1`. For more information, see [Considerations for `RENAME TABLE` DDLs](/ticdc/ticdc-ddl.md#ddl-replication-considerations-for-renaming-tables).
 
 ### Differences in DDL SQL text
 

Committable suggestion

IMPORTANT
Review the replacement and indentation, then test before committing.

Suggested change

	- **Table filtering**: In both architectures, whether to replicate a `RENAME` statement is determined by whether the old table name matches the filter rule. If the old table name does not match but the new table name does, the changefeed reports an error and stops replicating. For multi-table `RENAME`, the classic architecture also requires the target database to be within the replication scope, while the new architecture evaluates each renaming step separately. For example, when `filter.rules = ['test.t*']`, the new architecture can replicate `RENAME TABLE test.t1 TO ignore.t1, test.t2 TO test.t22;` and then stop replicating the renamed `ignore.t1`. For more information, see [Considerations for `RENAME TABLE` DDLs](/ticdc/ticdc-ddl.md#ddl-replication-considerations-for-renaming-tables).
	- **Execution coordination**: In the classic architecture, TiCDC waits for the entire changefeed's `CheckpointTs` to reach the DDL execution point before executing a `RENAME` DDL. In the new architecture, TiCDC coordinates only the participating tables or partitions and related DDL scheduling tasks, so DML for unrelated tables can continue. The global `CheckpointTs` still depends on the slowest replication progress and is not guaranteed to advance continuously while the rename waits.
	- **Table filtering**: In both architectures, whether to replicate a `RENAME` statement is determined by whether the old table name matches the filter rule. If the old table name does not match but the new table name does, the changefeed reports an error and stops replicating. For multi-table `RENAME`, the classic architecture also requires the target database to be within the replication scope, while the new architecture evaluates each renaming step separately. For example, when `filter.rules = ['test.t*']`, the new architecture can replicate `RENAME TABLE test.t1 TO ignore.t1, test.t2 TO test.t22;` and then stop replicating the renamed `ignore.t1`. For more information, see [Considerations for `RENAME TABLE` DDLs](/ticdc/ticdc-ddl.md#ddl-replication-considerations-for-renaming-tables).

Tools

LanguageTool

[style] ~135-~135: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...op replicating the renamed ignore.t1. For more information, see [Considerations f...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)

Source: Coding guidelines