The User Experience of TiDB — Global Kill

Notice: I am not an expert in UX(user experience), but I think I am an experienced user. This series will document some of our efforts to improve the user experience of TiDB and TiDB cloud, what we did well, and what we didn’t do well.

Today, we will talk about TiDB’s new feature — Global Kill. I guess the readers here are familiar with MySQL, or TiDB or other databases.

Kill

Sometimes, the user may send a not well written query(like not using index, or joining too many big tables) to the database. The query will execute for a long time, occupy too many resources of the database and affect other queries.

To avoid this, a simple way like in TiDB is to use `show processlist` to find the ID of the executing query, and then send `kill ID` command to let the database kill the long-running query, like below:

Load balancer Problem

But things are not always so perfect, as a distributed database, TiDB can be scaled out horizontally. Most of our users deploy many TiDB servers, and to let the clients access all servers easily, they often deploy a load balancer in front of all the TiDB servers.

Using a load balancer may cause a problem like above, the user sends a long-running query to one TiDB server, but the admin logs in to another TiDB server through Load Balancer, so the admin can’t kill the query.

To avoid this, we can let the admin pass the Load Balancer and log in to the specific TiDB server, but

• It is not friendly if there are too many TiDB servers
• It is still hard to let the user do the kill by himself/herself, because we don’t want to expose the TiDB servers outside.

Global Kill

From TiDB 6.1, we’ve provided a better way to solve this problem — Global Kill, you can see more here Support CTRL-C or kill <connId> to kill a connection/query by implementing global connection IDs

The feature of Global Kill is enabled by default from TiDB 6.1. As you can see the picture below, the feature is very straightforward.

No matter which TiDB server the admin connects, when the admin sends a kill ID command, the TiDB server will check wether the connection ID belongs to itself or other remote TiDB servers, if the connection ID belongs to the remote one, the TiDB server will forward the kill command to that.

Epilogue

Although now we can support Global Kill, finding the long-running query is still not friendly. As you can see, we use below to get the connection ID.

select ID, INFO from information_schema.cluster_processlist;

A better way is to provide a command like `show cluster processlist` or even `show processlist` itself to return all running queries from all TiDB servers. Feel free to contribute to TiDB if you are interested in.

You can get more TiDB insights from ossinsight.io . You can also create a TiDB cluster for free and have a try through https://tidb.cloud.