This is a milestone release, for use at your own risk. Significant development changes take place in milestone releases and you may encounter compatibility issues, such as data format changes that require attention in addition to the usual procedure of running mysql_upgrade. For example, you may find it necessary to dump your data with mysqldump before the upgrade and reload it afterward.
Important Change: MySQL builds on Windows using Visual Studio now require Visual Studio 2013 or later. The previous requirement was Visual Studio 2010 or later. (Bug #18404381)
Important Change: The atomic-operations API was simplified to use only the existing GCC built-in implementation or platform-provided implementations (for Windows, Solaris), and to remove the custom mutex-based fallback implementation. The retained implementations are those able to use CPU-native atomics. This simplifies the atomics APIs and related code and deals with bugs resulting from the fallback implementation.
As part of this work, the (undocumented)
options were removed.
On platforms where native atomics are supported, this change introduces no issues. For other platforms, here are potential MySQL compilation issues, and solutions:
32-bit Linux variants that use GCC 4.1 will no longer work.
This includes Red Hat 5, which is a supported platform. The
solution to this problem is to use a new GCC or set the
-march compiler option. For example, use
GCC 4.4, which is available on Red Hat 5. For information
about specifying compiler options, see
There may be issues on unsupported platforms. For example, 64-bit PowerPC, 32-bit ARM, and 64-bit ARM will not compile with older compilers. The solution for these cases is to use GCC 4.7 or later.
CMake workarounds for older Mac OS X and XCode versions were removed. On Mac OS X, compilation always uses Clang, even for 32-bit builds.
Compilation on Mac OS X is now supported for Mac OS 10.8 and up, using XCode 5 and up. Compilation on older versions may work but is unsupported. (Bug #18510941)
Spatial Data Support
NULL if the argument contained nonsupported
GeometryCollection() returns all
the proper geometries contained in the argument even if a
nonsupported geometry is present.
The Open Geospatial Consortium guidelines document the use of open polygons (polygons where the start point is not equal to the end point) but the MySQL GIS implementation did not support them. Now MySQL supports open polygons: An open polygon is converted to a closed one by appending the starting point to the point sequence. Before:
SELECT AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))'));+---------------------------------------------------------------+ | AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))')) | +---------------------------------------------------------------+ | NULL | +---------------------------------------------------------------+
SELECT AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))'));+---------------------------------------------------------------+ | AsText(PolygonFromText('POLYGON((10 10,20 10,20 20,10 20))')) | +---------------------------------------------------------------+ | POLYGON((10 10,20 10,20 20,10 20,10 10)) | +---------------------------------------------------------------+
Functionality Added or Changed
Tablespace discovery during crash recovery is simplified.
Instead of reading the first page of all
*.idb files and checking the contents of
*.isl files before applying redo logs,
information that identifies
*.ibd files is
now available in file-based redo log records. This enhancement
eliminates scans on the file system prior to redo log
application, which can be a slow process on installations with a
large number of
*.ibd files. Additionally,
only tablespaces referred to in redo log records since the last
checkpoint are accessed.
parameter is now dynamic, allowing you to resize the buffer pool
without restarting the server. The resizing operation, which
involves moving pages to a new location in memory, is performed
in 1MB chunks by default. Chunk size is configurable using the
configuration option. You can monitor resizing progress using
When replicating from a master running a version earlier than
MySQL 5.6.0 to a slave running MySQL 5.6.0 or later, the slave
master_uuid value, which is the
server_uuid value from the
master_uuid value is unsupported
on the older master, and in such a replication situation could
become invalid on the newer slave. A check for empty
master_uuid now ensures that the slave uses
an empty value for
Global transaction identifiers (GTIDs) are now logged in a MySQL
system table whenever they are enabled on the server, which
lifts a previous requirement to use binary logging when
replicating with GTIDs. If binary logging is disabled, the
server stores the GTID for each transaction in the
mysql.gtid_executed table as the transaction
is executed. If binary logging is enabled, then, whenever the
binary log is rotated or the server is shut down, the server
also writes into the new binary log the GTIDs for all
transactions from the previous binary log.
mysql.gtid_executed table can
become filled with many rows with single-transaction GTIDs
having the same originating server and sequential transaction
IDs, the server compresses this table periodically whenever
GTIDs are enabled. You can control the frequency with which the
table is compressed by setting the
system variable. This variable's default value is 1000,
which means that compression of the table is applied following
each 1000 transactions. You can set the
executed_gtids_compression_period to 0 to
disable the compression altogether, but you should be aware that
doing this may cause the space required by this table to
increase significantly. (See
mysql.gtid_executed Table Compression.)
Compression of the mysql.gtid_executed table is performed by a
dedicated thread. You can obtain information about the state of
this thread in the Performance Schema
The new system variable
what happens if the server cannot write to the binary log, for
example, due to a file error. The default for
IGNORE_ERROR, meaning the server logs the
error, halts logging, and continues updates to the database.
Setting this variable to
the server halt logging and shut down the server if it can not
write to the binary log.
(Bug #51014, Bug #11758766)
The rwlock used for the
implementation is now instrumented for the Performance Schema.
The instrument name is
CMake support was updated to handle CMake version 3. (Bug #19001781)
The (undocumented) binary-configure.sh script has been removed from MySQL distributions. (Bug #18694238)
RHEL 4 is not supported for 5.7, so the
support-files/RHEL4-SElinux file was
The optimizer computes more accurate costs for semi-join materialization. (Bug #18558561)
Unused private fields reported by Clang's
-Wunused-private-field compiler warning option
thr_alarm.c were removed because they
contain dead code almost exclusively. The remaining live code
was moved to
my_alarm.c were also removed, and the code
from them that is actually used was moved to
CMake option was turned on by default for
debug builds and off for release builds, and
-Werror to be enabled when building with GCC.
This made it cumbersome to enable
certain conditions, such as when compiling with Clang.
MYSQL_MAINTAINER_MODE is on by default
when compiling debug builds with GCC, and
-Werror regardless of whether GCC or Clang is
-Werror with Clang can be done
simply by explicitly setting
-DMYSQL_MAINTAINER_MODE=1 when running
CMake. In addition, some compilation warnings
reported by Clang 3.4 were fixed, making it possible to build
the default debug build with
Optimizer trace output for range access in the
considered_access_path section has been
improved: Instead of always printing
"ref" for index lookup types,
"fulltext" is now printed.
The obsolete and unmaintained charset2html utility has been removed from MySQL distributions. (Bug #71897, Bug #18352347)
mysqld help text for
--general_log was clarified. Thanks to Andrew
Gaul for the patch.
(Bug #71463, Bug #18127243)
fill_help_tables.sql file that is used
to load server-side help table content now contains the
following statement to suppress binary logging and prevent table
contents from replicating to slaves:
Because help table content is specific to the a particular server version, this prevents loading incorrect content into the slaves, which do not necessarily run the same version of MySQL as the master. For more information, see Replication of Server-Side Help Tables. (Bug #69564, Bug #17015822)
The empty string provided for numeric or enumeration options
--port="") produced inconsistent
or confusing behavior. Such empty option values now are rejected
with an error.
(Bug #68055, Bug #16102788)
The mysqladmin flush-logs command now permits
optional log types to be given, to specify which logs to flush.
flush-logs command, you can
provide a space-separated list of one or more of the following
correspond to the log types that can be specified for the
FLUSH LOGS SQL
statement. Thanks to Daniël van Eeden for the patch.
(Bug #60878, Bug #12368203)
InnoDB tables was improved by
THR_LOCK locks. As a result of this
change, DML statements for
InnoDB tables that
previously waited for a
THR_LOCK lock will
wait for a metadata lock:
Explicitly or implicitly started transactions that update
any table (transactional or nontransactional) will block and
be blocked by
LOCK TABLES ... READ for
that table. This is similar to how
LOCK TABLES ...
Tables that are implicitly locked by
TABLES now will be locked using metadata locks
THR_LOCK locks (for
InnoDB tables), and locked using metadata
locks in addition to
THR_LOCK locks (for
all other storage engines). Implicit locks occur for
underlying tables of a locked view, tables used by triggers
for a locked table, or tables used by stored programs called
from such views and triggers.
Multiple-table updates now will block and be blocked by
LOCK TABLES ... READ
statements on any table in the update, even if the table is
used only for reading.
HANDLER ... READ for any storage engine
will block and be blocked by a concurrent
TABLES ... WRITE, but now using a metadata lock
rather than a
In the Performance Schema,
acquisitions and waits will be registered in the
metadata_locks table and for
wait/lock/metadata/sql/mdl events rather
than registered in the
table_handles table and for
Issues that went away as a result of these locking changes:
For debug builds, concurrent execution of
TABLES ... READ and a DML statement affecting the
InnoDB table might lead to
Found lock of type 6 that is write and read
locked warnings in the error log.
(Bug #42147, Bug #11751331)
CMake support was updated to handle the new directory layout for Sun C++ 5.13. (Bug #73034, Bug #19010286)
The mysql client now indicates whether
USE statements produced warnings.
(Bug #29965, Bug #11746951)
The deprecated mysqlbug, mysql_waitpid, and mysql_zap utilities have been removed from MySQL distributions.
The deprecated mysqlhotcopy utility has been removed from MySQL distributions. Alternatives include mysqldump and MySQL Enterprise Backup.
The Boost library now is required to build MySQL. Two new CMake options enable control over the library source location, and whether to download it automatically:
specifies the Boost library directory location. It is also
possible to specify the Boost location by setting the
WITH_BOOST environment variable.
specifies whether to download the Boost source if it is not
present in the specified location. The default is
For example, if you normally build MySQL placing the object
output in the
bld subdirectory of your
MySQL source tree, you can build with Boost like this:
mkdir bld cd bld cmake .. -DDOWNLOAD_BOOST=ON -DWITH_BOOST=$HOME/my_boost
This causes Boost to be downloaded into the
my_boost directory under your home
directory. If the required Boost version is already there, no
download is done. If the required Boost version changes, the
newer version is downloaded.
If Boost is already installed locally and your compiler finds the Boost header files on its own, it may not be necessary to specify the preceding CMake options. However, if the version of Boost required by MySQL changes and the locally installed version has not been upgraded, you may have build problems. Using the CMake options should give you a successful build.
The custom rwlock implementation for Windows was replaced with standard Windows API calls. As a result of this change, Windows binaries require Windows 7 / Windows Server 2008 R2 or newer. In particular, Windows binaries no longer work on Windows Vista or Windows Server 2008 (plain, not R2).
system variable has been removed.
When processing the dump thread, a semisynchronous replication
master checked whether or not the dump thread came from a
semisynchronous slave by checking the value of
but did so for every operation performed on this thread, which
had significant negative impact on performance. Now this check
is made only once, when the dump thread is started, which should
noticeably improve the performance of semisynchronous
replication in most cases.
Important Change; Partitioning:
ALTER TABLE statement, the
REBUILD with the name of a
subpartition as valid syntax even though the
REBUILD keyword in this case did nothing. Now
REBUILD is rejected in such cases, and causes
the statement to fail with an error.
(Bug #19075411, Bug #73130)
References: This bug is a regression of Bug #14028340, Bug #65184.
Important Change; Replication:
DROP TABLE statement may be
divided into multiple statements before it is sent to the binary
log if it contains regular (not temporary) tables and temporary
tables, or if it contains temporary tables using both
transactional and non-transactional storage engines. Now, when
DROP TABLE statements affecting
these combinations of tables are no longer allowed unless the
value of the
AUTOMATIC. This is because, with
GTIDs enabled on the server, issuing a
TABLE in the cases just described while having only
one GTID associated with each statement (the SQL thread does
causes problems when there are not enough GTIDs for assignment
to all the resulting statements following the division of the
DROP TABLE statement might be split due to
the behavior of the statement with respect to the current
transaction varying, depending on table characteristics, as
DROP TABLE of a regular (not temporary)
table is committed immediately
DROP TABLE of a temporary table using a
transactional storage engine is committed with the current
DROP TABLE of a temporary table that uses
a nontransactional storage engine is committed immediately
Naming all three of these types of tables in a single
DROP TABLE statement causes the MySQL server
to divide the original statement into three separate
DROP TABLE statements in the binary log. If
GTIDs are enabled but the value of
AUTOMATIC, issuing a
TABLE statement that mixes any of the table types
described previously causes the server to have an insufficient
number of GTIDs to write with all of the resulting statements
into the binary log. In addition,
DROP TABLE IF
EXISTS is always written in the binary log for all
tables specified in the statement, even if some or all of the
tables do not exist.
Because temporary tables are handled differently by
DROP TABLE depending on whether they use a
transactional or nontransactional storage engine, any tables
named by a
DROP TEMPORARY TABLE statement
that do not exist are assumed to be transactional. This means
that, if a
DROP TEMPORARY TABLE with two
nontransactional temporary tables is issued on the master, it
would writes only one
DROP TABLE statement
naming both tables. If one of the temporary tables no longer
exists on the slave, then, when the SQL thread executes the
statement, it tries to divide it into multiple statements due to
it affecting a nontransactional (but existing) temporary table
and a nonexistent transactional temporary table; this leads to
problems because the SQL thread has only one GTID for the
DROP TABLE statement but must write
DROP TABLE statements in the binary log.
In addition, when the slave dropped temporary tables after
detecting that the master had restarted, it logged one
DROP TABLE statement per pseudo-thread and
per database, but combined temporary tables using transactional
and nontransactional storage engines in a single
Now, we throw an error in the client session if
gtid_next is set to a
value and a
DROP TABLE statement is issued
mixing any of the table types described previously.
In addition, we now group the nonexistent temporary tables and assume them to be transactional only if at least one transactional temporary table is dropped by the statement. If no transactional temporary tables are dropped, any nonexistent temporary tables are assumed to be nontransactional temporary tables.
The slave now also handles dropping of temporary tables correctly in the event of the restart by the master. (Bug #17620053)
Important Change; Replication:
The maximum length that can be used for the password in a
CHANGE MASTER TO statement is 32
characters. Previously, when a longer password was employed, it
was accepted, but any excess length was silently truncated by
the server. Following this fix, when the password's length
exceeds 32 characters,
CHANGE MASTER TO fails
with an error.
(Bug #11752299, Bug #43439)
With a transaction isolation level less than or equal to
READ COMMITTED, gap locks were not taken when
scanning a unique secondary index to check for duplicates. As a
result, duplicate check logic failed allowing duplicate key
values in the unique secondary index.
References: This bug is a regression of Bug #16133801.
InnoDB: Improved error handling, diagnostics, and test coverage related to crash recovery error handling. (Bug #19145637, Bug #73179)
Improved error handling for calls to
References: This bug is a regression of Bug #16802288.
CMake option is removed in MySQL 5.7.5. This
option was enabled by default but could be disabled for systems
that do not support atomics. As of MySQL 5.7.5, support for
atomics is required to build MySQL, making the
A race condition that occurred when dynamically disabling
caused the purge thread to assert.
In debug builds, an invalid
RW_NO_LATCH assertion would cause the server to halt.
A code comment for the
(Bug #18940008, Bug #72919)
InnoDB: Added debug assertions to the adaptive hash index code to check that the tablespace ID in buffer blocks match the index space. (Bug #18965518, Bug #72986)
InnoDB: During recovery, a segmentation fault would occur when marking a table as corrupt. (Bug #18942294)
trx_cleanup_at_db_startup failed to reset
trx->rsegs->m-redo content in debug
Removed unused function definitions and declarations from the
InnoDB memcached API.
(Bug #18815992, Bug #72723)
script would fail after running the
mysql_secure_installation script, which
removes the MySQL
test database. The
innodb_memcached_config.sql script now
test database if it does not
(Bug #18816381, Bug #72678)
InnoDB: Opening a parent table that has thousands of child tables could result in a long semaphore wait condition. (Bug #18806829)
A regression introduced by the fix for Bug #11758237 resulted in
InnoDB: For single item full-text searches, deleted documents were included inverse document frequency (IDF) calculations. (Bug #18711306, Bug #72548)
On mysqld start, specifying multiple data
files using the
would return a Space id in fsp header
error after data is written to the second file.
page_create function has been optimized
to use simpler functions to initialize pages.
References: This bug is a regression of Bug #16963396.
DELETE operation on a table with full-text
search indexes raised an assertion.
References: See also Bug #14639605.
When calling the memcached
attempts to initialize a connection and a transaction. If the
transaction is in
InnoDB would fail to set
CONN_DATA->CRSR_TRX to NULL, resulting in
a serious error.
InnoDB is built as a shared library,
attempting to load the
INFORMATION_SCHEMA plugin would
fail with a Can't open shared library
(Bug #18655281, Bug #70178)
On startup, with
page cleaner thread would raise a
srv_get_active_thread_type() == SRV_NONE
debug assertion when encountering an active master thread.
After upgrading from 5.6.10 to MySQL versions up to and
including MySQL 5.6.18,
InnoDB would attempt
to rename obsolete full-text search auxiliary tables on server
startup, resulting in an assertion failure.
(Bug #18634201, Bug #72079)
References: This bug is a regression of Bug #13975225.
INSERT operation on a table with
GEOMETRY columns raised an assertion in
The temporary tablespace file (
held open by the
page_cleaner thread and
could not be removed on startup, resulting in a hang.
InnoDB would try to merge a b-tree change
buffer for a dedicated undo tablespace.
A regression introduced in MySQL 5.6.5 would cause full-text
search index tables to be created in the system tablespace
(space 0) even though
DB_LOCK_WAIT during a foreign key check
caused redundant delete marking, resulting in a failing
os_event_wait_time_low function would
the sync time has elapsed.
SELECT on a partitioned table
caused a memory access violation in
References: See also Bug #18167648.
UNIV_SYNC_DEBUG enabled, a late call to
sync_check_enable() would result in an
m_enabled assertion failure.
InnoDB would write to the redo log for an
IMPORT TABLESPACE operation before the
tablespace import was complete.
plugin would call
lock_plugin mutex. This bug fix
also addresses a race condition in
With persistent statistics enabled,
TABLE STATUS output and the
TABLE_ROWS column of
INFORMATION_SCHEMA.TABLES could report an
incorrect number of tables rows for tables with externally
Added the C++
ostream mechanism for error
InnoDB: Code quality improvements for the redo log subsystem. (Bug #18345004)
InnoDB: The fix for Bug#17699331 caused a high rate of read/write lock creation and destruction which resulted in a performance regression. (Bug #18345645, Bug #71708)
InnoDB: A regression introduced by the fix for Bug#18069105 could result in a table corruption and failing assertions. (Bug #18368345)
The data file was not opened prior to calling
in an assertion failure.
variable, which was only used in a diagnostic error message.
buf_pool->flush_rbt, which is only
intended to be used for recovery, would be allocated for
database creation and never freed.
sched_getcpu would cause page
ib_heap_resize failed to verify that
new_size is greater than or equal to
old_size before calling
After crash recovery and with
enabled, purge would fail with a
buf_pool_from_bpage(bpage) == buf_pool
For each insert,
memset would be called three
times to allocate memory for system fields. To reduce CPU usage,
memset calls are now combined into
a single call.
(Bug #17858679, Bug #71014)
Assertion code in
buf0buf.ic was too restrictive.
The fix for Bug#16418661 added superfluous
buf_flush_list() logic to
InnoDB startup code.
(Bug #17798076, Bug #70899)
A problem renaming temporary tables during an
TABLE operation would raise an assertion and print a
warning to the error log. Temporary table names were not
ALTER TABLE operations
requiring a table rebuild would sort the clustered index even
though the primary key order remained unchanged. This behavior
caused unnecessary temporary table usage and I/O.
A race condition in
resulted in Duplicate FTS_DOC_ID and
Cannot find index FTS_DOC_ID_INDEX in InnoDB index
translation table errors.
(Bug #17447086, Bug #70311)
References: See also Bug #16469399.
InnoDB Table Monitor would
result in a
(Bug #17039528, Bug #69641)
Redo log writes for large, externally stored
BLOB fields could overwrite the most recent
checkpoint. The 5.6.20 patch limits the size of redo log
BLOB writes to 10% of the redo
log file size. The 5.7.5 patch addresses the bug without
imposing a limitation. For MySQL 5.5, the bug remains a known
As a result of the redo log
write limit introduced for MySQL 5.6,
innodb_log_file_size should be
set to a value greater than 10 times the largest
BLOB data size found in the rows
of your tables. Failing to do so could result in “Row size
too large” errors. No action is required if your
innodb_log_file_size setting is
already 10 times the largest
data size or your tables contain no
(Bug #16963396, Bug #19030353, Bug #69477)
The error log message that is printed on
CREATE TABLE when the number of
TEXT fields exceed the row size
limit did not provide sufficient information. The error message
now provides the maximum row size, current row size, and the
field that causes the maximum row size to be exceeded.
(Bug #16874873, Bug #69336)
Inserting a record into an
InnoDB table with
a key that falls between the maximum key of a full page and the
minimum key of the “next” page could result in
unnecessary page splits and under-filled pages. If the insert
point is at the end of a page,
attempts to insert to the next page before splitting the page.
(Bug #15923864, Bug #67718)
buffer pool flushing would not be initiated until the percentage
of dirty pages reached at least 1%, which would leave up to 1%
of dirty pages unflushed.
(Bug #13029450, Bug #62534)
InnoDB: Due to differences in memory ordering on different processor types, some mutex and read-write lock flags were not read consistently. (Bug #11755438, Bug #47213)
InnoDB would allow an index
required by a foreign key constraint to be dropped, thereby
placing the table into an inconsistent state. Dropping an index
required by a foreign key constraint should not be permitted.
(Bug #70260, Bug #17449901)
(enabled by default) or the
flag was enabled by the setting of the
variable, queries returned incorrect results when executed
against partitoned tables that used the
MyISAM storage engine, as well as
InnoDB tables that
lacked a primary key.
References: See also Bug #16862316, Bug #17588348, Bug #17648468.
Selecting from a table having multiple columns in its primary
key and partitioned by
R was the last (rightmost) column
listed in the primary key definition, returned an incorrect
(Bug #17909699, Bug #71095)
Replication: Removed an unnecessary write lock that was taken by an internal function while adding a GTID to a GTID set, which should improve the performance of the function and the code dependent on it during such operations. (Bug #18963555, Bug #72977)
ALL did not clear
IGNORE_SERVER_IDS, although this statement
should clear any values that are set by
CHANGE MASTER TO. Now
RESET SLAVE ALL always empties the list of
server IDs to ignore, whenever it is executed.
Replication: The same internal function had effects which caused three similar problems when resetting or starting slaves. These three issues are listed here:
RESET SLAVE automatically set
SSL_VERIFY_SERVER_CERT to the default.
When a server was not configured as a slave (that is, when
CHANGE MASTER TO statement
had yet been executed), the subsequent failure of
START SLAVE was expected but
had the unintended side effect of resetting the heartbeat
period to the default.
The function has been rewritten such that code affecting
heartbeat or SSL certificate usage has been eliminated or moved
to a more appropriate location, eleminating the side effects
formerly seen with
RESET SLAVE or a failed
As part of this fix, in order to be able to keep heartbeats
enabled by default when changing the master, if host and port
are given but the heartbeat period is not specified in a
CHANGE MASTER TO statement, we force it to
the default value.
(Bug #18791604, Bug #18778485, Bug #18777899)
Semi-synchronous replication did not work as expected when the
variables were set. The values of the variables were changed,
but the related internal status was not updated during
(Bug #18835117, Bug #18466390)
--raw did not check for
errors caused by failed writes, which could result in silent
corruption of binary logs. Now in such cases it stops with an
(Bug #18742916, Bug #72597)
Replication: When a slave worker thread tried to execute a statement that was too large, the resulting error caused a crash. Now in such cases, the error is truncated to fit the size of the buffer. (Bug #18563480)
Log rotation events could cause
group_relay_log_pos to be moved forward
incorrectly within a group. This meant that, when the
transaction was retried, or if the SQL thread was stopped in the
middle of a transaction following one or more log rotations
(such that the transaction or group spanned multiple relay log
files), part or all of the group was silently skipped.
This issue has been addressed by correcting a problem in the logic used to avoid touching the coordinates of the SQL thread when updating the log position as part of a relay log rotation whereby it was possible to update the SQL thread's coordinates when not using a multi-threaded slave, even in the middle of a group. (Bug #18482854)
When using row-based replication, updating or deleting a row on
the master that did not exist on the slave led to failure of the
slave when it tried to process the change. This problem occurred
InnoDB tables lacking a
(Bug #18432495, Bug #72085)
When replicating from a MySQL 5.5 or earlier master to a MySQL
5.6 or later slave, the
SOURCE_UUID column of
table contained random data. Now in such cases,
SOURCE_UUID is left blank.
Replication: During relay log initialization, the thread context was used as a flag for the reconstruction of the retrieved GTID set, an operation that does not depend on this parameter. This could be problematic if relay log initialization was called in another context other than the legacy replication scenario; if the invocation was made in a context where the thread context was always present, this prevented the set's reconstruction. The opposite could also happen when the thread context was not present, which cause the initialization to be performed twice.
To avoid such issues, the thread context flag is replaced with a new flag that allows the reconstruction in all contexts but prevents multiple invocations. (Bug #18337036)
When mysqlbinlog processed multiple binary
log files into a single output file, this file was not in a
useful state for point-in-time recovery, when it failed with the
error, When @@SESSION.GTID_NEXT is set to a GTID, you
must explicitly set it to a different value after a COMMIT or
ROLLBACK. Please check GTID_NEXT variable manual page for
detailed explanation. Current @@SESSION.GTID_NEXT is
mysqlbinlog processes a binary log containing
GTIDs, it outputs
gtid_next statements, but
gtid_next is set to undefined whenever a
commit occurs; this left
when the server had finished processing the output from
mysqlbinlog. When the next binary log file
started with one or more anonymous statements or transactions,
the combination of gtid_next being left undefined at the end of
the first binary log and the second binary log containing
anonymous transactions to the error described previously (Error
To fix this issue, now, whenever mysqlbinlog
encounters this situation, it inserts
SET gtid_next =
AUTOMATIC if required to avoid leaving the previous
binary log with
In addition, as a result of this fix, mysqlbinlog no longer outputs session variable information for every binary log; now, this value is printed only once unless it changes. (Bug #18258933, Bug #71695)
Quotation marks were not always handled correctly by
INFILE when written into the binary log.
(Bug #18207212, Bug #71603)
In certain cases, the server mishandled triggers and stored
procedures that tried to modify other tables when called by
TABLE ... SELECT. This is now handled correctly as an
When used on a table employing a transactional storage engine, a
TRUNCATE TABLE was still
written to the binary log and thus replayed on the slave. This
could lead to inconsistency when the master retained data that
was removed on the slave.
Now in such cases
TRUNCATE TABLE is logged
only when it executes successfully.
(Bug #17942050, Bug #71070)
Beginning in MySQL 5.6.20, when a user specified
AUTO_INCREMENT value falls outside of the
range between the current
value and the sum of the current and number of rows affected
values it is replicated correctly. In previous versions, an
error was generated by the slave even if the user specified
AUTO_INCREMENT value fell outside of the
(Bug #17588419, Bug #70583)
Replication: A group of threads involved in acquiring locks could deadlock when the following events occurred:
Dump thread reconnects from slave; on master, a new dump
thread tries to kill zombie dump threads; having acquired
LOCK_thd_data, it is
about to acquire
Application thread executing show binary logs, having
LOCK_log and about to acquire
Application thread executing
LOGS; having acquired
LOCK_index, it is about to acquire
Application thread executing
SELECT * FROM
INFORMATION_SCHEMA.PROCESSLIST), having acquired
LOCK_thread_count and about to acquire
the zombie dump thread's
This leads to the 4 threads deadlocking in the same order which the threads have been listed here.
This problem arises because there are ordering rules for
as well as rules for ordering
LOCK_thd_data, but there are no rules for
ordering across these two sets of locks. This was because the
SHOW PROCESSLIST acquired
LOCK_thread_count for the complete lifetime
of the function as well as acquiring and releasing each
LOCK_thd_data. Now this
function takes a copy of the threads from the global thread list
and performs its traversal on these, and only after releasing
LOCK_thread_count. During this traversal,
removal from the global thread list is blocked using
LOCK_thd_remove such that the copies that
would otherwise be destroyed by the removal remain valid during
traversal. The locking order following this fix is shown here:
LOCK_thd_remove -> LOCK_thd_data -> LOCK_log -> LOCK_index -> LOCK_thread_count
(Bug #17283409, Bug #69954)
Replication: On Windows, mysqldump failed if the error log file was deleted (missing) from the active MySQL server. (Bug #17076131)
When the binary log was rotated due to receipt of a
SIGHUP signal, the new binary log did not
Previous_gtid_event required for
subsequent processing of that binary log's GTID events. Now
SIGHUP is received, steps are taken to
insure that the server writes the necessary
Previous_gtid_event to the new log before
writing any GTID events to the new log.
Replication: When using row-based replication, running a long transaction involving a large number of events could trigger an Out of Memory (OOM) error if the slave's table structure was not compatible with the master's table structure. Such an incompatible situation could occur if the table on the slave had been manually changed, or when replicating between different MySQL versions that have different data types. This OOM error was caused because the virtual temporary tables created for the row conversion were not being freed until the end of the transaction, which was a problem when replicating large numbers of events.
Starting with this version, such virtual tables are correctly freed during the conversion process. (Bug #72610, Bug #18770469)
Client applications should be able to set the
BINLOG_DUMP_NON_BLOCK flag in the initial
handshake packet (
connecting to a server issuing a
COM_BINLOG_DUMP with the flag unset do not
get an EOF when the server has sent the last event in the binary
log, which causes the connection to block. This flag, which was
removed in error in MySQL 5.6.5, is now restored in the current
As part of this fix, a new
option is added to mysqlbinlog. This option
can be used by the client to test a MySQL server for the
presence of this issue.
(Bug #71178, Bug #18000079)
gtid_mode=ON, and a
transaction is filtered out on the slave, the GTID of the
transaction is still logged on the slave as an
“empty” transaction (consisting of a GTID followed
BEGIN and then
COMMIT). This is necessary to
prevent the transaction from being retransmitted the next time
the slave reconnects or is involved in a failover. The current
fix addresses two issues relating to such “empty”
(Bug #71376, Bug #18095502, Bug #18145032)
Performance Schema memory instrumentation did not honor the
ENABLED flag in the
setup_instruments table or the
consumers in the
table. This has been corrected, with the result that unnecessary
statistics are not collected and overhead is reduced.
SELECT included a derived table in a
join in its
FROM list and the
SELECT list included
COUNT() returned 1 even if the underlying
result set was empty.
References: This bug is a regression of Bug #11760197.
Enabling optimizer trace could cause a server exit for queries
with a subquery in a
Conversion failure of “zero” dates in strict SQL mode could cause a server exit. (Bug #18840123)
SHA and MD5 functions failed for operations using the internal
filename character set and could cause a
Modulo operations on
values in some cases could overflow and cause a server exit.
Spatial operations on
InnoDB tables could
fail attempting to access nonexistent index statistics.
Passing bad arguments to
could cause a server exit.
Using an outer reference in a
GROUP BY or
ORDER BY clause in a subquery could cause a
If a materialized subquery read from a view, and contained an inner subquery having an outer reference to a column of the view, results could be incorrect. (Bug #18770217)
mysql_secure_installation ignored options defined after an unrecognized option. (Bug #18659533)
The code for processing the
set had a too-strict assertion for single-character invalid
ORDER BY of a GIS function that was given
invalid arguments could cause a server exit.
Compiler flags were not passed to DTrace, causing problems for 32-bit builds cross-compiled on 64-bit platforms. (Bug #18593044)
The server could fail to properly reprepare triggers that referred to another table after that table was truncated. (Bug #18596756, Bug #72446, Bug #18665853)
For conditions on the form
t.key NOT IN (c1, c2,
...), if one or more of the
NULL, the optimizer
generated incorrect range predicates, possibly yielding
The range optimizer would build predicates for empty in-lists
NULL values are removed from
NOT IN (in-list)).
(Bug #18556403, Bug #18715670)
returned information only when the
and returned information for all types, not just
SESSION_TRACK_SYSTEM_VARIABLES. Now they
return information of the type requested and only that type.
In debug builds, a qsort operation on decimal values could raise an assertion. (Bug #18486249)
For debug builds, an assertion was raised for attempts using a
cursor within a stored routine to fetch a large value
INT) which cannot fit into a variable
In debug builds, subquery optimization could be overly aggressive about raising an assertion. (Bug #18486607)
In debug builds,
GROUP BY clause raised an assertion.
to a bad value could cause server failure later.
For queries executed using Loose Index Scan, incorrect cost estimates could be produced if index statistics were unavailable. (Bug #18497308)
mysql_install_db could hang while reading
/dev/random to generate a random
CONNECTION showed an incorrect filtering value for
dynamic range queries.
Assigning some values to the
system variable could cause a server exit.
For mysql_upgrade, specifying the
--defaults-extra-file with a nonexisting file
caused a segmentation fault on some platforms.
CMake check failed due to a missing include
After a code reorganization in MySQL 5.7.4,
BY for multiple-table
statements was ignored.
In debug builds, lack of proper object initialization of decimal objects caused an assertion to be raised. (Bug #18335446)
INFORMATION_SCHEMA queries could
cause a server exit.
Plugin registration code in the embedded server (compiled without the Performance Schema) failed for plugins compiled with the Performance Schema. (Bug #18363910)
Improper linking of join caches by the optimizer could lead to a server exit. (Bug #18335908)
The addition in MySQL 5.7.4 of session state information to the
OK packet of the client/server protocol caused the
mysql->info member to be missing a
terminating null terminator.
NULL when it should not have.
If MySQL was built with the
mysql_config did not work if the MySQL
package was unpacked into a location with a different
installation prefix. Also, mysql_config did
not work for some RPM builds because it used an incorrect
COM_RESET_CONNECTION command did not
reset some session system variables:
timestamp. Also, it did not
clear warnings, and, although it reset the
profiling variable, it did not
reset profiling information.
(Bug #18329348, Bug #18329560, Bug #18328396, Bug #18329452)
On Windows, some test cases ran too slowly due to mysqltest not testing properly for server termination. (Bug #18330694)
For indexes on prefixes or character string columns, index corruption could occur for assignment of binary data to the column due to improper character counting. (Bug #18359924)
Solaris-specific scripts were included in and installed by non-Solaris packages. (Bug #18305641)
On Windows, use of the
caused a server exit.
innobase_strnxfrm() wrote one byte too many.
EXPLAIN for some full-text
queries could raise an assertion.
For debug builds, a
0x00 character in a
full-text query string that used the
eucjpms_bin collation could raise an
For queries involving an
AND of two geometry
ranges, the optimizer could decide no index was usable but try
to use it anyway, resulting in a server exit.
EXPLAIN on a query with an
EXISTS subquery containing a
UNION could cause a server exit. Multiple
executions of a prepared
EXPLAIN on a
UNION of subqueries could cause a server
mysqladmin password masked the old password given on the command line, but not the new password. (Bug #18163964)
yaSSL code had an off-by-one error in certificate decoding that could cause buffer overflow.
yaSSL code had an
opendir() without a
(Bug #18178997, Bug #17201924)
InnoDB tables, boolean full-text queries
for terms ending with
* could return
Executing a correlated subquery on an
table which has an
caused the server to hang.
The client library could cause clients to exit due to incorrectly mapping the client error number to the corresponding message, if reallocation of packet buffer memory occurred. (Bug #18080920)
For XA transactions, -1 could be assigned as the format ID part of an XID value, resulting in mishandling (server hang or exit) of concurrent XA statements. (Bug #18107853)
For full-text queries on
attempts to access delected document IDs could lead to a server
If the optimizer chose to perform an index scan, in some cases it could choose a noncovering rather than a covering index. (Bug #18035906)
MyISAM temporary files could be used to mount
a code-execution attack.
The C client library could leak memory when client plugins were used. (Bug #17933308)
-DWITHOUT_PARTITION_STORAGE_ENGINE=1 option did
not work. As part of fixing this problem, a preferred syntax for
disabling storage engines was implmented. The syntax
is now preferred to
For example, use:
-DWITH_EXAMPLE_STORAGE_ENGINE=0 -DWITH_FEDERATED_STORAGE_ENGINE=0 -DWITH_PARTITION_STORAGE_ENGINE=0
-DWITHOUT_EXAMPLE_STORAGE_ENGINE=1 -DWITHOUT_FEDERATED_STORAGE_ENGINE=1 -DWITHOUT_PARTITION_STORAGE_ENGINE=1
BEFORE UPDATE trigger could insert
NULL into a
For debug builds,
with a too-long function name raised an assertion.
A (rare) deadlock could occur between
LOCK_thd_data and the
trx_sys mutex. One
thread could read a query string while it was being removed by
Deadlock could occur between
mysqldump could create table definitions in
the dump file that resulted in
columns errors when reloading the dump file.
On Windows, calling
mysql_init() caused the client to
exit. windows. Now it returns a nonzero result because it is an
error to call
mysql_thread_init() before the
client library is initialized with
INFILE to load fixed-length data into a view could
cause a server exit.
The optimizer trace could cause a server exit in cases where a subquery was transformed away. (Bug #17458054)
UPDATE statements that modified
full-text indexes could cause a server exit.
If a query had both
SUM(DISTINCT)) and was executed
using Loose Index Scan, the result values of
MIN()/MAX() were set improperly.
UNION statements, the
rows-examined value was calculated incorrectly. This was
manifest as too-large values for the
ROWS_EXAMINED column of Performance Schema
statement tables (such as
Row constructor arguments to
INTERVAL() could cause a server
The change made in MySQL 5.7.0 to display the XID value in
RECOVER if it contained nonprintable characters was
reverted because it caused problems for some clients. Now the
statement takes an optional
keyword so that clients can request the XID value in hexadecimal
Use of a nonmulti-byte algorithm for skipping leading spaces in multi-byte strings could cause a server exit. (Bug #12368495, Bug #18315770)
big_tables enabled, queries that used
COUNT(DISTINCT) on a simple join with a
constant equality condition on a non-duplicate key returned
(Bug #52582, Bug #11760197)
References: See also Bug #18853696.
When MySQL runs as service on Windows,
NTService.Stop() initiates shutdown and exit
events during shutdown. After a code reorganization in MySQL
5.7.3, a call to
clean_up() was missed,
resulting in initiation of crash recovery.
(Bug #71104, Bug #17980260)
Some statements could be written to the slow query log twice. (Bug #68626, Bug #16467055)
LOAD DATA LOCAL INFILE could use all CPU if
import errors occurred when there were no line delimiters.
(Bug #51840, Bug #11759519)
mysql_config_editor exited when given an
empty argument to the
(Bug #71837, Bug #18311024, Bug #18830493)
MySQL did not compile with Bison 3. A workaround is to downgrade to Bison 2. (Bug #71250, Bug #18017820, Bug #18978946)
was treated as a fatal error, thus not catchable with condition
(Bug #72064, Bug #18413646)
For mysqldump, dump and restore operations
failed for database names that contained backslash
'\'). Thanks for Xiaobin Lin for the patch.
(Bug #71437, Bug #18109728)
mysqlslap accepted an
--iterations option value of 0, which resulted
in a divide-by-zero error. The minimum option value now is 1.
Thanks to Tsubasa Tanaka for the patch.
(Bug #72082, Bug #18430704)
IN() predicates with values different
from the key data value, the optimizer sometimes used a table
scan when it could do a range scan.
(Bug #71962, Bug #18364815)
Some comparisons between
BIGINT signed and
unsigned values could yield incorrect results.
(Bug #72046, Bug #18408499)
Uninstalling and reinstalling semisynchronous replication plugins while semisynchronous replication was active caused replication failures. The plugins now check whether they can be uninstalled and produce an error if semisynchronous replication is active. To uninstall the master-side plugin, there must be no semisynchronous slaves. To uninstall the slave-side plugin, there must be no semisynchronous I/O threads running. (Bug #70391, Bug #17638477)
A statement of the following form broke row-based replication
because it created a table having a field of data type
BIGINT with a display width of 3000, which is
beyond the maximum acceptable value of 255:
CREATE TABLE t1 AS SELECT REPEAT('A',1000) DIV 1 AS a;
(Bug #71179, Bug #17994219)
For non-debug builds of several client programs, the
--help message did not correctly indicate that
--debug-info apply only for debug builds.
(Bug #66854, Bug #16272328)
DIGEST_TEXT column of Performance
Schema statement events tables, references to system variables
of the form
(Bug #71634, Bug #18304086)
Updates could fail to update all applicable rows in cases where multiple key values were identical except for trailing spaces. (Bug #69684, Bug #17156940)
The Performance Schema
table displayed a
PROCESS_ID value of
NULL for replication threads. Now it displays
the same ID as
(Bug #71682, Bug #18259356)
SELECT 1 AS foo UNION SELECT 2 ORDER BY MAX(1);
A nonaggregated query with an
applied to it cannot contain aggregate functions, but was not
rejected as it should be. Now such queries are rejected with an
SELECT a FROM t1 ORDER BY COUNT(*);
(Bug #72174, Bug #18503515, Bug #72512, Bug #18694751)
If there was a predicate on a column referenced by
MAX() and that predicate was not
present in all the disjunctions on key parts earlier in the
compound index, Loose Index Scan returned an incorrect result.
(Bug #71097, Bug #17909656)
Valgrind warnings during verification of the zip header of the
(Bug #69202, Bug #18693654)
For an existing nondynamic (built-in) plugin, the error message
for an attempted
was misleading (the plugin does not exist). Now the message
indicates that built-in plugins cannot be uninstalled.
(Bug #51771, Bug #11759453)
Full-text queries on
MyISAM tables that
LIMIT clause but no
WHERE clause could return too few rows.
(Bug #69908, Bug #17261347)
Client auto-reconnect did not work for clients linked against
libmysqlclient, even with
(Bug #70026, Bug #17309863)
mysql_tzinfo_to_sql mishandled some values from the abbreviation list (read from the timezone information file) due to failure to account for the the null character appended to the end of the char array. (Bug #68861, Bug #16664462)
gb18030_chinese_ci collation treated
'Y' equal to
(Bug #72565, Bug #18729428)
The mysql client displayed
gb18030 data incorrectly.
(Bug #72573, Bug #18726196)
The server did not take the
into account in determining the database directory from which to
db.opts file, and thus could read
the file from an incorrect directory.
(Bug #72900, Bug #18923685)
SELECT statement using a
BY did not permit use of an alias in the outer
(Bug #72189, Bug #18498344)
Upgrades using RPM packages could change the ownership of an installation directory. (Bug #71715, Bug #18281535)
Proxy users were unable to execute statements if the proxied user password had expired. (Bug #71337, Bug #18057562)
A new CMake option,
libCstd instead of
stlport4 on Solaris 10 or later. This works
only for client code because the server depends on C++98.
cmake -DWITHOUT_SERVER=1 -DSUNPRO_CXX_LIBRARY=Cstd
(Bug #72352, Bug #18605389)
File permissions and line endings of several test and configuration files were made more consistent to avoid warnings from package checkers. (Bug #68521, Bug #16415173, Bug #16395459, Bug #68517, Bug #16415032, Bug #71112, Bug #17919313, Bug #71113, Bug #17919422)
The server was made more consistent and resilient with regard to
handling of statements for which the
keyword is specified.
The server could fail to report warnings for multiple-table
DELETE IGNORE statements.
UPDATE triggers for a table were invoked
UPDATE IGNORE statements for
which a unique index caused the update to be ignored.
For debug builds, an assertion could be raised for errors
DELETE IGNORE statements.
For debug builds, an assertion could be raised for deadlocks
DELETE IGNORE statements.
(Bug #43895, Bug #11752648, Bug #68726, Bug #16522924, Bug #16860715, Bug #16860829, Bug #14786621)
The server failed to produce an error for
INSERT statements that provided
no column names but did provide column values.
(Bug #20943, Bug #11745889, Bug #18064775)
References: This bug is a regression of Bug #16820562.