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.