MySQL 5.7 Release Notes - Download - MySQL

MySQL 5.7 Release NotesReferences: See also Bug #16862316, Bug #17588348, Bug #17648468.• Partitioning: Selecting from a table having multiple columns in its primary key and partitioned byLIST COLUMNS(R), where R was the last (rightmost) column listed in the primary key definition,returned an incorrect result. (Bug #17909699, Bug #71095)• Replication: Log rotation events could cause group_relay_log_pos to be moved forwardincorrectly within a group. This meant that, when the transaction was retried, or if the SQL threadwas stopped in the middle of a transaction following one or more log rotations (such that thetransaction 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 thecoordinates of the SQL thread when updating the log position as part of a relay log rotation wherebyit was possible to update the SQL thread's coordinates when not using a multi-threaded slave, evenin the middle of a group. (Bug #18482854)• Replication: When replicating from a MySQL 5.5 or earlier master toa MySQL 5.6 or later slave, the SOURCE_UUID column of the slave'sperformance_schema.replication_connection_status table contained random data. Nowin such cases, SOURCE_UUID is left blank. (Bug #18338203)• Replication: During relay log initialization, the thread context was used as a flag for thereconstruction of the retrieved GTID set, an operation that does not depend on this parameter. Thiscould be problematic if relay log initialization was called in another context other than the legacyreplication scenario; if the invocation was made in a context where the thread context was alwayspresent, this prevented the set's reconstruction. The opposite could also happen when the threadcontext 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 thereconstruction in all contexts but prevents multiple invocations. (Bug #18337036)• Replication: In certain cases, the server mishandled triggers and stored procedures that tried tomodify other tables when called by CREATE TABLE ... SELECT. This is now handled correctly asan error. (Bug #18137535)• Replication: When used on a table employing a transactional storage engine, a failed TRUNCATETABLE was still written to the binary log and thus replayed on the slave. This could lead toinconsistency 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: On Windows, mysqldump failed if the error log file was deleted (missing) from theactive MySQL server. (Bug #17076131)• Replication: When the binary log was rotated due to receipt of a SIGHUP signal, the new binary logdid not contain the Previous_gtid_event required for subsequent processing of that binary log'sGTID events. Now when SIGHUP is received, steps are taken to insure that the server writes thenecessary Previous_gtid_event to the new log before writing any GTID events to the new log.(Bug #17026898)• Replication: When gtid_mode=ON, and a transaction is filtered out on the slave, the GTID of thetransaction is still logged on the slave as an “empty” transaction (consisting of a GTID followedimmediately by BEGIN and then COMMIT). This is necessary to prevent the transaction from beingretransmitted the next time the slave reconnects or is involved in a failover. The current fix addressestwo issues relating to such “empty” transactions:• No empty transaction was generated for CREATE TEMPORARY TABLE or DROP TEMPORARYTABLE statements.9