MySQL 5.7 Release Notes
InnoDB; Partitioning: Support for placing table partitions in shared tablespaces is deprecated and will be removed in a future MySQL version. Shared tablespaces include the system tablespace and general tablespaces. For information about identifying partitions in shared tablespaces and moving them to file-per-table tablespaces, see Preparing Your Installation for Upgrade.
InnoDB:
Support for TABLESPACE =
innodb_file_per_table
and TABLESPACE =
innodb_temporary
clauses with
CREATE TEMPORARY
TABLE
is deprecated and will be removed in a future
MySQL version.
Binary packages that include curl
rather than
linking to the system curl
library now use
curl
7.60.0 rather than 7.45.0.
(Bug #28043702)
The zlib library bundled with MySQL has been upgraded from version 1.2.3 to version 1.2.11. MySQL implements compression with the help of the zlib library.
The zlib compressBound()
function in zlib
1.2.11 returns a slightly higher estimate of the buffer size
required to compress a given length of bytes than it did in zlib
version 1.2.3. The compressBound()
function
is called by InnoDB
functions that determine
the maximum row size permitted when creating compressed
InnoDB
tables or inserting rows into
compressed InnoDB
tables. As a result,
CREATE TABLE ...
ROW_FORMAT=COMPRESSED
or
INSERT
and
UPDATE
operations with row sizes
very close to the maximum row size that were successful in
earlier releases could now fail. For additional information, see
Changes in MySQL 5.7.
Microsoft Windows:
On Windows, MySQL Enterprise Edition distributions now bundle
the Cyrus SASL library files libsasl.dll
and saslSCRAM.dll
so that the LDAP
authentication plugins can use the
SCRAM-SHA-1
authentication method.
MySQL Enterprise Edition now provides data masking and de-identification capabilities, implemented as a plugin library containing a plugin and a set of user-defined functions. Data masking hides sensitive information by replacing real values with substitutes. MySQL Enterprise Data Masking and De-Identification functions enable masking existing data using several methods such as obfuscation (removing identifying characteristics), generation of formatted random data, and data replacement or substitution. For example:
mysql>SET @ssn = gen_rnd_ssn();
mysql>SET @masked_ssn1 = mask_ssn(@ssn);
mysql>SET @masked_ssn2 = mask_outer(mask_inner (@ssn,4,5,'A'), 3,0,'B');
mysql>SELECT @ssn, @masked_ssn1, @masked_ssn2;
+-------------+--------------+--------------+ | @ssn | @masked_ssn1 | @masked_ssn2 | +-------------+--------------+--------------+ | 980-31-2838 | XXX-XX-2838 | BBB-AA-2838 | +-------------+--------------+--------------+
For more information, see MySQL Enterprise Data Masking and De-Identification.
Replication:
Use the
group_replication_exit_state_action
option to configure how Group Replication behaves when a member
leaves the group involuntarily, for example when it is expelled
from the group due to an unstable network connection. When
group_replication_exit_state_action
is set to ABORT_SERVER
, upon exiting the
group unintentionally, the instance shuts MySQL down, and when
group_replication_exit_state_action
is set to READ_ONLY
the instance sets MySQL
to super read only mode instead and its state is set to
ERROR
.
Previously, file I/O performed in the I/O cache in the
mysys
library was not instrumented, affecting
in particular file I/O statistics reported by the Performance
Schema about the binary log index file. Now, this I/O is
instrumented and Performance Schema statistics are accurate.
Thanks to Yura Sorokin for the contribution.
(Bug #27788907, Bug #90264)
InnoDB:
An ALTER TABLE
operation that
added a primary key produced a segmentation fault.
(Bug #28395278)
References: This issue is a regression of: Bug #27753193.
InnoDB: A query that scanned the primary key of a table did not return the expected result. (Bug #28104394, Bug #91032)
InnoDB: A query interruption during a lock wait caused an error. (Bug #28068293)
InnoDB: An index record was not found when updating a secondary index defined on a generated column. (Bug #27968952)
InnoDB:
The update log applied as part of an online
ALTER TABLE
operation did not
take into account the computed value of the generated column in
the old row while updating the secondary index.
(Bug #27921932)
InnoDB: An unsupported DDL operation involving a foreign key constraint raised an assertion. (Bug #27912873)
InnoDB: An attempted foreign key check on a discarded table caused a segmentation fault. (Bug #27804668)
InnoDB:
An assertion was raised during an OPTIMIZE
TABLE
operation.
(Bug #27753193)
InnoDB: A foreign key constraint name was duplicated during a rename table operation, causing a failure during later query execution. (Bug #27545888)
InnoDB:
In a function called before the execution of a statement in a
stored procedure, a read and write operation on
trx->lock.start_stmt
was not protected by
a mutex.
(Bug #27325898)
InnoDB:
An error occurred during a DDL operation due to a mismatch in a
REDUNDANT
row format calculation that
determines the length of the online log.
(Bug #26375771)
InnoDB:
The location of the Innodb Merge Temp File that reported by the
wait/io/file/innodb/innodb_temp_file
Performance Schema instrument was incorrect.
(Bug #21339079, Bug #77519)
Partitioning:
When a
CREATE
TABLE ... PARTITION BY ...
statement failed due to an
invalid partition definition, the server did not remove any
partition files which might have been created prior to
encountering the invalid PARTITION
clause.
(Bug #27798708)
References: See also: Bug #88043, Bug #26945644.
Partitioning:
It was possible to perform
FLUSH TABLES FOR
EXPORT
on a partitioned table created with
innodb_file_per_table=1
after
discarding its tablespace. Attempting to do so now raises
ER_TABLESPACE_DISCARDED
.
(Bug #90545, Bug #27903881)
References: See also: Bug #80669, Bug #22899690.
Replication:
When the
binlog_group_commit_sync_delay
system variable is set to a wait time to delay synchronization
of transactions to disk, and the
binlog_group_commit_sync_no_delay_count
system variable is also set to a number of transactions, the
MySQL server exits the wait procedure if the specified number of
transactions is reached before the specified wait time is
reached. The server manages this process by checking on the
transaction count after a delta of one tenth of the time
specified by
binlog_group_commit_sync_delay
has elapsed, then subtracting that interval from the remaining
wait time.
If rounding during calculation of the delta meant that the wait time was not a multiple of the delta, the final subtraction of the delta from the remaining wait time would cause the value to be negative, and therefore to wrap to the maximum wait time, making the commit hang. The data type for the remaining wait time has now been changed so that the value does not wrap in this situation, and the commit can proceed when the original wait time has elapsed. Thanks to Yan Huang for the contribution. (Bug #28091735, Bug #91055)
Replication: An assertion was raised in debug builds because the MySQL server recorded a GTID consistency violation, but did not remove the record after the relevant statement failed to execute successfully. The handling of this situation has now been improved to ensure that the server checks at the end of a transaction whether a GTID consistency violation was produced by a failed statement, and if this is the case, restores the previous GTID consistency state. (Bug #27903831, Bug #90551)
Replication:
With GTIDs in use for replication, transactions including
statements that caused a parsing error
(ER_PARSE_ERROR
) could not be
skipped manually by the recommended method of injecting an empty
or replacement transaction with the same GTID. This action
should result in the slave identifying the GTID as already used,
and therefore skipping the unwanted transaction that shared its
GTID. However, in the case of a parsing error, because the
statement was parsed before the GTID was checked to see if it
needed to be skipped, the replication applier thread stopped due
to the parsing error, even though the intention was for the
transaction to be skipped anyway.
With this fix, the replication applier thread now ignores parsing errors if the transaction concerned needs to be skipped because the GTID was already used. Note that this behavior change does not apply in the case of workloads consisting of binary log output produced by mysqlbinlog. In that situation, there would be a risk that a transaction with a parsing error that immediately follows a skipped transaction would also be silently skipped, when it ought to raise an error. (Bug #27638268)
Replication:
When a RESET SLAVE
statement was
issued on a replication slave with GTIDs in use, the existing
relay log files were purged, but the replacement new relay log
file was generated before the set of received GTIDs for the
channel had been cleared. The former GTID set was therefore
written to the new relay log file as the
PREVIOUS_GTIDS
event, causing a fatal error
in replication stating that the slave had more GTIDs than the
master, even though the gtid_executed
set for
both servers was empty. Now, when RESET
SLAVE
is issued, the set of received GTIDs is cleared
before the new relay log file is generated, so that this
situation does not occur.
(Bug #27636289)
Replication: The master's receiver thread for semisynchronous replication held a mutex while reading acknowledgements from slaves, but the same mutex was required to add or remove a semisynchronous slave, causing those operations to be delayed by the acknowledgement activity. The issue has now been fixed by not acquiring the mutex to read the acknowledgements from slaves. (Bug #27610678, Bug #89370)
Replication:
Entries in the relay log info log (the
slave_relay_log_info
table) for the Group
Replication-specific channels
group_replication_applier
and
group_replication_recovery
were not being
cleared by a RESET SLAVE
or
RESET SLAVE
ALL
command.
(Bug #27411175)
Replication:
Automatic retrying of transactions on a replication slave, as
specified by the
slave_transaction_retries
system variable, was taking place even if the transaction had a
non-temporary error that would repeat on retrying or that
indicated wider issues. Now, transactions are only automatically
retried if there is either no error, or an error that is only
temporary.
(Bug #27373559, Bug #89143)
Replication:
Attempting to uninstall the plugin while
START GROUP_REPLICATION
executed
could result in unexpected behavior.
(Bug #25423650, Bug #91042, Bug #28088177)
Replication:
When FLUSH
statements for
specific log types (such as FLUSH SLOW LOGS
)
resulted in an error, the statements were still written to the
binary log. This stopped replication because the error had
occurred on the master, but did not occur on the slave. MySQL
Server now checks on the outcome of these
FLUSH
statements, and if an error
occurred, the statement is not written to the binary log.
(Bug #24786290, Bug #83232)
Replication:
The PASSWORD()
function, which produces a
hash of the password, was deprecated in MySQL 5.7 and removed in
MySQL 8.0. When a SET PASSWORD
statement that used this function was replicated from a MySQL
5.6 master to a MySQL 5.7 slave, or from a MySQL 5.7 master with
the
log_builtin_as_identified_by_password
system variable set to ON to a MySQL 5.7 slave, the password
hash was itself also hashed before being stored on the slave.
The issue has now been fixed and the replicated password hash is
stored as originally passed to the slave.
(Bug #24687073)
Replication:
If an ORDER BY
clause was used in retrieving
records from certain Performance Schema tables relating to
replication, an empty set was returned. The issue has now been
fixed.
(Bug #22958077, Bug #80777)
Replication:
When replication channels are used on a slave for multi-source
replication, a START SLAVE
statement that does not specify an individual channel (so
without the FOR CHANNEL
clause) should start
the I/O thread and the SQL thread for all of the channels on the
replication slave. However, if a RESET
SLAVE
statement was used on such a slave, a subsequent
START SLAVE
statement did not
start the non-default channels. Now, replication channels that
are deinitialized as a result of a RESET
SLAVE
statement, rather than as a result of an error
in the initialization process, are identified and are restarted
by a START SLAVE
statement that
applies to all channels.
(Bug #22809607)
Replication:
Issuing RESET SLAVE
on a
replication slave does not change any replication connection
parameters such as master host, master port, master user, or
master password, which are retained in memory. However, these
connection parameters are reset if you issue
RESET SLAVE
ALL
. Previously, if the slave
mysqld was restarted immediately after
issuing RESET SLAVE
(including a
server crash as well as a deliberate restart), the connection
parameters were reset as if
RESET SLAVE
ALL
had been used.
Now, when
master_info_repository=TABLE
is
set on the server (which is the default from MySQL 8.0),
replication connection parameters are preserved in the
crash-safe InnoDB
table
mysql.slave_master_info
as part of the
RESET SLAVE
operation. They are
also retained in memory. In the event of a server crash or
deliberate restart after issuing RESET
SLAVE
but before issuing START
SLAVE
, the replication connection parameters are
retrieved from the table and reused for the new connection.
If master_info_repository=FILE
is set on the server (which is the default in MySQL 5.7),
replication connection parameters are only retained in memory,
so the behavior remains the same as previously. If the slave
mysqld is restarted due to a server crash or
a deliberate restart immediately after issuing
RESET SLAVE
, the connection
parameters are lost. In that case, you must issue a
CHANGE MASTER TO
statement after
the server start to respecify the connection parameters before
issuing START SLAVE
.
If you want to reset the connection parameters intentionally,
you need to use
RESET SLAVE
ALL
, which clears the connection parameters. In that
case, you must issue a CHANGE MASTER
TO
statement after the server start to specify the new
connection parameters.
(Bug #20280946)
Replication:
Compilation warnings related to unused functions in
xdr_utils
have been reduced. Thanks to Zsolt
Parragi for the patch.
(Bug #91071, Bug #28099963)
Replication:
If the
group_replication_recovery_retry_count
variable was modified while the member was already making a
reconnection attempt, the connection attempt could enter an
infinite loop.
(Bug #91057, Bug #28092714)
Replication:
When
group_replication_group_seeds
contained a DNS based entry which resolved to its own local
address, Group Replication could not start.
(Bug #90483, Bug #27882096, Bug #28074929)
Microsoft Windows: On Windows, uninstallation of the MySQL Server MSI package through MySQL Installer produced a spurious popup window. (Bug #27463864)
On the Fedora 29 platform, OpenSSL 1.0.x is used to build
packages because OpenSSL 1.1.1 support is not ready. If you
build MySQL from source, it is recommended that you build using
the compat-openssl10-devel
package.
(Bug #28737143)
On the Fedora 29 platform, upgrading from MariaDB to MySQL 8.0.13 failed due to missing obsoletes. (Bug #28727698)
Address Sanitizer revealed SSL/Zlib link problems related to the
audit_log
plugin; these were corrected.
(Bug #28525431, Bug #92082)
Compilation failed for GCC 8 with MySQL configured to use some system libraries. (Bug #28471072, Bug #91914)
Concurrent INSERT
and
SELECT
statements on a
MERGE
table could result in a
server exit.
(Bug #28379285)
For UPDATE
and
DELETE
statements that produce an
error due to sql_safe_updates
being enabled, the error message was insufficiently informative.
The message now includes the first diagnostic that was produced,
to provide information about the reason for failure. For
example, the message may indicate that the
range_optimizer_max_mem_size
value was exceeded or type conversion occurred, either of which
can preclude use of an index.
Additionally: (1) Using EXPLAIN
for such statements does not produce an error, enabling users to
see from EXPLAIN
plus
SHOW WARNINGS
output why an index
is not used. (2) For multiple-table deletes and updates, an
error is produced with safe updates enabled only if any target
table uses a table scan.
(Bug #28145710, Bug #91080)
MySQL Server and test RPM packages were missing
perl-Data-Dumper
as a dependency.
(Bug #28144933, Bug #72926)
For the mysql client, the -b
short option was associated with two long options,
--no-beep
and
--binary-as-hex
. The
-b
option now is associated only with
--no-beep
.
(Bug #28093271)
The WITH_GMOCK
CMake option did not handle Windows path
names properly.
(Bug #28061409, Bug #90964)
Group lookups for LDAP authentication plugins could fail if the
user had insufficient privileges. Now, group search operations
bind again using root
credentials if those
are available.
(Bug #28016008)
Generated columns having indexes and that used a string function were not always populated correctly. (Bug #27973409)
Stored program definitions in mysqldump dump
files sometimes included the
NO_AUTO_CREATE_USER
SQL mode. Because that
mode has been removed in MySQL 8.0, loading such a dump file
into a MySQL 8.0 server failed. mysqldump now
removes NO_AUTO_CREATE_USER
from the
definition of dumped stored programs.
(Bug #27931181, Bug #90624)
Very long table keys were handled incorrectly on replication slaves. (Bug #27930505)
During server startup/shutdown, PID files could be mishandled. (Bug #27919254)
If flushing the error log failed due to a file permission error, the flush operation did not complete. (Bug #27891472, Bug #90505)
References: This issue is a regression of: Bug #26447825.
For MEMORY
tables, memory overflow errors
could occur.
(Bug #27799513)
When converting from a BLOB
(or
TEXT
) type to a smaller
BLOB
(or TEXT
) type, no
warning or error was reported informing about the truncation or
data loss. Now an appropriate error is issued in strict SQL mode
and a warning in nonstrict SQL mode.
(Bug #27788685, Bug #90266)
The severity of messages produced by the server about being unable to read key files has been escalated from INFORMATION to WARNING. (Bug #27737195)
Failure to create a temporary table during a
MyISAM
query could cause a server exit.
Thanks to Facebook for the patch.
(Bug #27724519, Bug #90145)
parser_max_mem_size
was
ineffective when parsing stored program definitions.
(Bug #27714748)
Some typos in server error messages were fixed. Thanks to Thomas Tsiakalakis for the contribution. (Bug #27688294, Bug #90048)
Host name resolution errors could cause the
audit_log
plugin to fail.
(Bug #27567003)
Unsuccessful connection attempts were not being written to the
error log when
log_error_verbosity=3
.
(Bug #27539838)
An earlier code cleanup caused FEDERATED
storage engine failures.
(Bug #27493633, Bug #89537)
References: This issue is a regression of: Bug #25943754.
An attempted read of an uncommitted transaction raised an assertion. (Bug #26876608)
ALTER TABLE ... REORGANIZE PARTITION ...
could result in incorrect behavior if any partition other than
the last was missing the VALUES LESS THAN
part of the syntax.
(Bug #26791931)
The audit_log
plugin could deadlock the
server.
(Bug #24353553)
Debug symbol packages are now included for all
apt
platforms (previously, they were only
available on Debian 9).
(Bug #24008883, Bug #27990381)
For InnoDB
tables, the storage engine API
could return incorrect values for the maximum supported key-part
length.
(Bug #20629014, Bug #76096)
Specifying the maximum possible value for a
YEAR
column failed when expressed
as a real constant such as 2155.0E00
or
2.15E3
.
(Bug #91226, Bug #28172538)
It was possible for a subquery that used a unique key on a column allowing NULL to return multiple rows. (Bug #88670, Bug #27182010)