Bjorn Munch MySQL Community Server 5.7.5 has been released (part 2/3)
Sep 25, 2014; 22:54
MySQL Community Server 5.7.5 has been released (part 2/3)
[Due to length restrictions, this announcement is split into three parts. This is part 2.]
* 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: 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
This site manages and broadcasts several email lists pertaining to Lasso Programming and technologies related and used by Lasso developers. Sign up today!