Skip to content

Commit 0e14d1a

Browse files
authored
ddl-introduction: switch the tab of pre-v6.2 info and post-v6.2 info (#19158)
1 parent 3d6f0c2 commit 0e14d1a

File tree

1 file changed

+25
-25
lines changed

1 file changed

+25
-25
lines changed

Diff for: ddl-introduction.md

+25-25
Original file line numberDiff line numberDiff line change
@@ -77,6 +77,31 @@ absent -> delete only -> write only -> write reorg -> public
7777
For users, the newly created index is unavailable before the `public` state.
7878

7979
<SimpleTab>
80+
<div label="Parallel DDL framework starting from v6.2.0">
81+
82+
Before TiDB v6.2.0, because the Owner can only execute one DDL task of the same type (either logical or physical) at a time, which is relatively strict, and affects the user experience.
83+
84+
If there is no dependency between DDL tasks, parallel execution does not affect data correctness and consistency. For example, user A adds an index to the `T1` table, while user B deletes a column from the `T2` table. These two DDL statements can be executed in parallel.
85+
86+
To improve the user experience of DDL execution, starting from v6.2.0, TiDB enables the Owner to determine the relevance of DDL tasks. The logic is as follows:
87+
88+
+ DDL statements to be performed on the same table are mutually blocked.
89+
+ `DROP DATABASE` and DDL statements that affect all objects in the database are mutually blocked.
90+
+ Adding indexes and column type changes on different tables can be executed concurrently.
91+
+ A logical DDL statement must wait for the previous logical DDL statement to be executed before it can be executed.
92+
+ In other cases, DDL can be executed based on the level of availability for concurrent DDL execution.
93+
94+
Specifically, TiDB 6.2.0 has enhanced the DDL execution framework in the following aspects:
95+
96+
+ The DDL Owner can execute DDL tasks in parallel based on the preceding logic.
97+
+ The first-in-first-out issue in the DDL Job queue has been addressed. The DDL Owner no longer selects the first job in the queue, but instead selects the job that can be executed at the current time.
98+
+ The number of workers that handle physical DDL statements has been increased, enabling multiple physical DDL statements to be executed in parallel.
99+
100+
Because all DDL tasks in TiDB are implemented using an online change approach, TiDB can determine the relevance of new DDL jobs through the Owner, and schedule DDL tasks based on this information. This approach enables the distributed database to achieve the same level of DDL concurrency as traditional databases.
101+
102+
The concurrent DDL framework enhances the execution capability of DDL statements in TiDB, making it more compatible with the usage patterns of commercial databases.
103+
104+
</div>
80105
<div label="Online DDL asynchronous change before TiDB v6.2.0">
81106

82107
Before v6.2.0, the process of handling asynchronous schema changes in the TiDB SQL layer is as follows:
@@ -103,31 +128,6 @@ Before TiDB v6.2.0, the DDL execution framework had the following limitations:
103128

104129
These limitations might lead to some "unintended" DDL blocking behavior. For more details, see [SQL FAQ - DDL Execution](https://docs.pingcap.com/tidb/stable/sql-faq#ddl-execution).
105130

106-
</div>
107-
<div label="Parallel DDL framework starting from v6.2.0">
108-
109-
Before TiDB v6.2.0, because the Owner can only execute one DDL task of the same type (either logical or physical) at a time, which is relatively strict, and affects the user experience.
110-
111-
If there is no dependency between DDL tasks, parallel execution does not affect data correctness and consistency. For example, user A adds an index to the `T1` table, while user B deletes a column from the `T2` table. These two DDL statements can be executed in parallel.
112-
113-
To improve the user experience of DDL execution, starting from v6.2.0, TiDB enables the Owner to determine the relevance of DDL tasks. The logic is as follows:
114-
115-
+ DDL statements to be performed on the same table are mutually blocked.
116-
+ `DROP DATABASE` and DDL statements that affect all objects in the database are mutually blocked.
117-
+ Adding indexes and column type changes on different tables can be executed concurrently.
118-
+ A logical DDL statement must wait for the previous logical DDL statement to be executed before it can be executed.
119-
+ In other cases, DDL can be executed based on the level of availability for concurrent DDL execution.
120-
121-
Specifically, TiDB 6.2.0 has enhanced the DDL execution framework in the following aspects:
122-
123-
+ The DDL Owner can execute DDL tasks in parallel based on the preceding logic.
124-
+ The first-in-first-out issue in the DDL Job queue has been addressed. The DDL Owner no longer selects the first job in the queue, but instead selects the job that can be executed at the current time.
125-
+ The number of workers that handle physical DDL statements has been increased, enabling multiple physical DDL statements to be executed in parallel.
126-
127-
Because all DDL tasks in TiDB are implemented using an online change approach, TiDB can determine the relevance of new DDL jobs through the Owner, and schedule DDL tasks based on this information. This approach enables the distributed database to achieve the same level of DDL concurrency as traditional databases.
128-
129-
The concurrent DDL framework enhances the execution capability of DDL statements in TiDB, making it more compatible with the usage patterns of commercial databases.
130-
131131
</div>
132132
</SimpleTab>
133133

0 commit comments

Comments
 (0)