*: add infoschema client errors

[morgo]

What problem does this PR solve?

Issue Number: close #14433

Revives PR: #20785

Problem Summary:

In the PR #22351 , it is proposed that multiStmt be permitted as a warning, and later changed to a default. This provides an upgrade path for users.

The problem is, errors sent to the client were previously not captured by the server. So it is difficult to tell if a user is depending on the buggy behavior of multiStmt, and if the defaults change will cause them problems.

Thus, the proposal is to cherry-pick to 4.0 and 5.0 to provide a viable way to get past the multiStmt vulnerability.

What is changed and how it works?

What's Changed:

This PR introduces a method to observe errors and warnings sent to clients. For example, using multiStmt as an example:

mysql> select * from CLIENT_ERRORS_SUMMARY_by_user;
+------+--------------+---------------------------------------------------------------------------------------------------------------------------------------+-------------+---------------+---------------------+---------------------+
| USER | ERROR_NUMBER | ERROR_MESSAGE                                                                                                                         | ERROR_COUNT | WARNING_COUNT | FIRST_SEEN          | LAST_SEEN           |
+------+--------------+---------------------------------------------------------------------------------------------------------------------------------------+-------------+---------------+---------------------+---------------------+
| root |         1054 | Unknown column '%-.192s' in '%-.192s'                                                                                                 |           4 |             0 | 2021-01-13 13:14:06 | 2021-01-13 13:14:06 |
| root |         1105 | Unknown error                                                                                                                         |           1 |             0 | 2021-01-13 13:14:25 | 2021-01-13 13:14:25 |
| root |         1146 | Table '%-.192s.%-.192s' doesn't exist                                                                                                 |          12 |             0 | 2021-01-13 13:06:29 | 2021-01-13 13:12:56 |
| root |         8130 | client has multi-statement capability disabled. Run SET GLOBAL tidb_allow_multi_statement='ON' after you understand the security risk |           1 |             1 | 2021-01-13 13:06:53 | 2021-01-13 13:14:25 |
| root |         1365 | Division by 0                                                                                                                         |           0 |             1 | 2021-01-13 13:07:18 | 2021-01-13 13:07:18 |
+------+--------------+---------------------------------------------------------------------------------------------------------------------------------------+-------------+---------------+---------------------+---------------------+
5 rows in set (0.00 sec)

(The warning is the default, when set to OFF, it generated an error).

In total, three new information schema tables have been introduced:

• client_errors_summary_global
• client_errors_summary_by_host
• client_errors_summary_by_user

The design is modeled loosely based on what MySQL 8.0 has in performance_schema. But there are the following differences to be aware of:

• In MySQL 8.0, reseting the stats is done with a TRUNCATE TABLE command. But since these are in infoschema in TiDB, a command FLUSH CLIENT_ERRORS_SUMMARY is added.
• In MySQL there is always a row for each error code (regardless if any errors or warnings have been generated). I thought could be misleading, since if it showed all errors in the errno package - some are known not to be generated. Also, it creates a very large table if there are a lot of users or hosts.
• In TiDB it shows the ERROR_MESSAGE (in sprintf format), not the ERROR_NAME. This is a current limitation based on what is stored in the errno` package. I think it's fine.
• There is no ERROR_RAISED / ERROR_HANDLED counts, and the columns are just renamed to ERROR_COUNT. TiDB does not have stored procs, and thus no error handling.

How it Works:

The errors and warnings could be generated anywhere in code. I capture them not at generate time, but as they are sent to the client. This means that internal sql execution that triggers warnings etc. is not logged.

There is no persistence of the statistics, and no cluster-wide view.

Related changes

• Parser PR ast, misc, parser: add FLUSH CLIENT_ERRORS_SUMMARY parser#1154
• Need to cherry-pick to the release branch
• Docs PR information-schema: add client errors docs docs#5062

Check List

Tests

• Unit test

Side effects

• Should be minimal performance impact since it only needs to acquire the mutex briefly when there is a statement that has caused an error or warning. I checked with tiup tpcc bench to see how many client errors are generated, and it is only 1 during prepare.

Release note

• A set of client_errors_summary tables has been added to Information Schema. This helps keep track of which errors have been sent to clients.

[bb7133]

/lgtm

[bb7133]

/lgtm

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• bb7133

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 writing /lgtm in a comment.
Reviewer can cancel approval by writing /lgtm cancel in a comment.

[bb7133]

/merge

[ti-chi-bot]

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

Commit hash: acf1f51

[ti-srebot]

cherry pick to release-4.0 in PR #23267

[ti-srebot]

cherry pick to release-5.0-rc in PR #23268

[bb7133]

/run-build-image

[SunRunAway]

Do you have related documentation? @morgo

[morgo]

@SunRunAway I do now: pingcap/docs#5062 - can you please help review? :-)