Audit Log Plugin Notes
MySQL 5.7 changed audit log file output to a new format that has
better compatibility with Oracle Audit Vault. This format has
been backported to MySQL 5.5 and it is possible to select either
the old or new format using the new
variable, which has permitted values of
details about each format, see The Audit Log File.
In addition, when the audit log plugin rotates the audit log
file, it uses a different file name format. For a log file named
audit.log, the plugin previously renamed
the file to
The plugin now renames the file to
to indicate that it is an XML file.
If you change the value of
audit_log_format, use this
procedure to avoid writing log entries in one format to an
existing log file that contains entries in a different format:
Stop the server.
Rename the current audit log file manually.
Restart the server with the new value of
audit_log_format. The audit
log plugin will create a new log file, which will contain
log entries in the selected format.
The API for writing audit plugins has also changed. The
mysql_event_general structure has new members
to represent client host name and IP address, command class, and
external user. For more information, see
Writing Audit Plugins.
Following any query on the
InnoDB index statistics as
shown in the output of statements such as
read from the last partition, instead of from the partition
containing the greatest number of rows.
(Bug #11766851, Bug #60071)
References: See also Bug #16882435, Bug #69179.
would incorrectly prepare to compare a NULL column prefix in a
secondary index with a non-NULL column in a clustered index.
InnoDB: An incorrect purge would occur when rolling back an update to a delete-marked record. (Bug #17302896)
InnoDB would rename a user-defined foreign
key constraint containing the string “_ibfk_” in
its name, resulting in a duplicate constraint.
(Bug #17076737, Bug #69693, Bug #17076718, Bug #69707)
Rolling back an
INSERT after a
BLOB write would result in
an assertion failure. The assertion has been modified to allow
BLOB pointers if an error
occurs during a
A regression introduced with the fix for Bug #11762038 would
InnoDB to raise an incorrect error
message. The message stated that, “InnoDB cannot
delete/update rows with cascading foreign key constraints that
exceed max depth of 20”. The error message would occur
when killing connections reading from
tables that did not have foreign key constraints.
The documentation incorrectly stated that
START TRANSACTION WITH
CONSISTENT SNAPSHOT provides a consistent snapshot
only if the current isolation level is
REPEATABLE READ or
START TRANSACTION WITH
CONSISTENT SNAPSHOT only works with
REPEATABLE READ. All other
isolation levels are ignored. The documentation has been revised
and a warning is now generated whenever the
SNAPSHOT clause is ignored.
(Bug #14017206, Bug #65146)
srv_master_thread background thread,
which monitors server activity and performs activities such as
page flushing when the server is inactive or in a shutdown
state, runs on a one second delay loop.
srv_master_thread failed to check if the
server is in a shutdown state before sleeping.
(Bug #13417564, Bug #63276)
An infinite loop could occur in
buf_page_get_gen when handling
(Bug #12560151, Bug #61132)
Creating a table
CREATE TABLE ...
PARTITION BY LIST ... PARTITION ... VALUES IN (NULL),
then attempting to execute
CREATE TABLE ...
LIKE t1 caused the server to fail.
A slave using row-based replication was unable to read the rows
containing columns of type
properly (old-style decimal, used prior to MySQL 5.0.3). Now the
slave throws an error if it receives this type of data. You can
convert the old-style
format to the binary format used in current MySQL releases with
ALTER TABLE; see
from MySQL 4.1 to 5.0, for more information.
DROP TEMP TABLE IF
EXISTS statements could lead to failures in applying
the binary log during point-in-time recovery operations. This is
due to the fact that, when using row-based replication, the
IF EXISTS to any
TEMPORARY TABLE statements written to the binary log,
and that the slave SQL thread does not check * wildcard filter
DROP TEMPORARY TABLE IF EXISTS. If
--log-slave-updates was also
enabled on the slave, such a statement was preceded by a
USE statement. If the database
referred by the
USE statement did not exist,
the statement failed, and stopped replication.
Now, when writing
DROP TEMPORARY TABLE IF
EXISTS into the binary log, no
statement is written, and the table name in the
TEMPORARY TABLE statement is a fully qualified table
References: This bug is a regression of Bug #14188793.
Within a stored program, comparison of the value of a scalar
subquery with an
IN clause resulted in an
error for the first execution and raised an assertion for the
my_strtoll10() function could incorrectly
convert some long string-format numbers to numeric values and
fail to set the overflow flag.
A race condition in the thread pool plugin could cause status
variables such as
Aborted_connects not to be
incremented and permitting concurrent kills to happen for the
same thread ID.
Within a stored procedure, repeated execution of a prepared
CREATE TABLE statement for a
table with partitions could cause a server exit.
Deadlocks involving metadata locks and
deadlocks were both reported as an
ER_LOCK_DEADLOCK error, but only
InnoDB deadlocks rolled back the transaction.
Now both deadlocks roll back the transaction.
For queries that accessed an
INFORMATION_SCHEMA table in a subquery, an
attempt to lock a mutex that had already been locked could cause
a server crash.
RPM packages did not provide lowercase tags for their contents.
For example, a server RPM indicated that it provided
MySQL-server, but not
(Bug #69830, Bug #17211588)
InnoDB deadlock caused transaction rollback
but did not release metadata locks, blocking concurrent DDL on
the transaction tables until the connection that got the
deadlock issued an explicit
(Bug #69668, Bug #17054007)
SET OPTION, which failed when
reloaded because the deprecated
keyword has been removed from
(Bug #67507, Bug #15844882)
For failure to create a new thread for the event scheduler, event execution, or new connection, no message was written to the error log. This could lead to the impression that the event scheduler was running normally when it was not. (Bug #67191, Bug #14749800, Bug #16865959)
If one connection changed its default database and
simultaneously another connection executed
PROCESSLIST, the second connection could access
invalid memory when attempting to display the first connection's
default database. memory.
(Bug #58198, Bug #11765252)