Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: 7.1.0TiDB 关闭元数据锁有哪些影响?
[TiDB Usage Environment] Production Environment
[TiDB Version] 7.1.0
[Reproduction Path] Not reproduced
[Encountered Problem: Problem Phenomenon and Impact]
- What are the impacts of disabling metadata lock in version 7.1.0 on the service?
Background:
-
In the production environment, DDL is frequently blocked by MDL locks. After investigation, it was found that metadata locks were added after version 6.5. 元数据锁 | PingCAP 文档中心
-
Architecture background:
- The cluster was upgraded from version 5.0 to version 7.1.
We upgraded our STG environment to 6.5 and encountered the same issue. We couldn’t resolve it; executing DDL statements would get stuck, and we couldn’t find any related transactions. In the end, we had to disable the metadata lock, and after doing so, the issue was resolved. Currently, the development team hasn’t reported any problems, but we haven’t upgraded the production environment yet.
Older versions did not introduce metadata locks. If metadata changes occur on the related table during the execution of a transaction, TiDB will return an Information schema is changed
error to ensure data consistency, causing the user transaction to fail. The upgraded version will automatically enable this by default, but it can be turned off.
It doesn’t work at all. As long as you execute DDL, it gets stuck. Even the simplest create table gets stuck.
Thank you, boss. Very useful information.
Could you please provide the data volume, business characteristics, TPS, and QPS?
We are only using it in the testing environment, it hasn’t been deployed online yet.
Creating tables is being blocked? That shouldn’t be the case. Check mysql.tidb_mdl_view.
Received, received
. Gather more opinions from other classmates.
During the issue, no data could be retrieved from this table at all.
We are using version 7.1.1 in production and have not encountered any issues with DDL stalling so far.
First, check if yours is running, and also see if there are many DDL operations being executed.
We have a lot of SQL incompatibilities here, so we didn’t upgrade.
It depends on the business. In the past, when there was no metadata, queries might fail. If the business can accept this, I think it’s not a big deal, or you can add business retries.
There was no feedback before upgrading to 5.0.
Turn it off first, if there are any issues, solve them later. If you don’t turn it off, it will always be a problem.
Steady, accurate, and ruthless. In one word, just do it.
Remember, one thing to pay attention to during the upgrade.
Will it have any impact if it’s turned off?
How long does this blocking last? Based on the function of MDL and your business, is this MDL blocking expected?
Turning off MDL doesn’t have much impact.
The leader doesn’t allow intervention, opting for post-processing.