DDL statements cannot be completed or stopped

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

Original topic: ddl语句执行不完也停不下来

| username: zhanggame1

[TiDB Usage Environment] Production Environment / Testing / Poc
[TiDB Version] 7.1
[Reproduction Path] What operations were performed to cause the issue
Truncate a table, then the DDL status is done, but it never completes nor terminates.
I saw a similar issue posted on the forum a few days ago, but it wasn’t clear how to resolve it.
[Resource Configuration] Go to TiDB Dashboard - Cluster Info - Hosts and take a screenshot of this page
[Attachments: Screenshots/Logs/Monitoring]


| username: h5n1 | Original post link

Check if there is any content in mysql.tidb_mdl_view. If there is, it might be blocked, and you can see if you can kill it. If there is no content, just wait. If it still doesn’t work after waiting for a long time, you might need to restart all TiDB servers. The current “done” status means it hasn’t been synchronized to other TiDB nodes yet.

| username: zhanggame1 | Original post link

Cannot be cancelled. Error: [ddl:8225] This job: 128771 is finished, so can’t be cancelled.

| username: zhanggame1 | Original post link

The mysql.tidb_mdl_view attempt to select keeps running and getting stuck.

| username: tidb菜鸟一只 | Original post link

You definitely can’t cancel it. Cancel can only be used for tasks that haven’t been completed yet, and yours is already in a done state. Generally, in this situation, it’s being blocked by other queries. You can kill the IDs retrieved from the table by running select * from mysql.tidb_mdl_view;. However, if you can’t retrieve any data now, do you really have to restart TiDB?

| username: zhanggame1 | Original post link

After 10 minutes, the result of select * from mysql.tidb_mdl_view came out… There are a large number of modifications to this table.

Are these job IDs for ADMIN CANCEL DDL JOBS? The execution returns that these job IDs cannot be found.

| username: h5n1 | Original post link

View interpretation

| username: zhanggame1 | Original post link

All output session IDs are the same, and they match the session ID of the statement that got stuck on truncate.

| username: 像风一样的男子 | Original post link

Who wrote this code? It’s blocked.

| username: zhanggame1 | Original post link

Navicat right-clicked this table and truncated it, it’s inexplicable.

| username: TiDBer_oHSwKxOH | Original post link

It needs to be restarted.

| username: Jolyne | Original post link

I encountered this problem before as well, and it was resolved after a restart.

| username: tidb菜鸟一只 | Original post link

No, take a look at what the sql_digests column shows?

| username: TiDBer_oHSwKxOH | Original post link

Logging into each machine and restarting the tidbserver will solve the issue, but it is very disruptive to business.

| username: zhanggame1 | Original post link

The issue has been resolved by restarting all TiDB instances.

tiup cluster restart tidb-test -R tidb

| username: 像风一样的男子 | Original post link

Restarting is great!

| username: TiDBer_oHSwKxOH | Original post link

It’s always like this. Restarting will help.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.