Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aligning TiCDC DDL Handling with TiDB v8.3.0’s enable_fast_create_table Behavior #11816

Closed
wlwilliamx opened this issue Dec 2, 2024 · 2 comments · Fixed by #11836
Closed
Assignees
Labels
affects-8.5 This bug affects the 8.5.x(LTS) versions. area/ticdc Issues or PRs related to TiCDC. severity/major type/bug The issue is confirmed as a bug.

Comments

@wlwilliamx
Copy link
Contributor

wlwilliamx commented Dec 2, 2024

Background

In TiDB versions prior to v8.3.0, when enable_fast_create_table=on, the batch create tables DDL job would transition directly to the JobStateSynced state upon completion, bypassing the JobStateDone state. Moreover, create table DDL jobs would be written directly to the tidb_ddl_history table instead of the tidb_ddl_job table.

As of TiDB v8.3.0, this behavior has been standardized: batch create tables DDL jobs now follow the same lifecycle as other DDL jobs, including transitioning through the JobStateDone state, and are written to the tidb_ddl_job table.

This change allows TiCDC to stop listening to the tidb_ddl_history table, simplifying its architecture and reverting to the implementation prior to the introduction of the enable_fast_create_table feature.

Problem Statement

Previously, TiCDC handled both JobStateDone and JobStateSynced states for create table DDL jobs. This dual handling introduced potential redundancy and complexity, as TiCDC might process the same DDL job twice—once in the JobStateDone state and again in the JobStateSynced state.

This issue became more pronounced after the changes introduced in #11733, where TiCDC would process the same create table DDL job twice, once for the JobStateDone state and again for the JobStateSynced state. The detailed reason for this issue is a long story. In the early implementation of enable_fast_create_table v1 in TiDB, when enable_fast_create_table=on, the CREATE TABLE DDL is only written into the tidb_ddl_history table. Therefore, TiCDC must monitor the tidb_ddl_history table to capture the CREATE TABLE DDL. However, when enable_fast_create_table=off, TiDB cannot guarantee that the commit TS of the DDL written to the tidb_ddl_history table is less than the commit TS of the DMLs related to that table. Consequently, TiCDC must monitor the tidb_ddl_job table to capture the CREATE TABLE DDL, as this table ensures that the commit TS of its DDLs is always in order with the commit TS of the DMLs.

Thus, for the same DDL, when enable_fast_create_table=off, TiCDC will receive it twice—once from the tidb_ddl_job table and once from the tidb_ddl_history table. TiCDC cannot perceive whether enable_fast_create_table is on or off on the upstream TiDB.

Additionally, processing JobStateDone DDL jobs instead of JobStateSynced DDL jobs can significantly reduce latency. The transition of a DDL job from JobStateDone to JobStateSynced in TiDB involves:

  1. Synchronization across all TiDB nodes.
  2. Writing metadata to TiKV.
  3. TiCDC retrieving the JobStateSynced state after TiKV transactions are committed.

This sequence introduces delays that can be avoided if TiCDC processes the JobStateDone state directly.

Finally, TiCDC's reliance on the tidb_ddl_history table for capturing create table DDL changes was necessitated by the enable_fast_create_table=on behavior, where DDL jobs would only be written to tidb_ddl_history in the JobStateSynced state. With TiDB v8.3.0's changes, this is no longer required, and TiCDC can revert to monitoring only the tidb_ddl_job table.

Proposed Solution

Update TiCDC to process only JobStateDone DDL jobs for create table operations, leveraging the new behavior in TiDB v8.3.0. This will:

  1. Simplify the DDL handling logic in TiCDC.
  2. Avoid redundant processing of the same DDL job in multiple states.
  3. Resolve the issue introduced by ddl_puller.go(ticdc): fix DDLs are ignored when schema versions are out of order #11733, where the same create table DDL job is processed twice by TiCDC.
  4. Reduce latency in handling DDL operations, improving the responsiveness of TiCDC.
  5. Remove the need for TiCDC to monitor the tidb_ddl_history table, reverting to the pre-enable_fast_create_table implementation.

Action Items

  1. Update the TiCDC DDL handling logic to rely exclusively on the JobStateDone state for create table operations.
  2. Remove any special handling for JobStateSynced for create table DDL jobs.
  3. Stop monitoring the tidb_ddl_history table in TiCDC.
  4. Test the changes with TiDB to ensure correctness and improved performance.

Impact

This change will:

  • Align TiCDC with TiDB v8.3.0's standardized DDL job lifecycle.
  • Eliminate redundant DDL job processing in TiCDC.
  • Resolve the problem of TiCDC processing the same create table DDL job twice due to ddl_puller.go(ticdc): fix DDLs are ignored when schema versions are out of order #11733.
  • Reduce end-to-end latency for DDL operations, enhancing overall system performance.
  • Simplify TiCDC's architecture by removing its dependency on the tidb_ddl_history table.
@wlwilliamx wlwilliamx changed the title Aligning TiCDC DDL Handling with TiDB v8.3.0’s enable_fast_create_table Behavior Aligning TiCDC DDL Handling with TiDB v8.3.0’s enable_fast_create_table Behavior Dec 2, 2024
@wlwilliamx
Copy link
Contributor Author

related:
ticdc: Support create table ddl only appear in tidb_ddl_history instead of tidb_ddl_job table #10907
ddl(ticdc): support batch create table ddl #11262

@wlwilliamx
Copy link
Contributor Author

/affects 8.5

@asddongmen asddongmen added type/enhancement The issue or PR belongs to an enhancement. affects-8.5 This bug affects the 8.5.x(LTS) versions. type/bug The issue is confirmed as a bug. area/ticdc Issues or PRs related to TiCDC. and removed type/enhancement The issue or PR belongs to an enhancement. labels Dec 6, 2024
ti-chi-bot bot pushed a commit that referenced this issue Dec 20, 2024
ti-chi-bot bot pushed a commit that referenced this issue Dec 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects-8.5 This bug affects the 8.5.x(LTS) versions. area/ticdc Issues or PRs related to TiCDC. severity/major type/bug The issue is confirmed as a bug.
Projects
None yet
3 participants