Issues Related to DDL

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

Original topic: 关于DDL的相关问题

| username: TiDBer_U58GZgGJ

The completed DDL jobs will be placed in the tidb_ddl_history table. When will the data in this table be cleaned up? Can any internal developers answer this? Thank you.

| username: shigp_TIDBER | Original post link

First to comment, looking forward to an official response.

| username: 连连看db | Original post link

It should not be automatically deleted.

| username: TiDBer_QYr0vohO | Original post link

No, it won’t.

| username: TiDBer_QG3KhxYr | Original post link

Currently, there is no deletion mechanism for records in tidb_ddl_history.

| username: TiDBer_U58GZgGJ | Original post link

Wouldn’t that take up more and more disk space?

| username: yytest | Original post link

Indeed, the 101 course and official documentation have not mentioned it. An official explanation is needed.

| username: TIDB-Learner | Original post link

The tidb_ddl_history you mentioned is a table in the MySQL database. This is persistent data and is generally not actively deleted. The DDL history of the queue definitely has a deletion mechanism, such as after persistence… The specific implementation needs to be studied in depth.

Job: Each individual DDL operation can be considered a job. When a DDL operation starts, it is encapsulated into a job and placed in the job queue. Once the operation is completed, the job is removed from the job queue and stored in the history job queue for easy viewing of historical jobs.
Worker: Each node has a worker to process jobs.
Owner: Only one node’s worker in the entire system can be elected as the owner. Any node can be elected to this role. Once elected as the owner, the worker has the right to process jobs. The owner role has a term, and the owner’s information is stored in the KV layer. Workers periodically retrieve the owner information from the KV layer. If the ownerID is empty or the current owner has exceeded its term, the worker can attempt to update the owner information in the KV layer (setting the ownerID to its own workerID). If the update is successful, that worker becomes the owner. This ensures that only one node in the entire system is handling schema changes at any given time.

| username: TiDBer_RjzUpGDL | Original post link

It will not be automatically deleted.

| username: Jack-li | Original post link

That’s right, it doesn’t make sense.

| username: yytest | Original post link

I understand that it should be automatically deleted.

| username: TiDBer_U58GZgGJ | Original post link

Are you referring to whether the job queue is at the server level or if it will also be persisted on KV? I see that after the job is executed, it will be inserted into tidb_ddl_history.

| username: WalterWj | Original post link

It looks like it doesn’t get cleaned up :thinking:

| username: TiDBer_HUfcQIJx | Original post link

It won’t delete automatically.

| username: 人如其名 | Original post link

Strongly recommend allowing deletion or having an automatic cleanup strategy.

| username: wangkk2024 | Original post link

Will not delete

| username: TiDBer_H5NdJb5Q | Original post link

Will there be a lot of DDLs in such a complex business scenario?