MySQL 8.0 Release Notes
For general information about upgrades, downgrades, platform support, etc., please visit https://docs.oracle.com/cd/E17952_01/mysql-8.0-relnotes-en/.
Encryption and decryption operations for encrypted MySQL Enterprise Audit log
files use a password stored in the MySQL keyring. Previously,
only a single password was stored. Generating a new password
made the old password inaccessible, rendering MySQL Enterprise Audit unable
to read log files encrypted with the old password. MySQL Enterprise Audit now
implements password history in the keyring, which includes
password archiving and expiration capabilities. The audit log
plugin includes in each encrypted log file name the ID of the
password required to read the file. To enable expiration and
removal of old archived passwords in the keyring, the new
audit_log_password_history_keep_days
system variable is available. See
Configuring Audit Logging Characteristics.
(WL #11246)
These C API changes were made:
HOSTNAME_LENGTH
was changed from 60 to
255 and moved from include/mysql_com.h
to include/my_hostname.h
.
USER_HOST_BUFF_SIZE
was moved from
include/mysql_com.h
to
sql/auth/auth_common.h
.
(Bug #29590300)
The utf8mb4
character set has a new binary
collation, utf8mb4_0900_bin
, which differs
from the existing utf8mb4_bin
binary
collation as follows:
For collating weights, utf8mb4_bin
uses
code points, possibly with leading zero bytes added, whereas
utf8mb4_0900_bin
uses the
utf8mb4
encoding bytes. The sort order is
the same for both collations, but sorting for
utf8mb4_0900_bin
is much faster.
The pad attribute for utf8mb4_bin
is
PAD SPACE
, whereas for
utf8mb4_0900_bin
it is NO
PAD
. Consequently, operations involving
utf8mb4_0900_bin
do not add trailing
spaces, and comparisons involving strings with trailing
spaces may differ for the two collations.
For more information, see Unicode Character Sets. (WL #10354)
A new mysql_current_thread_reader
component
service is available to enable components to obtain a handle to
the current thread. For example, the service enables components
to access properties of the current session by passing its
thread handle to other services. For information about this
service, see the Component Subsystem section of the MySQL Server
Doxygen documentation, available at
https://dev.mysql.com/doc/index-other.html.
(WL #12727)
The source files in the mysys_ssl
directory
have been moved to the mysys
directory and
the mysys_ssl
library is no longer built.
(Bug #29488066)
MySQL configuration now requires a minimum CMake version of 3.5.1. (Bug #29337090)
The maximum permitted length of host names throughout MySQL has
been raised to 255 ASCII characters, up from the previous limit
of 60 characters. This applies to, for example, host
name-related columns in the data dictionary,
mysql
system schema, Performance Schema,
INFORMATION_SCHEMA
, and
sys
schema; the
MASTER_HOST
value for the
CHANGE MASTER TO
statement; the
Host
column in SHOW
PROCESSLIST
statement output; host names in account
names (such as used in account-management statements and in
DEFINER
attributes); and host name-related
command options and system variables.
Caveats:
The increase in permitted host name length can affect tables
with indexes on host name columns. For example, tables in
the mysql
system schema that index host
names now have an explicit ROW_FORMAT
attribute of DYNAMIC
to accommodate
longer index values.
Some file name-valued configuration settings might be
constructed based on the server host name. The permitted
values are constrained by the underlying operating system,
which may not permit file names long enough to include
255-character host names. This affects the
general_log_file
,
log_error
,
pid_file
,
relay_log
, and
slow_query_log_file
system
variables and corresponding options. If host name-based
values are too long for the OS, explicit shorter values must
be provided.
Although the server now supports 255-character host names,
connections to the server established using the
--ssl-mode=VERIFY_IDENTITY
option are constrained by maximum host name length supported
by OpenSSL. Host name matches pertain to two fields of SSL
certificates, which have maximum lengths as follows: Common
Name: maximum length 64; Subject Alternative Name: maximum
length as per RFC#1034.
Applications that expect host names to be a maximum of 60 characters should be adjusted to account for this change. (Bug #13548245, Bug #63814, Bug #27925782, Bug #90601, Bug #27955121, Bug #29584642, Bug #29602081, Bug #94907, WL #12571)
The MySQL server is a multithreaded application that uses numerous internal locking primitives such as mutexes. To enable detection of lock-acquisition deadlocks and enforcement that runtime execution is free of them, MySQL now supports LOCK_ORDER tooling. This enables a lock-order dependency graph to be defined as part of server design, and server runtime checking to ensure that lock acquisition is acyclic and that execution paths comply with the graph. LOCK_ORDER support includes:
A lock_order_dependencies.txt
file that
defines the server lock-order dependency graph.
A WITH_LOCK_ORDER
CMake option that configures whether
MySQL is built with LOCK_ORDER tooling.
A set of system variables that configure LOCK_ORDER tool operation during server execution.
A --lock-order
option for
mysql-test-run.pl that controls whether
to enable the LOCK_ORDER tool during test case execution.
To use the LOCK_ORDER tool, you must build MySQL from source with tooling enabled. See The LOCK_ORDER Tool. It is intended for debugging the server, not for production use.
X DevAPI:
For Collection
objects, the following methods
have been deprecated and are scheduled to be removed in a future
release:
Collection.find().where()
Collection.modify().where()
Collection.remove().where()
Any Collection
code relying on the
.where()
method should be updated and the
expression in the .where()
method should be
provided directly in the appropriate .find()
,
.remove()
, and .modify()
method.
(WL #12902)
A mysql_upgrade_info
file created by the
mysql_upgrade program during a previous
upgrade could only be modified the operating system user that
executed the mysql_upgrade program, causing
an upgrade error. A warning is now issued instead of an error,
which permits the upgrade operation to proceed. The
mysql_upgrade_info
file is deprecated and
will be removed in a future MySQL version.
(Bug #29702060, Bug #95165)
FLOAT(
and
M
,D
)DOUBLE(
syntax to specify the number of digits for columns of type
M
,D
)FLOAT
and
DOUBLE
(and any synonyms) is a
nonstandard MySQL extension. This syntax is deprecated and
support for it will be removed in a future MySQL version.
(Bug #25328973, Bug #84363, WL #12575)
For string data types, the BINARY
attribute
is a nonstandard MySQL extension that is shorthand for
specifying the binary (_bin
) collation of the
column character set (or of the table default character set if
no column character set is specified). In MySQL 8.0, this
nonstandard use of BINARY
is ambiguous
because the utf8mb4
character set has
multiple _bin
collations, so the
BINARY
attribute is deprecated and support
for it will be removed in a future MySQL version. Applications
should be adjusted to use an explicit _bin
collation instead.
The use of BINARY
to specify a data type or
character set remains unchanged.
(WL #13068)
The nonstandard C-style
&&
,
||
, and
!
operators that
are synonyms for the standard SQL
AND
,
OR
, and
NOT
operators, respectively, are
deprecated and support for them will be removed in a future
MySQL version. Applications that use the nonstandard operators
should be adjusted to use the standard operators.
Use of ||
is
deprecated unless the
PIPES_AS_CONCAT
SQL mode is
enabled. In that case, ||
signifies the
SQL-standard string concatenation operator).
(WL #13070)
The ZEROFILL
attribute is deprecated for
numeric data types, as is the display width attribute for
integer data types. Support for ZEROFILL
and
display widths for integer data types will be removed in a
future MySQL version. Consider using an alternative means of
producing the effect of these attributes. For example,
applications could use the LPAD()
function to zero-pad numbers up to the desired width, or they
could store the formatted numbers in
CHAR
columns.
(WL #13127)
The UNSIGNED
attribute is deprecated for
columns of type FLOAT
,
DOUBLE
, and
DECIMAL
(and any synonyms) and
support for it will be removed in a future MySQL version.
Consider using a simple CHECK
constraint
instead for such columns.
(WL #12391)
AUTO_INCREMENT
support is deprecated for
columns of type FLOAT
and
DOUBLE
(and any synonyms) and
will be removed in a future MySQL version. Consider removing the
AUTO_INCREMENT
attribute from such columns,
or convert them to an integer type.
(WL #12595)
The SQL_CALC_FOUND_ROWS
query modifier and
accompanying FOUND_ROWS()
function are now deprecated and will be removed in a future
MySQL version. As a replacement, considering executing your
query with LIMIT
, and then a second query
with COUNT(*)
and without
LIMIT
to determine whether there are
additional rows. For example, instead of these queries:
SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name
WHERE id > 100 LIMIT 10;
SELECT FOUND_ROWS();
Use these queries instead:
SELECT * FROM tbl_name
WHERE id > 100 LIMIT 10;
SELECT COUNT(*) WHERE id > 100;
COUNT(*)
is subject to certain
optimizations. SQL_CALC_FOUND_ROWS
causes
some optimizations to be disabled.
(WL #12615)
An automatic upgrade at server startup can take some time to complete. For better status notification in systemd environments, the server now sends messages to the system notification socket when upgrades start and end. (Status can be monitored with server mysqld status.) (Bug #29493201)
The keyring_aws
plugin has been updated to
use the latest AWS Encryption SDK and so that it works with
OpenSSL 1.1.
The keyring_aws_region
variable
supports the additional AWS regions supported by the new SDK.
Refer to the variable description for a list of supported AWS
regions.
(WL #12886)
To reduce the download size and disk footprint of
mysql-community-server
Linux packages, debug
binaries and plugins have been moved to separate packages for
these platforms:
EL8, Fedora: The mysql-community-server
package with debug binaries and associated plugins is now
split into a mysql-community-server
package without debug binaries or plugins and a
mysql-community-server-debug
package with
debug binaries and plugins.
Debian: The mysql-community-server
package with debug binaries and associated plugins is now
split into a mysql-community-server
package without debug binaries or plugins, a
mysql-community-server-debug
package with
debug binaries, and a
mysql-community-test-debug
package with
debug plugins.
In all cases, the debug packages are dependent on the
corresponding mysql-community-server
package.
(Bug #29769061, Bug #28647754, Bug #92415, Bug #29702765, Bug #95169, Bug #29681301)
Performance Schema version checking at compile time was improved to prevent incompatibilities with the server version. (Bug #29550156)
Previously, the Performance Schema instrumentation for RWLOCK
named priority read/write locks as rwlock
(thus failing to distinguish plain from priority locks) and did
not collect information about the kind of unlock operation
performed. Priority read/write locks now are named
prlock
, so that events for them begin with
wait/synch/prlock
. Also, information about
unlock operations is provided.
(Bug #29270712)
Not all plugins can operate properly if loaded
“early” in the server startup sequence using the
--early-plugin-load
option (that
is, before InnoDB
is initialized). However,
InnoDB
requires keyring backend plugins to
operate on encrypted tables. To enable plugins to indicate to
the server whether they can be loaded early, a new
PLUGIN_OPT_ALLOW_EARLY
flag is available for
use in the plugin descriptor. See
Server Plugin Library and Plugin Descriptors. Keyring plugins
included in MySQL distributions now have the
PLUGIN_OPT_ALLOW_EARLY
flag enabled because
InnoDB
requires them, but the flag is not
limited to keyring plugins. It can be set for other plugins that
are able to initialize successfully early in the server startup
sequence.
This flag has no effect on whether a plugin can be loaded at
server startup with the
--plugin-load
or
--plugin-load-add
option, or at
runtime with the INSTALL PLUGIN
statement.
All plugins compiled using MySQL distributions prior to 8.0.17
do not have this flag set. When loading these into pre-8.0.17
servers this does not matter, but attempts to use
--early-plugin-load
to load
plugin binaries compiled using pre-8.0.17 MySQL distributions
into a 8.0.17 or higher server will fail. The plugins must be
recompiled against MySQL 8.0.17 or higher.
(Bug #29040456, Bug #93550, WL #12935)
For platforms on which OpenSSL libraries are bundled, the linked OpenSSL library for MySQL Server has been updated to version 1.0.2s. Issues fixed in the new OpenSSL version are described at https://www.openssl.org/news/cl102.txt and https://www.openssl.org/news/vulnerabilities.html. (Bug #29881152)
The createIndex()
method did not support the
DOUBLE(M,D)
syntax for specifying
double-precision values due to a regression in MySQL 8.0.16.
(Bug #29748841)
X Protocol's handling of messages with arguments encoded as octets was corrected to support non-scalar data such as an array of strings. (Bug #29721046)
When host name identity verification was active for SSL
connections (--ssl-mode=VERIFY_IDENTITY
), X
Protocol did not check for matches to Subject Alternative Names
(SANs) in the server Certificate Authority (CA) certificate.
This could lead to connection requests being rejected
unnecessarily because they used a valid host name that was
specified as an SAN rather than as the certificate's Common Name
value.
(Bug #29691694)
When prepared statements were used with X Plugin, using
IN
or NOT IN
in a modify
or find operation produced invalid JSON, resulting in an error.
(Bug #29259501)
On Windows, X Plugin logged some messages that were unnecessary or insufficiently informative. The messages have been removed or improved as appropriate. (Bug #27839153)
X Plugin's list of SQL functions was out of date, and has been updated to add new functions and remove functions that are no longer available. (Bug #26574971)
InnoDB; JSON:
InnoDB
now supports multi-valued
indexes on JSON
arrays. A
multi-valued index is an index in which multiple index records
can point to the same data record. This can be useful for
indexing JSON
documents such as
{"user":"Bob","zipcode":[94477,94536]}
in
which, if we wish to search all zip codes, it is necessary to
have two index records for each zip code in the document. We can
create such an index on the zipcode
array
using a CREATE INDEX
statement
such as this one:
CREATE INDEX zips ON t1( (CAST(data->'$.zipcode' AS UNSIGNED ARRAY)) )
Effectively, this is a functional index using the
CAST()
function, which has been
extended with the ARRAY
keyword to enable
casting of JSON arrays to SQL data type arrays. The expression
must be a valid JSON expression, and must point to an array in
the JSON document in order to be effective. All type specifiers
supported by CAST()
can be used except for
BINARY
and JSON
. Such
usage of the CAST()
function is supported
only by InnoDB
, and only for creating
multi-valued indexes on JSON
arrays.
As part of this work, MySQL adds a new function
JSON_OVERLAPS()
as well as a new
MEMBER OF()
operator for working
with JSON
documents, as described
here:
JSON_OVERLAPS()
compares two
JSON
documents. If they
contain any key-value pairs or array elements in common, the
function returns TRUE (1); otherwise it returns FALSE (0).
If both values are scalars, the function performs a simple
test for equality. If one argument is a JSON array and the
other is a scalar, the scalar is treated as an array
element. Thus, JSON_OVERLAPS()
acts as a
complement to
JSON_CONTAINS()
, which
indicates whether all key-value pairs or array elements are
present in both JSON
documents.
MEMBER OF()
tests whether the first
operand (a scalar or JSON document) is a member of the JSON
array passed as the second operand, returning TRUE (1) if it
is, and FALSE (0) if it is not. No type conversion of the
operand is performed.
The MySQL optimizer uses multi-valued indexes automatically for
any suitable query—that is, a query using in its
WHERE
clause any of
JSON_CONTAINS()
,
JSON_OVERLAPS()
, or MEMBER
OF()
on an array within a JSON column. You can see
whether such an index is actually used by checking the output of
EXPLAIN
for the given query.
Multi-Valued Indexes, provides more
detailed information about multi-valued indexes, including
examples. For more information about
JSON_OVERLAPS()
and MEMBER
OF()
, with examples of use, see
Functions That Search JSON Values.
ARRAY
and MEMBER
now are
reserved words and cannot be used as identifiers without
identifier quoting.
(WL #8955, WL #8763)
Group Replication:
It is now possible to use a remote cloning operation for state
transfer to a joining member during distributed recovery. The
remote cloning operation lets you add new members to the group
without transferring the group's data to the server manually
beforehand. To use this functionality, you must install the
Clone plugin on the donor and joining member, grant the
BACKUP_ADMIN
permission to the
replication user for distributed recovery, and set the new
group_replication_clone_threshold
system variable to an appropriate level. Required Clone plugin
settings are now made and the remote cloning operation is now
handled automatically. When cloning is complete and the joining
member has restarted, any transactions that the group applied
while the remote cloning operation was in progress are
transferred to the joining member by replication from a donor's
binary log to complete distributed recovery.
(WL #12827)
Microsoft Windows: A new warning message now reminds DBAs that connections made using the MySQL named pipe on Windows has limited the permissions a connector can request on the named pipe.
Previously, the
named_pipe_full_access_group
system variable was set to a value that maps to the built-in
Windows Everyone
group (SID S-1-1-0) by
default. However, this group is not ideal and should be replaced
with a group that restricts its membership for connectors that
are unable to request fewer permissions on the MySQL named pipe.
The new warning is written to the error log at startup if the
string value assigned to
named_pipe_full_access_group
is
'*everyone*'
(or the Windows System Language
equivalent) and named pipes are enabled. In addition, the
warning is written to the error log and raised to the client if
the system variable is reset to the Everyone
group at runtime.
(WL #12670)
JSON:
MySQL now supports JSON schema validation using two functions
JSON_SCHEMA_VALID()
and
JSON_SCHEMA_VALIDATION_REPORT()
,
both of which validate a JSON document against a JSON schema
conforming to Draft 4 of the JSON Schema specification.
JSON_SCHEMA_VALID()
returns true if the
document validates against the schema and false if it does not.
JSON_SCHEMA_VALIDATION_REPORT()
returns a
JSON document containing detailed information about the results
of the validation.
For both of these functions, the following statements apply:
required
attributes are supported.
Regular expressions are supported (invalid expressions are silently ignored).
External resources in schemas and the
$ref
keyword are not supported.
For more information, including examples, see JSON Schema Validation Functions. (WL #11999, WL #13005)
The time_zone
session variable
is now hintable using the
SET_VAR
optimizer hint.
(Bug #29776464)
The minor version of the libmysqlclient.so
C client library has been increased to 1 (21.0 to 21.1), to
signal that new symbols have been added. This was done to
correct an oversight in the MySQL 8.0.16 release. To address
compatibility concerns, the version of all symbols is unchanged.
This means the filename of the library is
libmysqlclient.so.21.1.17
, whereas all
symbols inside the library are tagged as 21_0 (unchanged from
the 8.0.16 release).
(Bug #29584073, Bug #29642146)
Thanks to Josh Braden, Daniël van Eeden, Simon Mudd, and Zhou Mengkang, who contributed corrections to comments and messages in the MySQL source code. (Bug #29403708, Bug #94464, Bug #29428435, Bug #94527, Bug #29262200, Bug #94049, Bug #29468128, Bug #94625)
The mysql client program now sends
os_user
and os_sudouser
connection attributes, when available, to indicate the name of
the operating system user running the program and the value of
the SUDO_USER
environment variable,
respectively. For general information about connection
attributes, see
Performance Schema Connection Attribute Tables.
Thanks to Daniël van Eeden for the contribution on which this
feature was based.
(Bug #29210935, Bug #93916, WL #12955)
The optimizer now transforms a WHERE
condition having NOT IN
(
, subquery
)NOT
EXISTS (
,
subquery
)IN (
, or subquery
) IS NOT
TRUEEXISTS
(
internally into an antijoin, thus removing the subquery. This is
similar to the existing subquery
) IS NOT TRUEIS NULL
(Not
exists
) outer join optimization; see
EXPLAIN Extra Information, for further
information.
In addition, the semijoin materialization can now be used for a
WHERE
condition having IN
(
, or
subquery
) IS TRUEEXISTS (
, or when the subquery
) IS
TRUEIN
condition
belongs to a left join such as SELECT * FROM t1 LEFT
JOIN t2 ON t2.x IN (SELECT * FROM t3)
. See
Optimizing IN and EXISTS Subquery Predicates with Semijoin Transformations.
Also as a result of this work, MySQL is now able to simplify a
condition of the form (x IS TRUE) IS FALSE
as
x IS NOT TRUE
, which can be tested more
quickly and optimized more easily than the condition as
originally written.
(Bug #29027883, WL #4245)
Password hash values displayed in the IDENTIFIED
WITH
clause of output from SHOW
CREATE USER
may contain unprintable characters that
have adverse effects on terminal displays and in other
environments. Enabling the new
print_identified_with_as_hex
system variable causes SHOW CREATE
USER
to display such hash values as hexadecimal
strings rather than as regular string literals. Hash values that
do not contain unprintable characters still display as regular
string literals, even with this variable enabled. For
compatibility with this change, CREATE
USER
and ALTER USER
now
accept hash values specified either as regular string literals
or as hexadecimal strings.
(Bug #28053446, Bug #90947, WL #12803)
In MySQL 8.0, the
lower_case_table_names
variable
can only be configured when the MySQL server is initialized.
Because a MySQL server installation on Debian and Ubuntu
performed using APT initializes the MySQL server for you, there
was no opportunity to enable
lower_case_table_names
. To work
around this issue, you can now use the
debconf-set-selection
utility to enable
lower_case_table_names
(set
lower_case_table_names=1
) prior
to installing MySQL using APT.
To enable
lower_case_table_names
prior to
installing MySQL using APT, execute the following command:
shell> sudo debconf-set-selections <<< "mysql-server mysql-server/lowercase-table-names select Enabled
(Bug #27948395, Bug #90695)
The server now checks the SSL server certificate better at startup and writes a warning to the error log if it finds a problem. (Bug #25945005)
The umask for files created using
SELECT ... INTO
OUTFILE
or
SELECT ... INTO
DUMPFILE
was changed from 0666 to 0640. The
LOAD_FILE()
function no longer
requires files to be world-readable, just readable by the
server.
(Bug #24513720)
The mysqldump option
--set-gtid-purged
controls whether or not a
SET @@GLOBAL.gtid_purged
statement is added
to the mysqldump output. The statement
updates the value of
gtid_purged
on a server where
the dump file is reloaded, to add the GTID set from the source
server's gtid_executed
system
variable. A new choice
--set-gtid-purged=COMMENTED
is now available.
When this value is set, if GTIDs are enabled on the server you
are backing up, SET @@GLOBAL.gtid_purged
is
added to the output (unless
gtid_executed
is empty), but it
is commented out. This means that the value of
gtid_executed
is available in
the output, but no action is taken automatically when the dump
file is reloaded. With COMMENTED
, you can
control the use of the
gtid_executed
set manually or
through automation. For example, you might prefer to do this if
you are migrating data to another server that already has
different active databases. Thanks to Facebook for this
contribution.
(Bug #94332, Bug #29357665, WL #12959)
MySQL now supports explicit casts to
DOUBLE
,
FLOAT
, and
REAL
using either of the
functions CAST()
or
CONVERT()
. For more information,
see Cast Functions and Operators.
(Bug #30524, Bug #11747058, WL #529)
InnoDB
now supports redo log archiving.
Backup utilities that copy redo log records may sometimes fail
to keep pace with redo log generation while a backup operation
is in progress, resulting in lost redo log records due to those
records being overwritten. The redo log archiving feature
addresses this issue by sequentially writing redo log records to
an archive file. Backup utilities can copy redo log records from
the archive file as necessary, thereby avoiding the potential
loss of data.
For more information, see Redo Log Archiving. (WL #12009, WL #12329, WL #12348)
To provide additional indexing options for
JSON
data, InnoDB
now
supports multi-valued indexes. A multi-valued index is a
secondary index defined on a column that contains an array of
values.
(WL #8763)
MySQL now provides a clone plugin that permits cloning
InnoDB
data locally or from a remote MySQL
server instance. A local cloning operation stores cloned data on
the same server or node where the MySQL instance runs. A remote
cloning operation transfers cloned data over the network from a
donor MySQL server instance to the recipient server or node
where the cloning operation was initiated.
The clone plugin supports replication. In addition to cloning data, a cloning operation extracts and transfers replication coordinates from the donor and applies them on the recipient, which enables using the clone plugin for provisioning Group Replication members and replication slaves. Using the clone plugin for provisioning is considerably faster and more efficient than replicating a large number of transactions. Group Replication members can also be configured to use the clone plugin as an alternative method of recovery, so that members automatically choose the most efficient way to retrieve group data from seed members.
For more information, see The Clone Plugin, and Cloning for Distributed Recovery. (WL #9209, WL #9210, WL #9211, WL #9212, WL #11636, WL #9682)
Compatibility policies for member versions in groups now consider member's MySQL release version. Previously, only the minor version was considered. Using the release version means Group Replication can better maintain replication safety for mixed version groups during group reconfigurations and upgrade procedures.
The compatibility policies are applied when a member joins the group, either for the first time or following its upgrade, when a donor is selected for state transfer, and when a primary member election takes place. Members running MySQL 8.0.16 or earlier take into account only the major version in these situations. For primary member election, so that all members come to the same decision, members running MySQL 8.0.17 or later adjust their policies to match members running lower releases if any are in the group.
In a multi-primary mode group where members running multiple
MySQL Server versions are online, for example during a rolling
online upgrade procedure, Group Replication now automatically
manages the read-write and read-only status of members running
releases. If a member leaves the group, the members running the
version that is now the lowest are automatically set to
read-write mode. When you change a mixed version group that was
running in single-primary mode to run in multi-primary mode,
using the
group_replication_switch_to_multi_primary_mode()
function, members are set automatically to read-write or
read-only mode depending on their MySQL server versions.
These improved compatibility policies influence the behavior of group members during an online upgrade procedure from one patch version to another, in the same ways as the behavior during upgrades from one major version to another was influenced previously. For a multi-primary mode group, the number of members in read-write mode is reduced during the upgrade procedure; their read-write status is now handled automaticaly when the upgrade is otherwise complete. For a single-primary mode group, if you want the primary to remain as the primary, it must be upgraded last. (WL #12826)
Data that is held in the binary log transaction and statement
caches during a transaction is in unencrypted format in the
memory buffer that stores the cache. The data is written to a
temporary file on disk if it exceeds the space available in the
memory buffer. From MySQL 8.0.17, when binary log encryption is
active on the server
(binlog_encryption=ON
), the
temporary files used for the binary log cache are now encrypted
using AES-CTR (AES Counter mode) for stream encryption. Because
the temporary files are volatile and tied to a single process,
they are encrypted using single-tier encryption, using a
randomly generated file password and initialization vector that
exist only in memory and are never stored on disk or in the
keyring. After each transaction is committed, the binary log
cache is reset: the memory buffer is cleared, any temporary file
used to hold the binary log cache is truncated, and a new file
password and initialization vector are randomly generated for
use with the next transaction. This reset also takes place when
the server is restarted after a normal shutdown or an unexpected
halt.
(WL #12079)
An incomplete SQL predicate has the form WHERE
, in which
value
value
is a column name or constant
expression and no comparison operator is used. MySQL now
rewrites any predicate of this type internally as WHERE
during the
contextualization phase, so that the query resolver, query
optimizer, and query executor need work only with complete
predicates. The principal visible effect of this change is that,
for Boolean values, value
<> 0EXPLAIN
output now shows true
and
false
, rather than 1
and
0
.
(WL #12358)
InnoDB
parallel read thread performance for
large data sets was improved through better utilization of read
threads, through a reduction in read thread I/O for prefetch
activity that occurs during parallel scans, and through support
for parallel scanning of partitions.
The parallel read thread feature is controlled by the
innodb_parallel_read_threads
variable. The maximum setting is now 256, which is the total
number of threads for all client connections. If the thread
limit is reached, connections fall back to using a single
thread.
(WL #12978)
mysqlbinlog now supports the
--compress
(or
-C
) option to enable compression in the
client/server protocol.
(WL #2726)
NDB Cluster: Compile times for NDB Cluster using the included compile_cluster build script have been improved by removing options for software components not strictly necessary for running MySQL Cluster. (Bug #29355872)
NDB Cluster:
Attempting to change an NDB
table's
column properties (such as COLUMN_FORMAT
)
using
ALTER
TABLE ALGORITHM=INPLACE
was rejected, which is correct
behavior, but which raised a misleading error message.
(Bug #28929906, Bug #27645777)
InnoDB: A failure occurred when attempting to kill a process that was executing a row count. (Bug #29939617)
InnoDB:
Due to a regression introduced in MySQL 8.0.14, in-place upgrade
on a case sensitive file system from MySQL 5.7 or a MySQL 8.0
release prior to MySQL 8.0.14 to MySQL 8.0.16 failed for
instances with partitioned tables and
lower_case_table_names=1
. The
failure was caused by a case mismatch issue related to
partitioned table file names. The fix that introduced the
regression was reverted, which permits upgrades to MySQL 8.0.17
from MySQL 5.7 or MySQL 8.0 releases prior to MySQL 8.0.14 to
function as normal. However, the regression is still present in
the MySQL 8.0.14, 8.0.15, and 8.0.16 releases.
In-place upgrade on a case sensitive file system from MySQL
8.0.14, 8.0.15, or 8.0.16 to MySQL 8.0.17 fails with the
following error when starting the server after upgrading
binaries or packages to MySQL 8.0.17 if partitioned tables are
present and
lower_case_table_names=1
:
Upgrading from server versionversion_number
with partitioned tables and lower_case_table_names == 1 on a case sensitive file system may cause issues, and is therefore prohibited. To upgrade anyway, restart the new server version with the command line option 'upgrade=FORCE'. When upgrade is completed, please execute 'RENAME TABLEpart_table_name
TOnew_table_name
; RENAME TABLEnew_table_name
TOpart_table_name
;' for each of the partitioned tables. Please see the documentation for further information.
If you encounter this error when upgrading to MySQL 8.0.17, perform the following workaround:
Restart the server with
--upgrade=FORCE
to force the
upgrade operation to proceed.
Identify partitioned table file names with lowercase
partition name delimiters (#p#
or
#sp#
):
SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
For each file identified, rename the associated table using a temporary name, then rename the table back to its original name.
mysql> RENAME TABLEtable_name
TOtemporary_table_name
; mysql> RENAME TABLEtemporary_table_name
TOtable_name
;
Verify that there are no partitioned table file names with lowercase partition name delimiters (an empty result set should be returned).
mysql>SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES
->WHERE FILE_NAME LIKE '%#p#%' OR FILE_NAME LIKE '%#sp#%';
Empty set (0.00 sec)
Run ANALYZE TABLE
on each
renamed table to update the optimizer statistics in the
mysql.innodb_index_stats
and
mysql.innodb_table_stats
tables.
Because of the regression still present in the MySQL 8.0.14,
8.0.15, and 8.0.16 releases, importing partitioned tables from
MySQL 8.0.14, 8.0.15, or 8.0.16 to MySQL 8.0.17 is not supported
on case sensitive file systems where
lower_case_table_names=1
.
Attempting to do so results in a “Tablespace is missing
for table” error.
(Bug #29823032, Bug #29917793, Bug #95834)
References: This issue is a regression of: Bug #26925260.
InnoDB:
lock_sys
mutex contention caused by lock-wait
functions (lock_wait_suspend_thread()
and
lock_wait_table_release_slot()
) was reduced.
(Bug #29814339)
InnoDB:
The fseg_n_reserved_pages_low()
function,
which determines the number of pages reserved by a segment, did
not validate results read from the segment inode.
(Bug #29761998)
InnoDB:
Creation of the transaction rollback list
(hit_list
) was decoupled from lock
acquisition calls (lock_rec_lock
calls) to
permit the use of different latching schemes.
(Bug #29753800)
InnoDB:
Disabling Performance Schema consumers caused an
ALTER
TABLESPACE ... ENCRYPTION
operation to assert.
(Bug #29646974, Bug #95005)
InnoDB:
Error messages were revised to remove references to
.frm
files, which are not used in MySQL
8.0.
(Bug #29639655)
InnoDB: It was possible for a background thread to check the encryption status of an undo tablespace before the undo tablespace was fully initialized and the encryption flag set. (Bug #29600309)
InnoDB: A table name parsing function call returned false when parsing serialized dictionary information (SDI) tables names, which are not formatted to include a database name. The buffer that holds the database name remained uninitialized, causing Valgrind errors. (Bug #29550527)
InnoDB: The space reserved in the mini-transaction (mtr) log buffer for dynamic metadata logging was insufficient. (Bug #29524260)
InnoDB: Inaccuracies in the Contention-Aware Transaction Scheduling (CATS) implementation raised a signed integer overflow error in an UBSan build of MySQL. (Bug #29508517, Bug #91959)
InnoDB: Insufficient memory barriers in the rw-lock implementation caused deadlocks on ARM.
Thanks to Yibo Cai from Arm Technology for the contribution. (Bug #29508001, Bug #94699)
InnoDB:
The
INFORMATION_SCHEMA.INNODB_TABLESPACES
ENCRYPTION
column was not updated after
enabling undo tablespace encryption.
(Bug #29492911, Bug #94665)
InnoDB: A relocated table could not be accessed due to incorrect parsing of a schema or table name that included a forward slash character (/), which the server incorrectly interpreted as a directory separator. (Bug #29492113)
InnoDB:
Various fixes and revisions were applied to the
InnoDB
memcached source code.
(Bug #29485891)
InnoDB:
To enable global access, the value of
innodb_directories
variable is
now stored internally as a global variable instead of a static
variable.
(Bug #29471990)
InnoDB:
In debug builds, the thd_innodb_tmpdir()
function did not accept a NULL argument.
(Bug #29471846)
InnoDB: A subtraction operation in the file space allocation code incorrectly stored the result as an unsigned variable, which raised an assertion failure. (Bug #29466680)
InnoDB:
After moving or deleting default undo tablespaces and restarting
the server with a new
innodb_undo_directory
value,
MySQL recreated the undo tablespaces in the new location but
failed to update the undo directory path in the data dictionary.
(Bug #29461900)
InnoDB: A previously freed LOB page was accessed while rolling back a transaction during recovery. (Bug #29440408)
InnoDB: A request was issued during recovery to read pages into the buffer pool when there were no pages to be read. A check was added to avoid the unnecessary read request. (Bug #29440208)
InnoDB:
A regression introduced in MySQL 8.0.14 caused a “Invalid
(old?) table or database name” error when creating a
partitioned table on a MySQL instance with
lower_case_table_names=1
. The
change that caused the regression has been reverted.
(Bug #29426720, Bug #94519)
References: This issue is a regression of: Bug #26925260.
InnoDB:
A FULLTEXT
index table created in MySQL 5.6
in a database with a hyphen in its name caused a startup failure
after upgrading from MySQL 5.7 to MySQL 8.0. Tablespace file
paths for FULLTEXT
auxiliary tables were not
found in the data dictionary, and the hyphen in the database
name was not handled correctly in subsequently generated file
paths.
(Bug #29411899, Bug #94431)
InnoDB: There was potential for data loss to occur if the redo log was not logically empty and comprised a single block, and the server exited during recovery after an insert buffer merge generated new redo records but before the new records could be flushed to disk. (Bug #29411832, Bug #94448)
InnoDB:
InnoDB
returned an unknown generic error when
attempting to create a tablespace for which the path and file
name exceeded the MAX_PATH
limit on Windows.
InnoDB
now returns a more meaningful error.
(Bug #29341634)
InnoDB: An undo tablespace file was not found after being moved to a different directory. (Bug #29328158)
InnoDB:
The server failed to start with an
innodb_buffer_pool_size=default
setting. The default value was not checked for compatibility
with dependent system variable settings.
(Bug #29267814, Bug #94065)
InnoDB:
The CREATE
TABLESPACE ... ADD DATAFILE
clause no longer permits
circular directory references. For example, the circular
directory reference (/../
) in the following
statement is not permitted:
CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd 'any_directory
/../ts1.ibd';
An exception to this restriction exists on Linux, where a
circular directory reference is permitted if the preceding
directory is a symbolic link. For example, the data file path in
the example above is permitted if
any_directory
is a symbolic link. (It
is still permitted for data file paths to begin with
'../
'.)
To avoid upgrade issues, remove any circular directory
references from tablespace data file paths before upgrading to
MySQL 8.0.17 or higher. To inspect tablespace paths, query the
INFORMATION_SCHEMA.INNODB_DATAFILES
table.
(Bug #29157265)
InnoDB: Manually changing the system time while the MySQL server was running caused page cleaner thread delays. (Bug #29138644, Bug #93708)
InnoDB:
UPDATE
statements did not always
disable semi-consistent reads properly when encountering errors,
which could lead to assertion errors in debug mode.
(Bug #29047894)
InnoDB: When purging a deleted row, the logic that governs lock inheritance did not correctly determine the type of lock that should be inherited to satisfy constraint checks by active transactions. (Bug #29004362)
InnoDB:
An unnecessary read lock was taken on implicitly opened data
dictionary tables when executing a prepared statement in
LOCK TABLES
mode.
(Bug #28875646)
InnoDB:
During log application, after an OPTIMIZE
TABLE
operation, InnoDB
did not
populate virtual columns before checking for virtual column
index updates.
(Bug #28834208)
InnoDB: An operation that copied data from the clustered index was performed incorrectly, causing spatial indexes to use spatial rows with stale pointers to the clustered index. (Bug #28758961)
InnoDB:
An INSERT
operation involving a
generated virtual BLOB
column resulted a
secondary index being updated with an incorrect value.
(Bug #28652826)
InnoDB:
Configuring
innodb_data_file_path
and
innodb_temp_data_file_path
using SET
PERSIST_ONLY = default
incorrectly set the variable
values to NULL.
(Bug #28590014)
InnoDB:
A CREATE TABLE ...
REPLACE SELECT
operation raised a
lock_rec_get_rec_not_gap(lock)
assertion
failure. The operation set a flag on the transaction object
indicating that a REPLACE
operation was requested, but did not clear the flag before
updating dependent views, causing a subsequent
INSERT
operation to be
interpreted as a REPLACE
operation, leading to the wrong row locks being taken.
(Bug #28523025, Bug #92068)
InnoDB:
With super_read_only
enabled,
an attempted RENAME TABLE
operation on a temporary table raised an assertion instead of
returning an error.
(Bug #28490368, Bug #91975)
InnoDB: Valgrind errors were reported due to uninitialized bytes read during a virtual index prefix search. (Bug #28184025)
InnoDB:
InnoDB
initialization failed when attempting
to create an system tablespace greater than 2GB in size.
(Bug #27538464)
InnoDB: A full-text cache lock taken when data is synchronized was not released if the full-text cache size exceeded the full-text cache size limit. (Bug #25289359)
InnoDB:
The INNODB_METRICS
metadata_table_reference_count
counter
reported a negative value.
(Bug #20584149, Bug #75966)
InnoDB:
Client sessions using different
auto_increment_increment
values
while performing concurrent insert operations could cause a
duplicate key error.
(Bug #15851528, Bug #67526)
References: Reverted patches: Bug #14049391, Bug #65225.
Partitioning:
For partitioned tables, an ALTER
TABLE
statement could cause incorrect query results
under these conditions:
The statement swapped columns by renaming them, either
directly with RENAME COLUMN
or by
replacement with DROP COLUMN
/ADD
COLUMN
.
A swapped column was used in a partitioning expression.
The alteration was performed as an in-place operation that did not redistribute rows between partitions.
Such column renames are now prohibited unless the same
ALTER TABLE
statement satisfies
one of these conditions:
The statement makes the table nonpartitioned.
The statement redefines the table partitioning or partitioning expression (which causes a table rebuild that redistributes rows). This enables supporting existing scenarios in which partitioning expressions are updated to follow column renaming.
Partitioning is specified using PARTITION BY
KEY()
with an empty column list. This partitions
using the primary key, which tracks column renaming.
(Bug #29541665, Bug #94792)
Partitioning:
ALTER
TABLE ... EXCHANGE PARTITION
failed with the error
Non matching attribute 'ROW_FORMAT' between partition
and table when the partitioned table had partitions
using different row formats, even when the partition to be
exchanged used the same row format as the non-partitioned table.
(Bug #28687608)
Replication: When events generated by one MySQL server instance were written to the binary log of another instance, the second server implicitly assumed that the first server supported the same number of binary log event types as itself. Where this was not the case, the event header was handled incorrectly. The issue has now been fixed. Thanks to Facebook for the contribution. (Bug #29417234, Bug #94500)
Replication:
If a LOCK INSTANCE FOR BACKUP
statement was used to acquire an instance-level backup lock,
then a STOP SLAVE
statement was
issued, a deadlock could be created with the SQL thread waiting
on the backup lock and the STOP
SLAVE
statement waiting on the SQL thread to complete
its current action. To prevent this situation, the
STOP SLAVE
process now tries to
acquire the backup lock before proceeding, and returns an error
if the lock cannot be acquired.
(Bug #29386503, Bug #93649)
Replication:
From MySQL 8.0.13, if any replication channel has open temporary
tables, the binary logging format cannot be changed using
SET @@global.binlog_format
or SET
@@persist.binlog_format
. Previously, if this operation
was attempted after the new restriction was implemented, the
wrong error message was returned to the client (referencing a
running replication channel applier as the issue, rather than an
open temporary table). The appropriate error message is now
returned.
(Bug #29370024, Bug #94340)
Replication: Binary log checksums were handled incorrectly when de-serializing a format description event. (Bug #29355110)
Replication: With row-based replication in use, when the replication applier thread unpacked a row change event, index values for any functional indexes were calculated for both the “before” image and the “after” image. In the case of the “before” image, the values were not necessary. This calculation has therefore been removed for the before image in order to optimize row unpacking. (Bug #29304076)
Replication:
When a MEMORY
table is implicitly deleted on
a master following a server restart, the master writes a
DELETE
statement to the binary
log so that slaves also empty the table. This generated event
now includes a comment in the binary log so that the reason for
the DELETE
statement is easy to
identify. Thanks to Daniël van Eeden for the contribution.
(Bug #29157796, Bug #93771)
Replication:
If an invalid starting offset was provided in a
SHOW BINLOG
EVENTS FROM
statement, the invalid offset was returned
in place of the correct starting position for the first returned
event.
(Bug #29039732, Bug #93544)
Replication:
Replication could stop with a “record not found”
error when the value INDEX_SCAN,HASH_SCAN
(the default in MySQL 8.0) was set for the
slave_rows_search_algorithms
system variable, and an update event contained two updates to
the same row in a table that did not have a unique key, meaning
that the hash scan was used. In this situation, the second
update was missed by the hash scan due to the row change. Now,
after updating a row, the hash scan operation searches for the
updated row in the hash map, and applies any further update.
When the value TABLE_SCAN,HASH_SCAN
is set
for the
slave_rows_search_algorithms
system variable, so that the search cannot use an index, the
“record not found” error can occur in the above
situation whether or not the table has a unique key. Also, with
this setting, when a hash scan is used on a table that has a
unique key, in the case of an update event containing two row
updates that are order-dependent, the updates might be applied
out of order, causing replication to stop with a duplicate key
error. To avoid these issues, the documentation has been updated
to state that the value TABLE_SCAN,HASH_SCAN
should not be used.
(Bug #28846386)
Replication:
When binary logging is enabled on a replication slave, the
combination of the
--replicate-same-server-id
and
--log-slave-updates
options on
the slave can cause infinite loops in replication if the server
is part of a circular replication topology. (In MySQL 8.0,
binary logging is enabled by default, and slave update logging
is the default when binary logging is enabled.) However, the use
of global transaction identifiers (GTIDs) prevents this
situation by skipping the execution of transactions that have
already been applied. The restriction on this combination of
options has therefore now been removed when
gtid_mode=ON
is set. With any
other GTID mode, the server still does not start with this
combination of options. As a safeguard against creating the
problem situation after the server has started, you now cannot
change the GTID mode to anything other than
ON
on a running server that has this
combination of options set. Thanks to Facebook for the
contribution.
(Bug #28782370, Bug #92754)
Replication:
In query log events in the binary log, the thread ID used for
the execution of DROP TABLE
and
DELETE
statements was identified
incorrectly or not at all. On a multi-threaded replication
slave, where temporary tables were involved (which require the
correct thread ID as they are session specific), this omission
resulted in errors when using mysqlbinlog to
replay the binary log for point-in-time recovery. The thread ID
is now set correctly.
(Bug #28642318, Bug #92398)
Replication:
When a trigger invoked an INSERT
or
UPDATE
statement that set a column to its
default value, and the DEFAULT
expression of
that column was non-deterministic, the expected warning was not
raised when the trigger fired under statement-based replication.
In addition, if the binary logging format was
MIXED
, the non-deterministic statements were
logged in the format used for STATEMENT
rather than that used for ROW
.
The statement that causes the trigger to fire checks at
resolution time whether any of the triggered statements are
non-deterministic. At this time, the triggered statements have
been parsed, but not resolved, so the only check that can be
performed is whether the triggered statements directly reference
any non-deterministic operators. When the non-deterministic
operator is used by a DEFAULT
expression, the
non-determinism is not visible until the triggered statement has
been resolved, which happens when the trigger fires.
This is fixed by adding an extra check when determining the
logging format, where a statement is flagged as unsafe if any of
its substatements can write to a table that has a column with a
non-deterministic DEFAULT
expression. Since
it is not yet known at this point whether the
DEFAULT
expression will be used by the
substatement, this check flags the statement as unsafe even if
the substatement provides an explicit value for the column with
a non-deterministic DEFAULT
expression.
(Bug #28297486)
Replication:
When a slave server logs master status and connection
information to a table
(master_info_repository=TABLE
),
which is the default in MySQL 8.0, the
mysql.slave_master_info
table was not being
updated on shutdown if the server was in super read only mode
(super_read_only=ON
). No error
was written to the error log at this time, but replication
failed after server startup because the master log file and
master log position information was out of date. The thread that
updates the master info log at shutdown is now excluded from
read-only checks like other replication threads are, so it can
update the table even if the server is in super read only mode.
Error handling for a slave that is shutting down has also been
improved so that any failure to write to the slave status logs
results in an error in the error log.
(Bug #27675107, Bug #89987)
Replication:
If a replication slave tried to connect to the master using an
incorrect user name, host, or port, the original error message
specifying the reason for the connection failure was overwritten
with a generic message. The issue has now been corrected in the
output from the SHOW SLAVE STATUS
statement and in the Performance Schema table
replication_connection_status
.
(Bug #26580064)
Group Replication: When message fragmentation is in use for large Group Replication messages (which is available, and the default, from MySQL 8.0.16), if a fragmented message sent by the group member with the highest node identifier in XCom was partially delivered, and one or more members then left the group prior to the delivery of the remaining message fragments, reassembly of the message caused Group Replication to stop working. The loss of members meant that the node identifier of the original sender was no longer valid in the new view of the group. To correct this issue, reassembly of fragmented messages now uses the delivery information from the last fragment that was delivered, which reflects the new situation after the view change, rather than from the first fragment that was delivered, which reflects the old situation before the view change. (Bug #29716639)
Group Replication:
The error message that is issued for a discrepancy between the
number of group members and the auto-increment interval
incorrectly referred to the
group_replication_auto_increment_increment
system variable, instead of the
auto_increment_increment
system
variable. The value of
auto_increment_increment
is
changed to the value specified by
group_replication_auto_increment_increment
when Group Replication starts, but only if
auto_increment_increment
and
auto_increment_offset
have
their default values, and from MySQL 8.0, only in multi-primary
mode. The value of
auto_increment_increment
was
always the value that was checked for the error message, and it
has now been corrected to give the accurate system variable
name.
(Bug #29542425)
Group Replication:
Group Replication cannot be started following a MySQL Server
upgrade that uses the MINIMAL
option
(--upgrade=MINIMAL
), which does
not upgrade system tables on which this feature depends.
Previously, in this situation, the server waited indefinitely
for Group Replication to start. This is now handled correctly by
unblocking the waiting thread and issuing the expected error
ER_GRP_RPL_START_GRP_RPL_FAILED
.
(Bug #29423358, Bug #94515)
Group Replication: A change in the processing of suspicions by a member that is leaving the group meant that recovery failed because due to a circular dependency between the recovery failure and the view change notification. Now, if an error makes recovery impossible, the Group Communication System handles this as follows:
The member leaves the group
the view change is applied
The recovery thread is terminated.
(Bug #29417365, Bug #29628909)
Group Replication: In Group Replication, joining members could wrongly identify themselves as incompatible with an existing replication group even if there were members at the same version already in the group, because they checked against all other members, including the member at the highest version. Joining members also included their own version in the compatibility check. Now, joining members only compare themselves with the existing group member at the lowest version, and do not count their own version. (Bug #29390946, Bug #94429)
Group Replication: Functions for configuring an online group sometimes did not return an error when an issue arose during execution. These functions also now check whether the Group Replication plugin is stopping before they start to initialize. (Bug #28978767, Bug #93372)
Group Replication: The XCom group communication engine did not handle out of memory errors in an appropriate way. If memory could not be allocated to make a copy of the payload for a message, an error was logged but the message was still sent, with a null payload. The Group Communication System (GCS) on the receiving member discarded the message as empty, and the XCom instance on the receiving member accepted this action and did not retry, resulting in the message effectively being skipped. This caused the GTID set on the receiving member to diverge from the group, leading to replication errors. XCom now terminates gracefully if it experiences an out of memory error, so that this situation cannot occur. (Bug #28702320)
macOS: For macOS installations performed using DMG packages, launchd operation was problematic:
Previously, SHUTDOWN
caused a restart if
MySQL was configured to start at boot time via the
preference pane. This also affected the mysqladmin
shutdown command. Server shutdown initiated in
these ways now works correctly.
Previously, RESTART
did not work. It now
works correctly.
Previously, unexpected server exits did not cause automatic restart if the server was not configured to start at boot time. Exits with a nonzero exit status now cause a restart regardless of boot-time startup configuration.
(Bug #29789857)
JSON:
MAX()
and
MIN()
used on expressions
returning JSON
data sometimes
compared these values as strings rather than
JSON
values, which caused unexpected results;
this was particularly evident when the JSON
values were numbers.
This was due to the fact that GROUP BY
when
using temporary tables with indexes did not compare
JSON
values correctly.
(Bug #28947381)
JSON:
JSON_TABLE()
returned the error
Unknown database '' when executed from a
stored function.
The root cause of this issue was that, when merging tables from
a select that used JSON_TABLE()
, MySQL
checked only for derived tables. This caused the result table
returned by JSON_TABLE()
to be noted as a
regular table, so that when attempting to execute the query, the
server failed to open it. Now MySQL checks whether the table to
be added is not an internal table, that is, not a derived table,
a JSON_TABLE()
result table, or a reference
to a recursive common table expression.
(Bug #92976, Bug #28851656)
The WITH ADMIN
option for
GRANT
statements sometimes was
not handled properly.
(Bug #29900772)
Some foreign key error messages could differ depending on
whether the user had the GRANT
OPTION
privilege.
(Bug #29868844)
During upgrade operations, upgrades of the help tables failed if autocommit was disabled. (Bug #29865428, Bug #95620)
Fetching dynamically allocated dictionary objects into a vector
during upgrade while operating with a small
table_open_cache
size caused
data dictionary tables to be reopened, triggering a garbage
collection mechanism that incorrectly freed collected objects.
Subsequent attempts to access the freed objects caused a
segmentation fault.
(Bug #29823053)
For upgrades from MySQL 5.7 to 8.0, the upgrade process did not
close the innodb_*_stats_backup57.ibd
files
in the mysql
system schema before removing
them, resulting in errors for subsequent file system operations.
(Bug #29791350)
mysqld --initialize would fail if the file
system was mounted at the data directory mount point and a
lost+found
file or directory was present. The
lost+found
file or directory is now ignored
during data directory initialization.
(Bug #29780434)
MySQL upgrades did not assign the
AUDIT_ADMIN
privilege to accounts
that had the SUPER
privilege.
(Bug #29770732)
The REGEXP_REPLACE()
function did
not handle empty strings correctly in all cases.
(Bug #29763554)
An overly strict assertion could be raised during sorting of stored program local objects. (Bug #29759547, Bug #95062)
The
group_replication_get_communication_protocol()
function, which is used to query the group's communication
protocol version, failed if any group members were in RECOVERING
state, which was an unnecessary restriction. The function can
now be used provided that the member where it runs is in ONLINE
state, and is in contact with a majority of the group.
(Bug #29754967, Bug #95306)
For some arguments to REPEAT()
,
maximum length calculations were not always handled correctly.
(Bug #29739778)
UPDATE
statements for tables with
CHECK
constraints could fail to enforce the
constraints.
(Bug #29706621, Bug #95189)
For installation from RPM or Debian packages, if the
mysql_upgrade_info
file in the data
directory is found to exist but is owned by
root
, it is now changed to the same owner as
the data directory. The correct SELinux file context is also
set.
(Bug #29704041)
Installing from RPM packages could result in an error log with incorrect permissions. (Bug #29702462)
A replication group member that was unable to contact a majority
of the group before the
group_replication_unreachable_majority_timeout
setting was reached, and then exhausted the number of
auto-rejoin attempts specified by the
group_replication_autorejoin_tries
system variable without successfully rejoining, was sometimes
unable to carry out the action specified by the
group_replication_exit_state_action
system variable. The member tries to carry out the action using
the current session, which sometimes failed. The member now
ensures that the session is initialized before using it to
connect to the server to carry out the exit state action.
(Bug #29698754, Bug #95151)
When performing a upgrade, server-side SQL statements that update data dictionary tables used a non-default collation, causing an upgrade failure. (Bug #29697670, Bug #95144)
Starting the server with
--skip-grant-tables
and invoking
ROLES_GRAPHML()
could lead to a
server exit.
(Bug #29681975)
SELECT
DISTINCT
when using fixed-length keys did not
deduplicate records properly in all cases.
(Bug #29628699)
Client programs that used asynchronous C API functions could access freed memory after occurrence of a fatal error such as connection failure or receipt of a too-large packet. (Bug #29596244)
The
ST_AsWKB()
function could fail to perform proper error checking.
(Bug #29594287)
For failed data directory initialization, the server could produce a message indicating that the directory could be removed, even if the server itself did not create it. The message now indicates that only files in the directory created by the server can be removed. (Bug #29594082, Bug #94880)
In MySQL 8.0, the keyring_encypted_file
plugin could not read a file created by a MySQL 5.7
keyring_encypted_file
plugin.
(Bug #29588345)
In builds with Undefined Behavior Sanitizer enabled, runtime
errors occurred in my_strtoll10_mb2()
and
val_decimal()
.
(Bug #29585648, Bug #29594951)
Some diagnostics produced by the server while checking grant table structure at startup were written as errors rather than warnings. (Bug #29558993)
The comp_err utility could read uninitialized data. (Bug #29550442)
Enabling audit log encryption could cause a server exit. (Bug #29549327)
RPM package obsoletes were updated to enable successful upgrades from MariaDB to MySQL on EL8. (Bug #29549127, Bug #29623146, Bug #29623201, Bug #29659212)
In a join of the form LEFT JOIN t ON
, MySQL evaluated column
WHERE t.x=0 IS NOT
TRUEIS NOT TRUE
as FALSE
for a NULL
argument in a null-complemented row, and rejected it. This
caused an invalid conversion of the left join to an inner join,
so that there were missing rows in the result. The same issue
affected joins of the same form but having IS NOT
FALSE
in the WHERE
condition.
(Bug #29540230)
If the read_only
system
variable was enabled, its value improperly was applied against
updates to the character set and collation data dictionary
tables.
(Bug #29533590, Bug #94769)
The functions STATEMENT_DIGEST()
and STATEMENT_DIGEST_TEXT()
used
character_set_client
while
parsing the function's argument instead of the character set of
the argument.
(Bug #29526571)
The server now tracks data dictionary upgrades to ensure that
INFORMATION_SCHEMA
views are recreated when
data dictionary tables are changed.
(Bug #29513265)
Execution of STATEMENT_DIGEST()
or STATEMENT_DIGEST_TEXT()
could
have unintended side effects on data in the
performance_schema.events_statements_summary_by_digest
table.
(Bug #29512067)
The implementation for CREATE
TABLE
did not provide the table a clearly defined
starting cursor when no seeks or writes were performed.
(Bug #29511318)
When a table is const
optimized, any
predicate terms in the join's ON
condition
should also be evaluated on the tables marked as
const
to make sure that the row qualifies for
the ON
condition.
The optimizer failed to mark a table as const
when it was handled as having an impossible
ON
condition, in which case the resulting row
from this table is a NULL
extended row.
This fix sets the const_table
flag for the
table and marks the row as a NULL
row. It
also changes EXPLAIN
output for a table
optimized as having an impossible ON condition, where the
resulting NULL
values from this row are now
propagated into the rows column values, as with other
const
rows.
(Bug #29493830)
A query containing an IN
subquery could
return superfluous rows when
optimizer_switch
did not
include firstmatch=on
.
(Bug #29493026)
RPM package detection of whether the operating system is EL6 or EL7 failed on some systems. (Bug #29492896)
SQL layer validation of keys stored in storage-engine-private data fields in the data dictionary was disabled to permit storage engines to add new keys as required. Storage engines are now responsible for key validation. (Bug #29491593, Bug #94667)
Checks for NULL
returned an incorrect result
for some expressions comparing rows.
(Bug #29491083)
When optimizing a table join which included ORDER
BY
and LIMIT
, the optimizer
modified the select limit on the first table by taking the
fanout of the entire join into consideration. The fanout was
calculated using the filter_effect
for each
table, which can be set to COND_FILTER_STALE
(-1) to indicate an unknown value. This value was not actually
checked for by the optimizer, which could result in a negative
fanout, leading to an unexpected rows value of 0 in the
EXPLAIN
output for the query.
Now COND_FILTER_STALE
(filter_effect
unknown) is specifically
checked for, and, if it is found, the fanout is also assumed to
be unknown, and the number of rows to be selected from the first
table is thus not modified by the fanout for the entire join.
(Bug #29487181, Bug #29531472)
An implicit assumption was made for the
LEAST()
and
GREATEST()
functions that
arguments to either of these were all signed or all unsigned
values.
(Bug #29467577)
Some arguments for the BIT_OR()
function were not always handled correctly.
(Bug #29459549)
For debug builds, mishandling of the
user_attributes
column of the
mysql.user
system table could cause a server
exit.
(Bug #29451897)
MySQL Cluster-specific Debian debug packages had an incorrect path to the debug symbols. (Bug #29446947)
Compilation failure occurred when building with Protobuf 3.7.0. (Bug #29436791, Bug #94543)
On Debian and Ubuntu, MySQL packages did not enable
mysql.service
after upgrades from native
MySQL packages.
(Bug #29435592)
The server did not properly close shared-memory connections when an error occurred, which could result in unexpected server behavior. (Bug #29435426)
The internal JOIN_CACHE::join_record()
method
attempted to leave all tables on which it operated in the same
state with regard to the has_row
and
null_row
flags by saving the state upon entry
and restoring the appropriate flags when on completion.
The issue addressed here arose after these flags had been
restored, due to the fact that
restore_last_record()
was also called to
restore any records that had been processed, which could lead to
setting back a null_row
flag that had just
been restored based on the saved state. This is fixed by calling
restore_last_record()
before the saved states
are restored, rather than after, as well as making sure that
reset_null_row()
is also called if the saved
state indicates that the null_row
flag was
not set at the beginning.
(Bug #29435133)
Some ALTER TABLE
statements using
ADD COLUMN
did not perform as expected.
(Bug #29428288)
References: This issue is a regression of: Bug #28333657.
An incorrect error message was reported during upgrade from
MySQL 5.7 to MySQL 8.0 when a non-natively partitioned table was
encountered. The error message referenced the
-DWITH_PARTITION_STORAGE_ENGINE
CMake build option, which is not supported in
MySQL 8.0.
(Bug #29426632, Bug #94518)
At startup, the server did not properly check the length of user and host names in persisted variables. (Bug #29420141)
The parser could leak memory for certain multiple-statement queries. (Bug #29419820)
Installing MySQL on EL8 from RPM packages caused a conflict with the installed MeCab library. (Bug #29413115)
On FreeBSD, stack traces dumped for fatal signals did not work correctly. (Bug #29408039)
With the derived_merge
switch
disabled in the value of the optimizer_switch
system variable, information retrieved for base tables from
INFORMATION_SCHEMA.TABLES
displayed
inappropriate information in the
TABLE_COMMENT
column.
(Bug #29406053, Bug #94468)
In certain cases, use of ORDER BY
in a
subselect did not produce the expected result.
(Bug #29402943)
ROLLUP
queries with wildcards (and probably
also certain other wildcard queries) could cause assertion
errors.
(Bug #29396628)
A condition inside an IF
function having a
constant evaluating to TRUE
was not always
handled correctly.
(Bug #29394833)
A code change in MySQL 8.0.13 related to full-text search caused a segmentation fault. (Bug #29393105)
mysqlpump did not check whether the argument
to --result-file
was opened
correctly and exited unexpectedly if an error occurred.
(Bug #29389828)
In queries without joins, batch mode was not enabled until after
initialization was complete, so that OFFSET
rows were read outside of batch mode. This negated any
performance benefit to be had from batch mode.
(Bug #29373972)
When renaming a functional index, the server did not check for a possible duplicate index name. (Bug #29360763)
The system variable service did not check the input buffer size for some operations. (Bug #29343505)
For mysql
system schema dumps,
mysqlpump dumped certain tables by row rather
than as account-management statements.
(Bug #29343073)
Creation of a functional index on a UNION
subquery led to an assertion in debug builds.
(Bug #29342245)
Non-numeric arguments to AVG()
were not always handled correctly.
(Bug #29321764)
Result sets with a very large number of columns could cause
client programs to use all available memory. Now the client
library allocates no more than
max_allowed_packet
bytes for
result set metadata, returning an out-of-memory error if this
limit is exceeded. If this error occurs, it is fatal and the
client should disconnect.
(Bug #29316814)
A call to mysql_shutdown()
could
cause the client to exit when the server and client were from
different MySQL series, due to return packet payload
misinterpretation.
(Bug #29315393)
Client programs could fail while reading result set metadata if communicating with the server using the pre-MySQL 4.1 protocol. (Bug #29304864)
HANDLER
statements did not always
work correctly with tables having generated columns.
(Bug #29300049)
Session-tracking information in the client/server protocol could be mishandled. (Bug #29297652)
Client programs that used the libmysqlclient
C client library could exit upon receipt of an
OK
packet containing malformed
session-tracking information.
(Bug #29297620, Bug #29630735)
With the
PAD_CHAR_TO_FULL_LENGTH
SQL
mode enabled, password changes failed, with no warning or error
reported.
(Bug #29287785)
Initialization code of loadable functions for the
keyring_aws
plugin did not properly check
whether the plugin had been initialized.
(Bug #29278153)
Scalar subqueries were not always identified and handled correctly when compared with aggregate or window functions. (Bug #29276063)
Ubuntu packages did not disable binary logging for initialization scripts. (Bug #29263771)
The internal collation map could become corrupted by use of invalid collation names. (Bug #29258979)
Single-table UPDATE
and
DELETE
statements that used
indexed expressions could cause the server to exit when executed
as prepared statements.
(Bug #29257254)
The audit_log
plugin did not log
UNINSTALL
PLUGIN audit_log
statements.
(Bug #29248047)
MySQL now uses open(O_TMPFILE)
whenever
applicable when creating a temporary file that is immediately
unlinked. This is more efficient than previously and avoids the
small possibility of a race condition. Thanks to Daniel Black
for the contribution.
(Bug #29215177, Bug #93937)
audit_log
filtering operations could leak
memory.
(Bug #29201747)
The GRANT OPTION
privilege could
be mishandled in some cases.
(Bug #29179334)
Previously, LIKE
comparisons could
be incorrect if either of the _
or
%
SQL wildcard characters was used as the
ESCAPE
character. These characters can now be
used.
(Bug #29175461, Bug #93811)
The component_sys_variable
service could fail
to read certain system variables, causing a server exit.
(Bug #29162657)
Multiple-table UPDATE
statements
could search for incorrect generated-column values when
determining which row to update.
(Bug #29154379)
If the server was started with Performance Schema parameters that caused an out-of-memory condition, startup failed. (Bug #29140212, Bug #93726)
For consistency and compliance with standard SQL, the
ISNULL()
function is now printed
as IS NULL
in warnings generated by
EXPLAIN
statements.
(Bug #29119455)
Some supplemental Unicode characters could incorrectly be flagged with a warning message as invalid. (Bug #29110613, Bug #93626)
For upgrades from MySQL 5.7 to 8.0, the root
user was not given all dynamic privileges.
(Bug #29043233)
When using subpartitioning, table serialized dictionary information (SDI) was not stored in any tablespace file. (Bug #29020745, Bug #93499)
Privileges for dropping some Performance Schema tables were checked incorrectly. (Bug #29010031)
mysqldump failed to wrap SET NAMES
utf8mb4
and SET character_set_client =
utf8mb4
statements within version-specific comments,
which could cause compatibility problems.
(Bug #29007506, Bug #93450)
For a unique index created on one or more columns defined as
NULL
, the optimizer failed to handle joins
using that index as eq_ref
.
As part of this fix, late NULL
filtering is
now also performed to avoid treating comparisons with
NULL
as potential equality matches.
(Bug #28965762, Bug #29337233)
For debug builds, an assertion could be raised by string comparisons for which the expected and actual collation differed. (Bug #28960901)
The server did not handle correctly a subquery which, prior to
conversion to a semijoin, contained a merged derived table or
common table expression which in turn had a
WHERE
clause with an outer reference against
an indexed column.
(Bug #28955216)
A query that employed a derived table which included an
ORDER BY
was not always handled correctly.
(Bug #28942965)
When clients were terminated for inactivity exceeding the
wait_timeout
value, the message
written to the error log was unclear. Now
ER_NET_WAIT_ERROR
is written,
which is more specific about the cause of the problem. Thanks to
Mattias Jonsson for the contribution.
(Bug #28940167, Bug #93240)
Concurrent execution of FLUSH
PRIVILEGES
along with CREATE
USER
or ALTER USER
could cause the server to stall.
(Bug #28937018, Bug #93085)
CASE
statement comparisons that
relied on index prefix values could produce incorrect results.
(Bug #28934315, Bug #93215)
When adjusting the query cost after sort elimination to compensate for sorts that had not been considered in the original cost estimate, and the estimates could sometimes be too low, or even negative.
The sort cost is added to the total cost in
Optimize_table_order::consider_plan()
, and
subtracted from the total cost in
JOIN::optimize()
if it is found that sorting
is not needed.
If consider_plan()
finds that sorting is not
needed, it does not add the sort cost to the total cost, but
still records a sort cost in
JOIN::sort_cost()
, and this is set to the
sort cost of the candidate plan considered previously. Later,
JOIN::optimize()
saw that the
JOIN
object had an associated sort cost, and
subtracted that cost from the total cost, since it also sees
that no sort is needed. Since the sort cost came from a
candidate plan that was not the same as the chosen plan, the
estimate was incorrect.
The fix is to make consider_plan()
set
JOIN::sort_cost
to 0 if no sort cost is added
to the total cost, so that the mistaken adjustment of the cost
in JOIN::optimize()
is not performed.
(Bug #28884359)
Some GIS code failed to compile under Visual Studio 2017 15.5.6. (Bug #28861188)
References: This issue is a regression of: Bug #28842878.
Stored generated column values and indexes on virtual generated
columns were not correctly updated after columns on which these
generated columns depended were swapped using
ALTER TABLE
with RENAME
COLUMN
or CHANGE COLUMN
.
Renaming of base columns for generated columns, generated
defaults, and functional indexes is now prohibited unless the
same ALTER TABLE
statement
satisfies one of these conditions:
The statement removes the generated column, generated default, or functional index.
The statement updates the dependent expression in question. This enables supporting existing scenarios in which generation expressions are updated to follow base column renaming.
Restrictions on dropping columns on which generated columns, generated defaults, or functional indexes depend were relaxed in a similar way. (Bug #28772251, Bug #92727)
Base columns were not excluded from index-only access by a generated column. (Bug #28652733)
References: See also: Bug #29664369. This issue is a regression of: Bug #23169112.
SET
PERSIST_ONLY
did not properly handle the
version_tokens_session
system
variable.
(Bug #28542569)
For debug builds, improper error checking for
CREATE TABLE
statements could
cause an assertion to be raised.
(Bug #28490361, Bug #91976)
MySQL 5.7 supported foreign keys on InnoDB
tables with a parent key for which part of the referenced
columns were hidden, but MySQL 8.0 did not. MySQL 8.0 now
supports this capability.
(Bug #28480149, Bug #91952)
INSERT ... ON DUPLICATE
KEY UPDATE
did not consider privileges granted by
active roles.
(Bug #28395115)
For unloaded components, component options specified at startup
with a --loose-
prefix were not processed if
the component was later loaded at runtime.
(Bug #28341329)
Long passwords solicited interactively by client programs could fail to be null-terminated. (Bug #28121400)
When building MySQL, CMake
begins the process of downloading Boost
by
creating a zero-length tarball in the destination directory,
which is removed when the download is complete. If the download
was interrupted or timed out, the presence of this file
prevented CMake from attempting
to perform the download the time it was run. Now the zero-length
tarball, if present, is removed before the download is started.
(Bug #28089173)
A thread pool group could be blocked when a thread process tick time exceeded the maximum permitted value. The tick time now uses a larger data type to permit larger values. (Bug #28072609)
Privileges were not checked correctly for
ALTER USER ...
IDENTIFIED WITH ... BY
.
(Bug #27923149, Bug #29882299)
MySQL does not support OpenSSL session tickets, but did not set
the SSL_OP_NO_TICKET
flag to inform OpenSSL
of that. The flag is now set.
(Bug #27655493)
The audit_null
plugin did not properly check
for a null event record.
(Bug #27638290)
UpdateXML()
did not always free
memory properly in certain cases.
(Bug #27312862)
Empty values in the name
column of the
mysql.plugin
system table caused the server
to exit during startup.
(Bug #27302459)
The server did not properly check privileges for
CACHE INDEX
statements.
(Bug #26173827)
With the thread_pool
plugin enabled, the
Performance Schema status_by_thread
table contained no data.
(Bug #25933891)
The GRANT OPTION
privilege was
treated as related to database operations.
(Bug #25203933, Bug #34159579)
REPAIR TABLE
for
ARCHIVE
tables could result in a server exit.
(Bug #23304911)
If an INSTALL PLUGIN
statement
contained invalid UTF-8 characters in the shared library name,
it caused the server to hang (or to raise an assertion in debug
builds).
(Bug #14653594, Bug #23080148, Bug #27167197)
Logging to the mysql.slow_log
system table
could fail when values were to large for table columns. Now
logging proceeds on a best-effort basis, writing what
information can be provided. Otherwise, the row is discarded and
a message is written to the error log.
(Bug #11748692, Bug #37132)
A query using WHERE
failed with
error 1525 Incorrect DATE value on
Windows platforms.
(Bug #95780, Bug #29904751)date_column
LIKE
'year_value
'
References: This issue is a regression of: Bug #29368521.
A fix for a previous issue caused
YEAR
values to be treated as
unsigned, but this did not allow for possible negative values
arising during calculations involving subtraction, which could
lead to data truncation errors.
(Bug #95045, Bug #29668676)
References: This issue is a regression of: Bug #92209, Bug #28562930.
When working with derived tables with an aggregation which had zero input rows, the results of the aggregate functions were not properly copied into the temporary table. This caused incorrect results in cases where the derived table was evaluated multiple times, such as when performing a lateral join. (Bug #94721, Bug #29514504)
A window without a frame specification inheriting from a window
with an ORDER BY
yielded an incorrect result.
(Bug #94251, Bug #29328529)
The results returned by the functions
REGEXP_REPLACE()
and
REGEXP_SUBSTR()
used
UTF-16
rather than the character set and
collation of the expression searched for matches.
(Bug #94203, Bug #29308212)
A UNION ALL
query with
SUM(
was
processed very slowly compared to the same query using
constant
)SUM(
instead.
(Bug #93922, Bug #29227464)column
)
JSON_OBJECTAGG()
is
non-deterministic in the presence of duplicate keys unless the
window has ordering on the key, which is expected behavior, but
a key-value pair that was no longer in the window frame still
appeared in the result.
(Bug #93822, Bug #29175262)
LIMIT
was applied before
HAVING
in queries with subselects.
(Bug #93214, Bug #28934388)
References: This issue is a regression of: Bug #25466100.
A query involving GROUP BY
on a
TIMESTAMP
column resulted in a
duplicate entry for key
(ER_DUP_ENTRY
) error. This
problem arose when TIMESTAMP
values were
inserted into a table using a given setting for the time zone
and these values were later fetched after the time zone setting
had been changed, such that at least some of the inserted
TIMESTAMP
values occurred during the hour
that the time changed from standard to daylight time (DST) in
the new time zone, during which time the same
TIMESTAMP
value can exist twice. Now, when
the server would otherwise return the error DUPLICATE
ENTRY FOR KEY
'group_key
', if the
grouping involves a TIMESTAMP
column, it
instead raises the error Grouping on temporal is
non-deterministic for time zones having DST. Please consider
switching to UTC for this query.
In addition, it is suggested to set
explicit_defaults_for_timestamp
to ON
as well as one or more of
MODE_NO_ZERO_IN_DATE
,
MODE_NO_ZERO_DATE
, or
MODE_INVALID_DATES
as part of the server SQL
mode to help avoid this issue.
(Bug #90398, Bug #27970159)