server: a better way to handle killed connection

[bb7133]

What problem does this PR solve?

Issue Number: close #24031, this PR also reverts #29212.

Problem Summary:

What is changed and how it works?

The root cause of #24031 is that when a connection is idle, the goroutine is blocked at:

https://github.com/pingcap/tidb/blob/4a0d387e1ff1b508bbb60d484d97e4ac2a5ef2c7/server/conn.go#L1068

And the stack:

#	0x13fc361	bufio.(*Reader).Read+0x221					/home/bb7133/Softwares/go/src/bufio/bufio.go:227
#	0x34c8fba	github.com/pingcap/tidb/server.bufferedReadConn.Read+0x5a	/home/bb7133/Projects/gopath/src/github.com/pingcap/tidb/server/buffered_read_conn.go:31
#	0x1342886	io.ReadAtLeast+0x86						/home/bb7133/Softwares/go/src/io/io.go:328
#	0x34a96e4	io.ReadFull+0x84						/home/bb7133/Softwares/go/src/io/io.go:347
#	0x34a96ab	github.com/pingcap/tidb/server.(*packetIO).readOnePacket+0x4b	/home/bb7133/Projects/gopath/src/github.com/pingcap/tidb/server/packetio.go:86
#	0x34a9aee	github.com/pingcap/tidb/server.(*packetIO).readPacket+0x4e	/home/bb7133/Projects/gopath/src/github.com/pingcap/tidb/server/packetio.go:117
#	0x3479624	github.com/pingcap/tidb/server.(*clientConn).readPacket+0x1e4	/home/bb7133/Projects/gopath/src/github.com/pingcap/tidb/server/conn.go:397
#	0x34795ea	github.com/pingcap/tidb/server.(*clientConn).Run+0x1aa		/home/bb7133/Projects/gopath/src/github.com/pingcap/tidb/server/conn.go:1068
#	0x34b2d1d	github.com/pingcap/tidb/server.(*Server).onConn+0x12bd		/home/bb7133/Projects/gopath/src/github.com/pingcap/tidb/server/server.go:554

Because of that, the goroutine is not able to deal with the KILLED flag, release the resource it is holding and stop itself immediately.

In order to solve that, we need to make conn.Read() interruptable but there is no straightforward way in Go to do that. Some references:

1. proposal: io/v2: add Context parameter to Reader, etc. golang/go#20280: a lot of discussions/arguments without a clear conclusion.
2. Canceling I/O in Go Cap’n Proto: mentioned in go/issues/20280
3. Simplify pipestream by correctly interrupting a read on context cancellation. google/mtail#497: a context-based implementation for canceling the Read()

For the approach introduced in 2 and 3, they are generally the same as this PR: setting SetReadDeadline in another goroutine. I cannot find any material describing if doing so is thread-safe, so it should be implementation-dependent and might not be safe, but it might not be a real problem considering we're about the kill the connection and the read buffer/status will be abandoned.

Alternatives

• SHOW PROCESSLIST (and infoschema) is modified to show the State as Killed, as mentioned by @morgo in Killing connections needs cooperation from the to-be-killed connection #24031 (comment), the result of SHOW PROCESSLIST can be clear to the user but it doesn't solve the delayed 'release lock' issue(see Case 2 in 'Manual test' part).
• Instead of setting the read timeout to waitTimeout, the code is instead modified to have a hard coded 2s timeout, but loops for up to waitTimeout retrying a read..., also mentioned by @morgo in Killing connections needs cooperation from the to-be-killed connection #24031 (comment), the potential thread-safe concern can be avoided but we still have at most 2s delay for killing an idle connection and the code would be complicated.
• Instead of setting SetReadDeadline(), bufReadConn.Close() can be another solution. It is basically the same with SetReadDeadline() IMHO.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Case1:

Session1> (in idle state, with PROCESS_ID=3)
Session2> KILL TIDB 3;
Session2> SHOW PROCESSLIST; (Can be confirmed that Session1 is killed)

Case2:

Session1> CREATE TABLE t1(a INT);
Session1> INSERT INTO t1 values (1);
Session1> BEGIN PESSIMISTIC;
Session1> SELECT * FROM t1 WHERE a=1 FOR UPDATE;
Session1> (in idle state, with PROCESS_ID=3)
Session2> BEGIN PESSIMISTIC;
Session2> SELECT * FROM t1 WHERE a=1 FOR UPDATE; (Session 2 is blocked and waiting for the lock)
Session3> KILL TIDB 3; (Can be confirmed that Session 1 is killed and Session2 is able to acquire the lock immediately).

Side effects

• None

Release note

fix the issue that `KILL TIDB` doesn't take effect immediately on idle connections

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• jackysp
• morgo

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[sre-bot]

Code Coverage Details: https://codecov.io/github/pingcap/tidb/commit/159fa8d6418f30186f8694d2a0c88838dcb68392

[bb7133]

PTAL @djshow832 @tiancaiamao @morgo @dveeden

[morgo]

LGTM & very happy to see this fixed. I'm not sure about cherry picking though.

[jackysp]

LGTM

[jackysp]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: d06ee56

[ti-srebot]

cherry pick to release-4.0 in PR #33073

[ti-srebot]

cherry pick to release-5.0 in PR #33074

[ti-srebot]

cherry pick to release-5.1 in PR #33075

[ti-srebot]

cherry pick to release-5.2 in PR #33076

[zimulala]

@bb7133
It seems that we need to cherry-pick to v5.4, but we don't do it.

[ti-srebot]

cherry pick to release-5.4 in PR #37834

[ti-chi-bot]

In response to a cherrypick label: new pull request created: #38887.

[ti-chi-bot]

In response to a cherrypick label: new pull request created: #38888.