MySQL 5.7 Release Notes
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)
The new audit_log_disable
system 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.
The 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.com
may report a signature
verification error when upgrading to MySQL 5.7.37 and higher or
to MySQL 8.0.28 and higher using apt
or
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.
(Bug #33587308)
The bundled libedit
library was upgraded to
version 20210910-3.1.
(Bug #33568767)
InnoDB:
The buf_validate()
function in the
InnoDB
sources 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 TABLE
statements could be
employed to arrive at a partitioned table with one or more such
generated columns. When attempting to execute the
CREATE TABLE
statement obtained
by running SHOW CREATE TABLE
against 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_query
before parsing
the partition function.
The issue of allowing the use of certain nondeterminstic
functions (AES_ENCRYPT()
,
AES_DECRYPT()
,
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_LENGTH
SQL 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_stack
variable 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 TRIGGER
and
CREATE FUNCTION
should 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)
If a CR_UNKNOWN_ERROR
was to be
sent to a client, an exception could occur.
(Bug #31933415)
SHOW PROCESSLIST
could 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)