Bjorn Munch
2014-09-25 20:54:43 UTC
[Due to length restrictions, this announcement is split into three parts.
This is part 2.]
Bugs Fixed
* Performance; Replication: 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 rpl_semi_sync_slave_enabled, 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. (Bug #17932935)
* Important Change; Partitioning: In an ALTER TABLE statement,
the server accepted 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: A 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 using GTIDs, DROP TABLE statements affecting these
combinations of tables are no longer allowed unless the value
of the gtid_next system variable is AUTOMATIC. This is
because, with GTIDs enabled on the server, issuing a DROP
TABLE in the cases just described while having only one GTID
associated with each statement (the SQL thread does this
following SET gtid_next='uuid:number') causes problems when
there are not enough GTIDs for assignment to all the resulting
statements following the division of the original DROP TABLE.
A 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 follows:
+ 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 transaction
(following COMMIT)
+ 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 gtid_next is
not AUTOMATIC, issuing a DROP 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
original DROP TABLE statement but must write two 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 DROP TABLE
statement.
Now, we throw an error in the client session if gtid_next is
set to a uuid:number 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)
* InnoDB; Partitioning: Large numbers of partitioned InnoDB
tables could consume much more memory when used in MySQL 5.6
or 5.7 than the memory used by the same tables used in
previous releases of the MySQL Server. (Bug #17780517, Bug
#70641)
References: This bug was introduced by Bug #11764622, Bug
#57480.
* InnoDB: If a crash occurs after a drop index action during a
TRUNCATE TABLE operation, the root page could be left in a
free state. On crash recovery, an LSN
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_lsn
) check failed to check free pages when attempting to pin the
root page, resulting in an assertion. (Bug #19520482)
* InnoDB: The TTASFutexMutex, the mutex implementation that uses
the Linux futex, failed to request m_lock_word alignment. (Bug
#19525395, Bug #73760)
* InnoDB: Removed unused code related to binlog information
stored in the InnoDB trx_sys page. (Bug #19471743)
* InnoDB: Replaced a goto statement with an if statement in the
fil_mutex_enter_and_prepare_for_io function in fil0fil.cc.
(Bug #19488149)
* InnoDB: An ALTER TABLE ... ADD FOREIGN KEY operation could
cause a serious error. (Bug #19471516, Bug #73650)
* InnoDB: An INSERT operation on a table with spatial data
columns raised an assertion. (Bug #19474851)
* InnoDB: A transaction returned from the transaction pool was
not in a clean state. (Bug #19244969)
* InnoDB: An ALTER TABLE operation raised an fk_tables.empty()
assertion. After calling dict_load_foreigns(), all associated
tables that are linked by a foreign key should be loaded to
ensure that foreign keys are cached. (Bug #19267051)
References: This bug is a regression of Bug #16244691.
* InnoDB: In debug builds, an INSERT operation affecting
compressed tables would raise a sync-related assertion. (Bug
#19295893)
* InnoDB: Reduced mem_heap_zalloc calls in upd_create. Only a
single call is necessary to allocate memory for upd_t. (Bug
#19297656, Bug #73272)
* InnoDB: Retrieval of multiple values with a single get command
would return incorrect results instead of an error message.
The InnoDB memcached plugin does not currently support
retrieval of multiple values with a single get command. (Bug
#19172212, Bug #72453)
* InnoDB: When multiple daemon_memcached_option options are
defined, the INFORMATION_SCHEMA.GLOBAL_VARIABLES table and
SHOW VARIABLES statement should only display the first
daemon_memcached_option option that is defined in the command
line string or in the MySQL configuration file. (Bug
#19204759, Bug #73287)
* InnoDB: Removed unused one_flush variable from
storage/innobase/include/log0log.h. (Bug #19192364, Bug
#73269)
* InnoDB: Running SHOW ENGINE INNODB STATUS repeatedly under
performance testing conditions could result in a serious
error. (Bug #19196052)
* InnoDB: Attempting to perform operations on a timed out key
would cause the memcached daemon to crash and restart. (Bug
#19172013, Bug #72586)
* InnoDB: An MLOG_CHECKPOINT marker was incorrectly omitted when
performing a log checkpoint. (Bug #19233510)
* InnoDB: On crash recovery, InnoDB would call exit() when
encountering a corruption or inconsistency. Some of the exit()
calls have been removed to allow InnoDB to shut down properly.
(Bug #19229231)
* InnoDB: 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. (Bug #19140907)
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)
* InnoDB: Improved error handling for calls to
handler::records(). (Bug #19142753)
References: This bug is a regression of Bug #16802288.
* InnoDB: An ALTER TABLE operation that does not perform a sort
on the clustered index could result in a duplicate record.
(Bug #19163915)
References: See also Bug #17657223.
* InnoDB: The INNODB_PAGE_ATOMIC_REF_COUNT 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 INNODB_PAGE_ATOMIC_REF_COUNT option
obsolete. (Bug #19061440)
* InnoDB: A race condition that occurred when dynamically
disabling innodb_adaptive_hash_index caused the purge thread
to assert. (Bug #19069698)
* InnoDB: In debug builds, an invalid rw_latch == RW_NO_LATCH
assertion would cause the server to halt. (Bug #18977128)
* InnoDB: A code comment for the os_event_is_set function in
storage/innobase/os/os0event.cc was incorrect. (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)
* InnoDB: A latching order violation would occur while inserting
BLOB data. (Bug #18883885)
* InnoDB: trx_cleanup_at_db_startup failed to reset
trx->rsegs->m-redo content in debug code. (Bug #18795594)
* InnoDB: Removed unused function definitions and declarations
from the InnoDB memcached API. (Bug #18815992, Bug #72723)
* InnoDB: The innodb_memcached_config.sql configuration script
failed after running the mysql_secure_installation script,
which removes the MySQL test database. The
innodb_memcached_config.sql script now creates the test
database if it does not exist. (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)
* InnoDB: A regression introduced by the fix for Bug #11758237
resulted in a cursor->index->name == TEMP_INDEX_PREFIX
assertion. (Bug #18723872)
* InnoDB: For single item full-text searches, deleted documents
were included in inverse document frequency (IDF)
calculations. (Bug #18711306, Bug #72548)
* InnoDB: On mysqld start, specifying multiple data files using
the innodb_data_file_path option would return a Space id in
fsp header error after data is written to the second file.
(Bug #18767811)
* InnoDB: When storing BLOB data, InnoDB failed to reserve the
required tablespace pages prior to allocating the pages, which
raised an assertion on INSERT. (Bug #18756233)
* InnoDB: A failed in-place ALTER TABLE operation would leave
behind non-unique temporary file names in the data dictionary
preventing future ALTER TABLE operations on the same table due
to temporary file name conflicts. To avoid this problem,
temporary file names are made unique by appending a static
global number that is initialized to a random distributed
32-bit number using ut_time() and ut_crc32(). The number is
then incremented atomically for each assigned temporary file
name. Previously, temporary files were named using the format
#sql-ibtid, where tid is the table ID. Temporary files are now
named using the format #sql-ibtid-inc, where tid is the table
ID and inc is the incremented number. (Bug #18734396, Bug
#72594)
* InnoDB: The page_create function has been optimized to use
simpler functions to initialize pages. (Bug #18704384)
* InnoDB: An INSERT operation on a table with BLOB columns
raised an assertion. (Bug #18646430)
References: This bug is a regression of Bug #16963396.
* InnoDB: A DELETE operation on a table with full-text search
indexes raised an assertion. (Bug #18683832)
References: See also Bug #14639605.
* InnoDB: When calling the memcached flush_all command, InnoDB
attempts to initialize a connection and a transaction. If the
transaction is in TRX_STATE_NOT_STARTED state, InnoDB failed
to set CONN_DATA->CRSR_TRX to NULL, resulting in a serious
error. (Bug #18652854)
* InnoDB: When InnoDB is built as a shared library, attempting
to load the InnoDB full-text search (FTS) INFORMATION_SCHEMA
plugin would fail with a Can't open shared library
'ha_innodb.so' error. (Bug #18655281, Bug #70178)
* InnoDB: To-be-imported tablespace files (FIL_TYPE_IMPORT) were
not flushed after being converted to normal tablespace files
(FIL_TYPE_TABLESPACE), resulting in too many open files. (Bug
#18663997)
References: This bug is a regression of Bug #18236692.
* InnoDB: On startup, with innodb_file_per_table=ON, the page
cleaner thread would raise a srv_get_active_thread_type() ==
SRV_NONE debug assertion when encountering an active master
thread. (Bug #18598813)
* InnoDB: 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)
* InnoDB: After running OPTIMIZE TABLE on an InnoDB table with a
spatial index, running a SELECT statement that uses the
spatial index could result in a crash. (Bug #18619945, Bug
#72361)
References: This bug is a regression of Bug #13975225.
* InnoDB: An INSERT operation on a table with GEOMETRY columns
raised an assertion in rtr_page_split_and_insert(). (Bug
#18644435)
* InnoDB: The temporary tablespace file (ibtmp1) was held open
by the page_cleaner thread and could not be removed on
startup, resulting in a hang. (Bug #18642372)
* InnoDB: InnoDB would try to merge a b-tree change buffer for a
dedicated undo tablespace. (Bug #18593561)
* InnoDB: 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 innodb_file_per_table was
enabled. (Bug #18635485)
* InnoDB: In rare cases, the purge process would attempt to
delete a secondary index record that was not marked for
deletion, resulting in an inconsistent secondary index. (Bug
#18631496)
* InnoDB: Included unistd.h in innodb.cmake to enable futexes in
debug builds. (Bug #18522549, Bug #72225)
* InnoDB: A DB_LOCK_WAIT during a foreign key check caused
redundant delete marking, resulting in a failing assertion.
(Bug #18451287)
* InnoDB: TRUNCATE TABLE would write page-level redo logs during
the DROP TABLE step of a TRUNCATE TABLE operation. (Bug
#18511398)
* InnoDB: srv_active_wake_master_thread() was called directly in
innobase_commit and innobase_prepare, waking up the master
thread and incrementing srv_activity_count.
srv_active_wake_master_thread() should only be called after
committing write transactions, not after read-only
transactions or rollbacks. This patch also replaces some calls
to srv_active_wake_master_thread() with calls to
ib_wake_master_thread(). (Bug #18477009, Bug #72137)
* InnoDB: A COMMIT operation related to full-text search
resulted in a segmentation fault. (Bug #18503734)
* InnoDB: The os_event_wait_time_low function would sometimes
return OS_SYNC_TIME_EXCEEDED before the sync time has elapsed.
(Bug #18386498)
* InnoDB: Running a SELECT on a partitioned table caused a
memory access violation in memcpy(). (Bug #18383840)
References: See also Bug #18167648.
* InnoDB: With UNIV_SYNC_DEBUG enabled, a late call to
sync_check_enable() would result in an m_enabled assertion
failure. (Bug #18433658)
* InnoDB: InnoDB would write to the redo log for an IMPORT
TABLESPACE operation before the tablespace import was
complete. (Bug #18424134)
* InnoDB: The InnoDB memcached plugin would call plugin_del
without acquiring the lock_plugin mutex. This bug fix also
addresses a race condition in ib_cursor_delete_row. (Bug
#18409840)
* InnoDB: With persistent statistics enabled, SHOW TABLE STATUS
output and the TABLE_ROWS column of INFORMATION_SCHEMA.TABLES
could report an incorrect number of table rows for tables with
externally stored pages. (Bug #18384390)
* InnoDB: Added the C++ ostream mechanism for error logging.
(Bug #18320915)
* 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)
* InnoDB: The data file was not opened prior to calling
fil_fusionio_enable_atomic_write(), resulting in an assertion
failure. (Bug #18368241)
* InnoDB: Removed the recv_max_parsed_page_no code variable,
which was only used in a diagnostic error message. (Bug
#18312967)
* InnoDB: buf_pool->flush_rbt, which is only intended to be used
for recovery, would be allocated for database creation and
never freed. (Bug #18253089)
* InnoDB: Calls to sched_getcpu would cause page faults. (Bug
#18225489)
* InnoDB: ib_heap_resize failed to verify that new_size is
greater than or equal to old_size before calling memcpy. (Bug
#18178915)
* InnoDB: After crash recovery and with UNIV_DEBUG enabled,
purge failed with a buf_pool_from_bpage(bpage) == buf_pool
assertion failure. (Bug #18154145)
* InnoDB: For each insert, memset would be called three times to
allocate memory for system fields. To reduce CPU usage, the
three memset calls are now combined into a single call. (Bug
#17858679, Bug #71014)
* InnoDB: Assertion code in buf_page_release_latch() in
buf0buf.ic was too restrictive. (Bug #17869571)
* InnoDB: The fix for Bug#16418661 added superfluous
buf_flush_list() logic to InnoDB startup code. (Bug #17798076,
Bug #70899)
* InnoDB: A problem renaming temporary tables during an ALTER
TABLE operation would raise an assertion and print a warning
to the error log. Temporary table names were not sufficiently
unique. (Bug #17713871)
* InnoDB: In-place 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. (Bug #17657223)
* InnoDB: A race condition in fts_get_next_doc_id 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: Enabling the InnoDB Table Monitor would result in a
ib_table->stat_initialized assertion failure. (Bug #17039528,
Bug #69641)
* InnoDB: 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
limitation. (Bug #16963396, Bug #19030353, Bug #69477)
* InnoDB: The error log message that is printed on CREATE TABLE
when the number of BLOB or 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)
* InnoDB: An in-place ALTER TABLE operation on a table with a
broken foreign key constraint could raise an assertion. (Bug
#16869435)
* InnoDB: The lock_number_of_rows_locked function used a bit
vector to track the number of record locks held by a
transaction. To optimize reporting, the bit vector was
replaced by a simple counter. (Bug #16479309, Bug #68647)
* InnoDB: 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, InnoDB now attempts to insert to the next
page before splitting the page. (Bug #15923864, Bug #67718)
* InnoDB: With innodb_max_dirty_pages_pct=0 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: When foreign_key_checks is disabled, 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)
* InnoDB: Debug assertion code in file row0ins.cc did not
account for rw-lock shared-exclusive (sx-lock) mode, resulting
in an assertion failure. (Bug #73534, Bug #19420253)
* Partitioning: When the index_merge_intersection flag (enabled
by default) or the index_merge_union flag was enabled by the
setting of the optimizer_switch system variable, queries
returned incorrect results when executed against partitoned
tables that used the MyISAM storage engine, as well as
partitioned InnoDB tables that lacked a primary key. (Bug
#18167648)
References: See also Bug #16862316, Bug #17588348, Bug
#17648468.
* Partitioning: Selecting from a table having multiple columns
in its primary key and partitioned by LIST COLUMNS(R), where R
was the last (rightmost) column listed in the primary key
definition, returned an incorrect result. (Bug #17909699, Bug
#71095)
* Replication: Misleading or confusing error messages have been
revised, which were produced in the following 2 cases when
using mysqlbinlog with the --raw option:
+ When this option was used together with --include-gtids.
+ When this option was used together with --exclude-gtids
and --read-from-remote-master=BINLOG-DUMP-NON-GTIDS.
(Bug #19459836, Bug #73625)
* Replication: After the fix for Bug #16861624, killing a
multi-threaded slave worker which was waiting for a commit
lock caused a debug assertion to fail. This fix ensures that
such a situation can not occur. (Bug #19311260)
* Replication: Temporary errors related to a slave worker thread
which was retrying a transaction were visible in SHOW SLAVE
STATUS. This fix ensures that slave worker threads do not
store temporary errors in the slave status. (Bug #19282301)
* 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)
* Replication: RESET SLAVE 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. (Bug
#18816897)
* 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 the heartbeat period
(Slave_heartbeat_period) to its default value.
+ RESET SLAVE automatically set SSL_VERIFY_SERVER_CERT to
the default.
+ When a server was not configured as a slave (that is,
when no 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 START
SLAVE.
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)
* Replication: Semi-synchronous replication did not work as
expected when the rpl_semi_sync_master_wait_no_slave and
rpl_semi_sync_master_wait_for_slave_count variables were set.
The values of the variables were changed, but the related
internal status was not updated during initialization. (Bug
#18835117, Bug #18466390)
* Replication: mysqlbinlog --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 error. (Bug
#18742916, Bug #72597)
* Replication: When committing a transaction, a flag is now used
to check whether a thread has been created, rather than
checking the thread itself, which uses more resources,
particularly when running the server with
master_info_repository=TABLE. (Bug #18684222)
References: See also Bug #17967378.
* 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)
* Replication: When using GTIDs with MASTER_AUTO_POSITION
enabled, if an I/O thread was restarted it failed with an
ER_GTID_NEXT_TYPE_UNDEFINED_GROUP error due to a partial
transaction not being correctly rolled back before resuming
the I/O thread. This fix ensures that the partial transaction
is correctly rolled back. (Bug #18472603)
* Replication: 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)
* Replication: 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 with InnoDB tables lacking a
primary key. (Bug #18432495, Bug #72085)
* Replication: A multi-threaded slave now checks that a free
worker is available to dispatch the next event. In previous
versions, a multi-threaded slave crashes with a worker error
if the thread coordinator can not find a free worker. The
crash was caused when the coordinator did not return a free
worker, for example if the coordinator was aborted at the same
time using STOP SLAVE. (Bug #18363515)
* Replication: When replicating from a MySQL 5.5 or earlier
master to a MySQL 5.6 or later slave, the SOURCE_UUID column
of the slave's
performance_schema.replication_connection_status table
contained random data. Now in such cases, SOURCE_UUID is left
blank. (Bug #18338203)
* 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)
* Replication: 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 'xyz'.
When mysqlbinlog processes a binary log containing GTIDs, it
outputs SET gtid_next statements, but gtid_next is set to
undefined whenever a commit occurs; this left gtid_next
undefined 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 1837, ER_GTID_NEXT_TYPE_UNDEFINED_GROUP).
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 gtid_next
undefined.
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)
* Replication: Changing master_info_repository between TABLE and
FILE could produce duplicate values in the
Replicate_Ignore_Server_Ids column of the output from SHOW
SLAVE STATUS and the Ignored_server_ids column of the
mysql.slave_master_info table. This could arise because the
list of IDs stored internally by the server was not always
sorted before checking for duplicates when inserting new
values into the list. Now the list of server IDs to be ignored
is always sorted, prior to performing this check. (Bug
#18192817, Bug #18593479, Bug #18920203)
* Replication: Quotation marks were not always handled correctly
by LOAD DATA INFILE when written into the binary log. (Bug
#18207212, Bug #71603)
* Replication: In certain cases, the server mishandled triggers
and stored procedures that tried to modify other tables when
called by CREATE TABLE ... SELECT. This is now handled
correctly as an error. (Bug #18137535)
* Replication: The REPLICATE_WILD_DO_TABLE and
REPLICATE_WILD_IGNORE_TABLE options for CHANGE REPLICATION
FILTER could be employed with values which contained no period
(.) character, even though values for these options must be in
the format db_name.tbl_name.. (Bug #18095449)
* Replication: When used on a table employing a transactional
storage engine, a failed 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)
* Replication: Beginning in MySQL 5.6.20, when a user specified
AUTO_INCREMENT value falls outside of the range between the
current AUTO_INCREMENT 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
range. (Bug #17588419, Bug #70583)
* Replication: When the I/O thread reconnected to a master using
GTIDs and multithreaded slaves while in the middle of a
transaction, it failed to abort the transaction, leaving a
partial transaction in the relay log, and then retrieving the
same transaction again. This occurred when performing a
rotation of the relay log. Now when reconnecting, the server
checks before rotating the log in such cases, and waits first
for any ongoing transaction to complete. (Bug #17326020)
* Replication: On Windows, mysqldump failed if the error log
file was deleted (missing) from the active MySQL server. (Bug
#17076131)
* Replication: When the binary log was rotated due to receipt of
a SIGHUP signal, the new binary log did not contain the
Previous_gtid_event required for subsequent processing of that
binary log's GTID events. Now when 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. (Bug #17026898)
* Replication: When using semisynchronous replication, if the
binary log position was changed to a future position on a
slave then an assertion error was generated on the master.
This fix ensures that in such a situation the future position
is correctly acknowledged and an error is instead generated on
the slave. (Bug #70327, Bug #17453826)
* Replication: When an SQL thread which was waiting for a commit
lock was killed and restarted it caused a transaction to be
skipped on slave. This fix ensures that thread positions are
correctly persisted and transactions resume at the correct
position. (Bug #69873, Bug #17450876)
* Replication: On a master that is using semisynchronous
replication, where rpl_semi_sync_master_wait_no_slave is
enabled and rpl_semi_sync_master_timeout is set to long
timeout, killing the I/O thread could cause the server to hang
on shutdown. This fix ensures that if the dump thread finds
that there no semisynchronous slaves connected to the master,
the setting of rpl_semi_sync_master_wait_no_slave is ignored
and the shutdown proceeds correctly. (Bug #71047, Bug
#17879675)
* Replication: When using row-based replication, setting a
slave's slave_rows_search_algorithms variable to HASH_SCAN
caused an ER_RECORD_NOT_FOUND error even though that record
existed in the storage layer. This fix ensures that the unique
key for each record is correctly maintained and such a
situation does not occur. (Bug #72788, Bug #18860225)
* Replication: When an event group was spanned across multiple
relay log files, a slave could incorrectly identify
GTID-header group boundaries. This meant that when a
transaction was retried, or if the SQL thread was stopped in
the middle of a transaction after some rotates, the
Gtid_log_event was being silently skipped on the slave, and
the transaction was logged with the slave's GTID. This problem
also impacted on using START SLAVE UNTIL MASTER_LOG_POS =
log_pos; with GTIDs enabled. If log_pos was in the middle of a
transaction, the Gtid_log_event was not correctly detected as
the beginning of the transaction and replication stopped
before this event. With this fix, threads correctly detect
that they are part of a group, and this is used to check if a
Gtid_log_event is part of a transaction. (Bug #72313, Bug
#18652178, Bug #18306199)
* Replication: The error messages generated when a duplicate
server UUID causes issues during replication have been
improved. The slave error now identifies the duplicate server
UUID and the master error identifies the zombie thread that
has been killed. (Bug #72578, Bug #18731211)
* Replication: Replication of tables that contained temporal
type fields (such as TIMESTAMP, DATETIME, and TIME) from
different MySQL versions failed due to incompatible TIMESTAMP
types. The fractional TIMESTAMP format added in MySQL 5.6.4
was not being correctly converted. You can now replicate a
TIMESTAMP in either format correctly according to the
slave_type_conversions variable. (Bug #70124, Bug #17532932)
* Replication: The CLIENT_REMEMBER_OPTIONS flag for compressed
slave connections is no longer reset and all options are
retained. This restores functionality of all options to
compressed slave connections. (Bug #72901, Bug #18923691, Bug
#73324, Bug #19244772)
* 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)
* Replication: Client applications should be able to set the
BINLOG_DUMP_NON_BLOCK flag in the initial handshake packet
(COM_BINLOG_DUMP). Clients 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 release.
As part of this fix, a new --connection-server-id 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)
* Replication: A group of threads involved in acquiring locks
could deadlock when the following events occurred:
1. Dump thread reconnects from slave; on master, a new dump
thread tries to kill zombie dump threads; having acquired
the thread's LOCK_thd_data, it is about to acquire
LOCK_log.
2. Application thread executing show binary logs, having
acquired LOCK_log and about to acquire LOCK_index.
3. Application thread executing PURGE BINARY LOGS; having
acquired LOCK_index, it is about to acquire
LOCK_thread_count.
4. Application thread executing SHOW PROCESSLIST (or SELECT
* FROM INFORMATION_SCHEMA.PROCESSLIST), having acquired
LOCK_thread_count and about to acquire the zombie dump
thread's LOCK_thd_data.
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
LOCK_log and LOCK_index, as well as rules for ordering
LOCK_thread_count and LOCK_thd_data, but there are no rules
for ordering across these two sets of locks. This was because
the internal mysqld_list_processes() function invoked by SHOW
PROCESSLIST acquired LOCK_thread_count for the complete
lifetime of the function as well as acquiring and releasing
each thread's 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_th
read_count
(Bug #69954, Bug #17283409)
References: See also Bug #73475, Bug #19364731, Bug #19365180.
* Replication: When 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 immediately by 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" transactions:
+ No empty transaction was generated for CREATE TEMPORARY
TABLE or DROP TEMPORARY TABLE statements.
+ If the slave used a database filter (--replicate-do-db or
--replicate-ignore-db option), no empty transaction was
generated.
(Bug #71376, Bug #18095502, Bug #18145032)
This is part 2.]
Bugs Fixed
* Performance; Replication: 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 rpl_semi_sync_slave_enabled, 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. (Bug #17932935)
* Important Change; Partitioning: In an ALTER TABLE statement,
the server accepted 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: A 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 using GTIDs, DROP TABLE statements affecting these
combinations of tables are no longer allowed unless the value
of the gtid_next system variable is AUTOMATIC. This is
because, with GTIDs enabled on the server, issuing a DROP
TABLE in the cases just described while having only one GTID
associated with each statement (the SQL thread does this
following SET gtid_next='uuid:number') causes problems when
there are not enough GTIDs for assignment to all the resulting
statements following the division of the original DROP TABLE.
A 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 follows:
+ 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 transaction
(following COMMIT)
+ 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 gtid_next is
not AUTOMATIC, issuing a DROP 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
original DROP TABLE statement but must write two 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 DROP TABLE
statement.
Now, we throw an error in the client session if gtid_next is
set to a uuid:number 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)
* InnoDB; Partitioning: Large numbers of partitioned InnoDB
tables could consume much more memory when used in MySQL 5.6
or 5.7 than the memory used by the same tables used in
previous releases of the MySQL Server. (Bug #17780517, Bug
#70641)
References: This bug was introduced by Bug #11764622, Bug
#57480.
* InnoDB: If a crash occurs after a drop index action during a
TRUNCATE TABLE operation, the root page could be left in a
free state. On crash recovery, an LSN
(http://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_lsn
) check failed to check free pages when attempting to pin the
root page, resulting in an assertion. (Bug #19520482)
* InnoDB: The TTASFutexMutex, the mutex implementation that uses
the Linux futex, failed to request m_lock_word alignment. (Bug
#19525395, Bug #73760)
* InnoDB: Removed unused code related to binlog information
stored in the InnoDB trx_sys page. (Bug #19471743)
* InnoDB: Replaced a goto statement with an if statement in the
fil_mutex_enter_and_prepare_for_io function in fil0fil.cc.
(Bug #19488149)
* InnoDB: An ALTER TABLE ... ADD FOREIGN KEY operation could
cause a serious error. (Bug #19471516, Bug #73650)
* InnoDB: An INSERT operation on a table with spatial data
columns raised an assertion. (Bug #19474851)
* InnoDB: A transaction returned from the transaction pool was
not in a clean state. (Bug #19244969)
* InnoDB: An ALTER TABLE operation raised an fk_tables.empty()
assertion. After calling dict_load_foreigns(), all associated
tables that are linked by a foreign key should be loaded to
ensure that foreign keys are cached. (Bug #19267051)
References: This bug is a regression of Bug #16244691.
* InnoDB: In debug builds, an INSERT operation affecting
compressed tables would raise a sync-related assertion. (Bug
#19295893)
* InnoDB: Reduced mem_heap_zalloc calls in upd_create. Only a
single call is necessary to allocate memory for upd_t. (Bug
#19297656, Bug #73272)
* InnoDB: Retrieval of multiple values with a single get command
would return incorrect results instead of an error message.
The InnoDB memcached plugin does not currently support
retrieval of multiple values with a single get command. (Bug
#19172212, Bug #72453)
* InnoDB: When multiple daemon_memcached_option options are
defined, the INFORMATION_SCHEMA.GLOBAL_VARIABLES table and
SHOW VARIABLES statement should only display the first
daemon_memcached_option option that is defined in the command
line string or in the MySQL configuration file. (Bug
#19204759, Bug #73287)
* InnoDB: Removed unused one_flush variable from
storage/innobase/include/log0log.h. (Bug #19192364, Bug
#73269)
* InnoDB: Running SHOW ENGINE INNODB STATUS repeatedly under
performance testing conditions could result in a serious
error. (Bug #19196052)
* InnoDB: Attempting to perform operations on a timed out key
would cause the memcached daemon to crash and restart. (Bug
#19172013, Bug #72586)
* InnoDB: An MLOG_CHECKPOINT marker was incorrectly omitted when
performing a log checkpoint. (Bug #19233510)
* InnoDB: On crash recovery, InnoDB would call exit() when
encountering a corruption or inconsistency. Some of the exit()
calls have been removed to allow InnoDB to shut down properly.
(Bug #19229231)
* InnoDB: 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. (Bug #19140907)
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)
* InnoDB: Improved error handling for calls to
handler::records(). (Bug #19142753)
References: This bug is a regression of Bug #16802288.
* InnoDB: An ALTER TABLE operation that does not perform a sort
on the clustered index could result in a duplicate record.
(Bug #19163915)
References: See also Bug #17657223.
* InnoDB: The INNODB_PAGE_ATOMIC_REF_COUNT 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 INNODB_PAGE_ATOMIC_REF_COUNT option
obsolete. (Bug #19061440)
* InnoDB: A race condition that occurred when dynamically
disabling innodb_adaptive_hash_index caused the purge thread
to assert. (Bug #19069698)
* InnoDB: In debug builds, an invalid rw_latch == RW_NO_LATCH
assertion would cause the server to halt. (Bug #18977128)
* InnoDB: A code comment for the os_event_is_set function in
storage/innobase/os/os0event.cc was incorrect. (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)
* InnoDB: A latching order violation would occur while inserting
BLOB data. (Bug #18883885)
* InnoDB: trx_cleanup_at_db_startup failed to reset
trx->rsegs->m-redo content in debug code. (Bug #18795594)
* InnoDB: Removed unused function definitions and declarations
from the InnoDB memcached API. (Bug #18815992, Bug #72723)
* InnoDB: The innodb_memcached_config.sql configuration script
failed after running the mysql_secure_installation script,
which removes the MySQL test database. The
innodb_memcached_config.sql script now creates the test
database if it does not exist. (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)
* InnoDB: A regression introduced by the fix for Bug #11758237
resulted in a cursor->index->name == TEMP_INDEX_PREFIX
assertion. (Bug #18723872)
* InnoDB: For single item full-text searches, deleted documents
were included in inverse document frequency (IDF)
calculations. (Bug #18711306, Bug #72548)
* InnoDB: On mysqld start, specifying multiple data files using
the innodb_data_file_path option would return a Space id in
fsp header error after data is written to the second file.
(Bug #18767811)
* InnoDB: When storing BLOB data, InnoDB failed to reserve the
required tablespace pages prior to allocating the pages, which
raised an assertion on INSERT. (Bug #18756233)
* InnoDB: A failed in-place ALTER TABLE operation would leave
behind non-unique temporary file names in the data dictionary
preventing future ALTER TABLE operations on the same table due
to temporary file name conflicts. To avoid this problem,
temporary file names are made unique by appending a static
global number that is initialized to a random distributed
32-bit number using ut_time() and ut_crc32(). The number is
then incremented atomically for each assigned temporary file
name. Previously, temporary files were named using the format
#sql-ibtid, where tid is the table ID. Temporary files are now
named using the format #sql-ibtid-inc, where tid is the table
ID and inc is the incremented number. (Bug #18734396, Bug
#72594)
* InnoDB: The page_create function has been optimized to use
simpler functions to initialize pages. (Bug #18704384)
* InnoDB: An INSERT operation on a table with BLOB columns
raised an assertion. (Bug #18646430)
References: This bug is a regression of Bug #16963396.
* InnoDB: A DELETE operation on a table with full-text search
indexes raised an assertion. (Bug #18683832)
References: See also Bug #14639605.
* InnoDB: When calling the memcached flush_all command, InnoDB
attempts to initialize a connection and a transaction. If the
transaction is in TRX_STATE_NOT_STARTED state, InnoDB failed
to set CONN_DATA->CRSR_TRX to NULL, resulting in a serious
error. (Bug #18652854)
* InnoDB: When InnoDB is built as a shared library, attempting
to load the InnoDB full-text search (FTS) INFORMATION_SCHEMA
plugin would fail with a Can't open shared library
'ha_innodb.so' error. (Bug #18655281, Bug #70178)
* InnoDB: To-be-imported tablespace files (FIL_TYPE_IMPORT) were
not flushed after being converted to normal tablespace files
(FIL_TYPE_TABLESPACE), resulting in too many open files. (Bug
#18663997)
References: This bug is a regression of Bug #18236692.
* InnoDB: On startup, with innodb_file_per_table=ON, the page
cleaner thread would raise a srv_get_active_thread_type() ==
SRV_NONE debug assertion when encountering an active master
thread. (Bug #18598813)
* InnoDB: 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)
* InnoDB: After running OPTIMIZE TABLE on an InnoDB table with a
spatial index, running a SELECT statement that uses the
spatial index could result in a crash. (Bug #18619945, Bug
#72361)
References: This bug is a regression of Bug #13975225.
* InnoDB: An INSERT operation on a table with GEOMETRY columns
raised an assertion in rtr_page_split_and_insert(). (Bug
#18644435)
* InnoDB: The temporary tablespace file (ibtmp1) was held open
by the page_cleaner thread and could not be removed on
startup, resulting in a hang. (Bug #18642372)
* InnoDB: InnoDB would try to merge a b-tree change buffer for a
dedicated undo tablespace. (Bug #18593561)
* InnoDB: 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 innodb_file_per_table was
enabled. (Bug #18635485)
* InnoDB: In rare cases, the purge process would attempt to
delete a secondary index record that was not marked for
deletion, resulting in an inconsistent secondary index. (Bug
#18631496)
* InnoDB: Included unistd.h in innodb.cmake to enable futexes in
debug builds. (Bug #18522549, Bug #72225)
* InnoDB: A DB_LOCK_WAIT during a foreign key check caused
redundant delete marking, resulting in a failing assertion.
(Bug #18451287)
* InnoDB: TRUNCATE TABLE would write page-level redo logs during
the DROP TABLE step of a TRUNCATE TABLE operation. (Bug
#18511398)
* InnoDB: srv_active_wake_master_thread() was called directly in
innobase_commit and innobase_prepare, waking up the master
thread and incrementing srv_activity_count.
srv_active_wake_master_thread() should only be called after
committing write transactions, not after read-only
transactions or rollbacks. This patch also replaces some calls
to srv_active_wake_master_thread() with calls to
ib_wake_master_thread(). (Bug #18477009, Bug #72137)
* InnoDB: A COMMIT operation related to full-text search
resulted in a segmentation fault. (Bug #18503734)
* InnoDB: The os_event_wait_time_low function would sometimes
return OS_SYNC_TIME_EXCEEDED before the sync time has elapsed.
(Bug #18386498)
* InnoDB: Running a SELECT on a partitioned table caused a
memory access violation in memcpy(). (Bug #18383840)
References: See also Bug #18167648.
* InnoDB: With UNIV_SYNC_DEBUG enabled, a late call to
sync_check_enable() would result in an m_enabled assertion
failure. (Bug #18433658)
* InnoDB: InnoDB would write to the redo log for an IMPORT
TABLESPACE operation before the tablespace import was
complete. (Bug #18424134)
* InnoDB: The InnoDB memcached plugin would call plugin_del
without acquiring the lock_plugin mutex. This bug fix also
addresses a race condition in ib_cursor_delete_row. (Bug
#18409840)
* InnoDB: With persistent statistics enabled, SHOW TABLE STATUS
output and the TABLE_ROWS column of INFORMATION_SCHEMA.TABLES
could report an incorrect number of table rows for tables with
externally stored pages. (Bug #18384390)
* InnoDB: Added the C++ ostream mechanism for error logging.
(Bug #18320915)
* 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)
* InnoDB: The data file was not opened prior to calling
fil_fusionio_enable_atomic_write(), resulting in an assertion
failure. (Bug #18368241)
* InnoDB: Removed the recv_max_parsed_page_no code variable,
which was only used in a diagnostic error message. (Bug
#18312967)
* InnoDB: buf_pool->flush_rbt, which is only intended to be used
for recovery, would be allocated for database creation and
never freed. (Bug #18253089)
* InnoDB: Calls to sched_getcpu would cause page faults. (Bug
#18225489)
* InnoDB: ib_heap_resize failed to verify that new_size is
greater than or equal to old_size before calling memcpy. (Bug
#18178915)
* InnoDB: After crash recovery and with UNIV_DEBUG enabled,
purge failed with a buf_pool_from_bpage(bpage) == buf_pool
assertion failure. (Bug #18154145)
* InnoDB: For each insert, memset would be called three times to
allocate memory for system fields. To reduce CPU usage, the
three memset calls are now combined into a single call. (Bug
#17858679, Bug #71014)
* InnoDB: Assertion code in buf_page_release_latch() in
buf0buf.ic was too restrictive. (Bug #17869571)
* InnoDB: The fix for Bug#16418661 added superfluous
buf_flush_list() logic to InnoDB startup code. (Bug #17798076,
Bug #70899)
* InnoDB: A problem renaming temporary tables during an ALTER
TABLE operation would raise an assertion and print a warning
to the error log. Temporary table names were not sufficiently
unique. (Bug #17713871)
* InnoDB: In-place 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. (Bug #17657223)
* InnoDB: A race condition in fts_get_next_doc_id 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: Enabling the InnoDB Table Monitor would result in a
ib_table->stat_initialized assertion failure. (Bug #17039528,
Bug #69641)
* InnoDB: 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
limitation. (Bug #16963396, Bug #19030353, Bug #69477)
* InnoDB: The error log message that is printed on CREATE TABLE
when the number of BLOB or 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)
* InnoDB: An in-place ALTER TABLE operation on a table with a
broken foreign key constraint could raise an assertion. (Bug
#16869435)
* InnoDB: The lock_number_of_rows_locked function used a bit
vector to track the number of record locks held by a
transaction. To optimize reporting, the bit vector was
replaced by a simple counter. (Bug #16479309, Bug #68647)
* InnoDB: 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, InnoDB now attempts to insert to the next
page before splitting the page. (Bug #15923864, Bug #67718)
* InnoDB: With innodb_max_dirty_pages_pct=0 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: When foreign_key_checks is disabled, 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)
* InnoDB: Debug assertion code in file row0ins.cc did not
account for rw-lock shared-exclusive (sx-lock) mode, resulting
in an assertion failure. (Bug #73534, Bug #19420253)
* Partitioning: When the index_merge_intersection flag (enabled
by default) or the index_merge_union flag was enabled by the
setting of the optimizer_switch system variable, queries
returned incorrect results when executed against partitoned
tables that used the MyISAM storage engine, as well as
partitioned InnoDB tables that lacked a primary key. (Bug
#18167648)
References: See also Bug #16862316, Bug #17588348, Bug
#17648468.
* Partitioning: Selecting from a table having multiple columns
in its primary key and partitioned by LIST COLUMNS(R), where R
was the last (rightmost) column listed in the primary key
definition, returned an incorrect result. (Bug #17909699, Bug
#71095)
* Replication: Misleading or confusing error messages have been
revised, which were produced in the following 2 cases when
using mysqlbinlog with the --raw option:
+ When this option was used together with --include-gtids.
+ When this option was used together with --exclude-gtids
and --read-from-remote-master=BINLOG-DUMP-NON-GTIDS.
(Bug #19459836, Bug #73625)
* Replication: After the fix for Bug #16861624, killing a
multi-threaded slave worker which was waiting for a commit
lock caused a debug assertion to fail. This fix ensures that
such a situation can not occur. (Bug #19311260)
* Replication: Temporary errors related to a slave worker thread
which was retrying a transaction were visible in SHOW SLAVE
STATUS. This fix ensures that slave worker threads do not
store temporary errors in the slave status. (Bug #19282301)
* 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)
* Replication: RESET SLAVE 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. (Bug
#18816897)
* 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 the heartbeat period
(Slave_heartbeat_period) to its default value.
+ RESET SLAVE automatically set SSL_VERIFY_SERVER_CERT to
the default.
+ When a server was not configured as a slave (that is,
when no 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 START
SLAVE.
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)
* Replication: Semi-synchronous replication did not work as
expected when the rpl_semi_sync_master_wait_no_slave and
rpl_semi_sync_master_wait_for_slave_count variables were set.
The values of the variables were changed, but the related
internal status was not updated during initialization. (Bug
#18835117, Bug #18466390)
* Replication: mysqlbinlog --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 error. (Bug
#18742916, Bug #72597)
* Replication: When committing a transaction, a flag is now used
to check whether a thread has been created, rather than
checking the thread itself, which uses more resources,
particularly when running the server with
master_info_repository=TABLE. (Bug #18684222)
References: See also Bug #17967378.
* 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)
* Replication: When using GTIDs with MASTER_AUTO_POSITION
enabled, if an I/O thread was restarted it failed with an
ER_GTID_NEXT_TYPE_UNDEFINED_GROUP error due to a partial
transaction not being correctly rolled back before resuming
the I/O thread. This fix ensures that the partial transaction
is correctly rolled back. (Bug #18472603)
* Replication: 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)
* Replication: 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 with InnoDB tables lacking a
primary key. (Bug #18432495, Bug #72085)
* Replication: A multi-threaded slave now checks that a free
worker is available to dispatch the next event. In previous
versions, a multi-threaded slave crashes with a worker error
if the thread coordinator can not find a free worker. The
crash was caused when the coordinator did not return a free
worker, for example if the coordinator was aborted at the same
time using STOP SLAVE. (Bug #18363515)
* Replication: When replicating from a MySQL 5.5 or earlier
master to a MySQL 5.6 or later slave, the SOURCE_UUID column
of the slave's
performance_schema.replication_connection_status table
contained random data. Now in such cases, SOURCE_UUID is left
blank. (Bug #18338203)
* 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)
* Replication: 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 'xyz'.
When mysqlbinlog processes a binary log containing GTIDs, it
outputs SET gtid_next statements, but gtid_next is set to
undefined whenever a commit occurs; this left gtid_next
undefined 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 1837, ER_GTID_NEXT_TYPE_UNDEFINED_GROUP).
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 gtid_next
undefined.
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)
* Replication: Changing master_info_repository between TABLE and
FILE could produce duplicate values in the
Replicate_Ignore_Server_Ids column of the output from SHOW
SLAVE STATUS and the Ignored_server_ids column of the
mysql.slave_master_info table. This could arise because the
list of IDs stored internally by the server was not always
sorted before checking for duplicates when inserting new
values into the list. Now the list of server IDs to be ignored
is always sorted, prior to performing this check. (Bug
#18192817, Bug #18593479, Bug #18920203)
* Replication: Quotation marks were not always handled correctly
by LOAD DATA INFILE when written into the binary log. (Bug
#18207212, Bug #71603)
* Replication: In certain cases, the server mishandled triggers
and stored procedures that tried to modify other tables when
called by CREATE TABLE ... SELECT. This is now handled
correctly as an error. (Bug #18137535)
* Replication: The REPLICATE_WILD_DO_TABLE and
REPLICATE_WILD_IGNORE_TABLE options for CHANGE REPLICATION
FILTER could be employed with values which contained no period
(.) character, even though values for these options must be in
the format db_name.tbl_name.. (Bug #18095449)
* Replication: When used on a table employing a transactional
storage engine, a failed 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)
* Replication: Beginning in MySQL 5.6.20, when a user specified
AUTO_INCREMENT value falls outside of the range between the
current AUTO_INCREMENT 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
range. (Bug #17588419, Bug #70583)
* Replication: When the I/O thread reconnected to a master using
GTIDs and multithreaded slaves while in the middle of a
transaction, it failed to abort the transaction, leaving a
partial transaction in the relay log, and then retrieving the
same transaction again. This occurred when performing a
rotation of the relay log. Now when reconnecting, the server
checks before rotating the log in such cases, and waits first
for any ongoing transaction to complete. (Bug #17326020)
* Replication: On Windows, mysqldump failed if the error log
file was deleted (missing) from the active MySQL server. (Bug
#17076131)
* Replication: When the binary log was rotated due to receipt of
a SIGHUP signal, the new binary log did not contain the
Previous_gtid_event required for subsequent processing of that
binary log's GTID events. Now when 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. (Bug #17026898)
* Replication: When using semisynchronous replication, if the
binary log position was changed to a future position on a
slave then an assertion error was generated on the master.
This fix ensures that in such a situation the future position
is correctly acknowledged and an error is instead generated on
the slave. (Bug #70327, Bug #17453826)
* Replication: When an SQL thread which was waiting for a commit
lock was killed and restarted it caused a transaction to be
skipped on slave. This fix ensures that thread positions are
correctly persisted and transactions resume at the correct
position. (Bug #69873, Bug #17450876)
* Replication: On a master that is using semisynchronous
replication, where rpl_semi_sync_master_wait_no_slave is
enabled and rpl_semi_sync_master_timeout is set to long
timeout, killing the I/O thread could cause the server to hang
on shutdown. This fix ensures that if the dump thread finds
that there no semisynchronous slaves connected to the master,
the setting of rpl_semi_sync_master_wait_no_slave is ignored
and the shutdown proceeds correctly. (Bug #71047, Bug
#17879675)
* Replication: When using row-based replication, setting a
slave's slave_rows_search_algorithms variable to HASH_SCAN
caused an ER_RECORD_NOT_FOUND error even though that record
existed in the storage layer. This fix ensures that the unique
key for each record is correctly maintained and such a
situation does not occur. (Bug #72788, Bug #18860225)
* Replication: When an event group was spanned across multiple
relay log files, a slave could incorrectly identify
GTID-header group boundaries. This meant that when a
transaction was retried, or if the SQL thread was stopped in
the middle of a transaction after some rotates, the
Gtid_log_event was being silently skipped on the slave, and
the transaction was logged with the slave's GTID. This problem
also impacted on using START SLAVE UNTIL MASTER_LOG_POS =
log_pos; with GTIDs enabled. If log_pos was in the middle of a
transaction, the Gtid_log_event was not correctly detected as
the beginning of the transaction and replication stopped
before this event. With this fix, threads correctly detect
that they are part of a group, and this is used to check if a
Gtid_log_event is part of a transaction. (Bug #72313, Bug
#18652178, Bug #18306199)
* Replication: The error messages generated when a duplicate
server UUID causes issues during replication have been
improved. The slave error now identifies the duplicate server
UUID and the master error identifies the zombie thread that
has been killed. (Bug #72578, Bug #18731211)
* Replication: Replication of tables that contained temporal
type fields (such as TIMESTAMP, DATETIME, and TIME) from
different MySQL versions failed due to incompatible TIMESTAMP
types. The fractional TIMESTAMP format added in MySQL 5.6.4
was not being correctly converted. You can now replicate a
TIMESTAMP in either format correctly according to the
slave_type_conversions variable. (Bug #70124, Bug #17532932)
* Replication: The CLIENT_REMEMBER_OPTIONS flag for compressed
slave connections is no longer reset and all options are
retained. This restores functionality of all options to
compressed slave connections. (Bug #72901, Bug #18923691, Bug
#73324, Bug #19244772)
* 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)
* Replication: Client applications should be able to set the
BINLOG_DUMP_NON_BLOCK flag in the initial handshake packet
(COM_BINLOG_DUMP). Clients 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 release.
As part of this fix, a new --connection-server-id 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)
* Replication: A group of threads involved in acquiring locks
could deadlock when the following events occurred:
1. Dump thread reconnects from slave; on master, a new dump
thread tries to kill zombie dump threads; having acquired
the thread's LOCK_thd_data, it is about to acquire
LOCK_log.
2. Application thread executing show binary logs, having
acquired LOCK_log and about to acquire LOCK_index.
3. Application thread executing PURGE BINARY LOGS; having
acquired LOCK_index, it is about to acquire
LOCK_thread_count.
4. Application thread executing SHOW PROCESSLIST (or SELECT
* FROM INFORMATION_SCHEMA.PROCESSLIST), having acquired
LOCK_thread_count and about to acquire the zombie dump
thread's LOCK_thd_data.
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
LOCK_log and LOCK_index, as well as rules for ordering
LOCK_thread_count and LOCK_thd_data, but there are no rules
for ordering across these two sets of locks. This was because
the internal mysqld_list_processes() function invoked by SHOW
PROCESSLIST acquired LOCK_thread_count for the complete
lifetime of the function as well as acquiring and releasing
each thread's 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_th
read_count
(Bug #69954, Bug #17283409)
References: See also Bug #73475, Bug #19364731, Bug #19365180.
* Replication: When 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 immediately by 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" transactions:
+ No empty transaction was generated for CREATE TEMPORARY
TABLE or DROP TEMPORARY TABLE statements.
+ If the slave used a database filter (--replicate-do-db or
--replicate-ignore-db option), no empty transaction was
generated.
(Bug #71376, Bug #18095502, Bug #18145032)
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql