Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: 生产下线索引。导致mysql挂掉。这种问题能规避吗

Taking an index offline in production caused MySQL to crash. Can this issue be avoided?
Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: 生产下线索引。导致mysql挂掉。这种问题能规避吗
Taking an index offline in production caused MySQL to crash. Can this issue be avoided?
Yes, I want to ask two questions: how does TiDB handle it and how does MySQL handle it?
This can be controlled through the production terminal. When you want to input “drop index,” it prompts you to enter an authorization code to execute it. Many terminal control systems can achieve this. It is impossible for the database to control this.
“Creating an index in production caused MySQL to crash” Did the MySQL process crash after creating the index? Or did the MySQL service hang? There are invisible indexes, you might want to check those.
The production is TiDB, the downstream is MySQL, and then TiDB deleting the index causes MySQL replication to be interrupted. Is that what you mean?
TiDB should have an index monitoring feature like Oracle, which monitors unused indexes over a period of time before deleting them. This would reduce the risk.
Experimental feature, looking forward to it becoming official soon.
Why delete it? The data based on the judgment is inaccurate.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.