Previously, each event logged by MySQL Enterprise Audit included the SQL statement literal text. To provide an alternative (because it is possible that statements contain sensitive information), the audit log filtering language now supports logging a statement's digest rather than its literal text. For example, instead of logging this statement:
SELECT * FROM orders WHERE some_sensitive_column=1234567
The audit log plugin can log this digest:
SELECT * FROM `orders` WHERE `some_sensitive_column` = ?
This is similar to what is already logged for prepared statements, for which parameter markers appear rather than actual data values.
To perform digest logging, use audit filter definitions that replace the statement literal text by its corresponding digest, as discussed in Replacement of Event Field Values.
Because text replacement occurs at an early auditing stage (during filtering), the choice of whether to log statement literal text or digest values applies regardless of log format written later (that is, whether the audit log plugin produces XML or JSON output). (Bug #31482609, WL #14267, WL #14724)
audit_log_disablesystem variable permits disabling audit logging for all connecting and connected sessions. See Disabling Audit Logging. (WL #14699)
Binary packages that include curl rather than linking to the system curl library have been upgraded to use curl 7.80.0. (Bug #33576431)
Queries making use of the
MBRContains()function did not employ all available spatial indexes. (Bug #32975221)
References: This issue is a regression of: Bug #29770705.
FORMAT()function returned a formatted number without showing the thousands separator and grouping between separators when either the es_ES or es_MX locale was specified. (Bug #31374305)
The GnuPG build key used to sign MySQL downloadable packages has been updated. The previous GnuPG build key is set to expire on 2022-02-16. For information about verifying the integrity and authenticity of MySQL downloadable packages using GnuPG signature checking, or to obtain a copy of our public GnuPG build key, see Signature Checking Using GnuPG.
Due to the GnuPG key update, systems configured to use
repo.mysql.commay report a signature verification error when upgrading to MySQL 5.7.37 and higher or to MySQL 8.0.28 and higher using
yum. Use one of the following methods to resolve this issue:
Manually reinstall the MySQL APT or YUM repository setup package from https://dev.mysql.com/downloads/.
Download the MySQL GnuPG public key and add it your system GPG keyring.
For MySQL APT repository instructions, see Appendix A: Adding and Configuring the MySQL APT Repository Manually.
For MySQL YUM repository instructions, see Upgrading MySQL with the MySQL Yum Repository.
buf_validate()function in the
InnoDBsources was optimized, improving performance on debug builds.
Thanks to Hobert Lu for the contribution. (Bug #33417058, Bug #104967)
Partitioning: Creating a table with nondeterministic functions in generated column expressions should not be possible, but this was not enforced in all cases; a series of one or more
ALTER TABLEstatements could be employed to arrive at a partitioned table with one or more such generated columns. When attempting to execute the
CREATE TABLEstatement obtained by running
SHOW CREATE TABLEagainst this table, MySQL rejected the statement with a misleading error message referring to the partitioning expression rather than to the problematic column, despite the fact that the partitioning expression itself was legal.
This was caused by the result of a check for any unsafe expressions defined for a generated column (in the internal variable
thd->safe_to_cache_query), which was later checked again without being cleared while parsing the partition expression, leading to an error even when the partition expression did not refer to the problematic generated column expression. Now in such cases, we reset
thd->safe_to_cache_querybefore parsing the partition function.
The issue of allowing the use of certain nondeterminstic functions (
RANDOM_BYTES()) in generated columns is handled separately. (Bug #29268656)
References: See also: Bug #32592320.
Partitioning: A query using an index other than the primary key of a partitioned table sometimes resulted in excessive CPU load. (Bug #104576, Bug #33238010)
Replication: When the
PAD_CHAR_TO_FULL_LENGTHSQL mode was enabled on a replica server, trailing spaces could be added to a replication channel’s name in the replication metadata repository tables, resulting in errors in replication operations that identified the channel using that data. The issue has now been fixed in MySQL 8.0 by using VARCHAR for character columns, and in MySQL 5.7 by disabling the SQL mode when reading from those tables. Thanks to Brian Yue for the contribution. (Bug #33213841)
MySQL 5.7 did not handle the
thread_stackvariable in the same manner as MySQL 5.6 or MySQL 8.0. (Bug #33362907)
It was possible in some cases to create a generated column of type
SERIAL, which is not allowed.
See Numeric Data Type Syntax, and CREATE TABLE and Generated Columns, for more information (Bug #33141966)
Statements which commit a transaction implicitly or explicitly are not allowed inside a trigger or a stored function. Both
CREATE FUNCTIONshould report an error (
ER_COMMIT_NOT_ALLOWED_IN_SF_OR_TRG) in this case, but did not correctly handle
DROP TABLESPACE. (Bug #33141958)
The MySQL session used for online keyring migration was not closed gracefully after the migration was complete, resulting in an “Aborted connection” note being printed to the error log. (Bug #32989716)
CR_UNKNOWN_ERRORwas to be sent to a client, an exception could occur. (Bug #31933415)
SHOW PROCESSLISTcould read freed memory when accessing the query string belonging to a connection that was in the process of deleting a prepared statement. (Bug #28142052)
Privileges were not checked correctly for
ALTER USER ... IDENTIFIED WITH ... BY. (Bug #27923149, Bug #29882299)