Changes in MySQL 5.7.24 (2018-10-22, General Availability)

• Deprecation and Removal Notes

• Packaging Notes

• Pluggable Authentication

• Security Notes

• Functionality Added or Changed

• Bugs Fixed

Deprecation and Removal Notes

• InnoDB; Partitioning: Support for placing table partitions in shared tablespaces is deprecated and will be removed in a future MySQL version. Shared tablespaces include the system tablespace and general tablespaces. For information about identifying partitions in shared tablespaces and moving them to file-per-table tablespaces, see Preparing Your Installation for Upgrade. (WL #11571, WL #9286)

• InnoDB: Support for TABLESPACE = innodb_file_per_table and TABLESPACE = innodb_temporary clauses with CREATE TEMPORARY TABLE is deprecated and will be removed in a future MySQL version. (WL #12179)

Packaging Notes

• Binary packages that include curl rather than linking to the system curl library now use curl 7.60.0 rather than 7.45.0. (Bug #28043702)

• The zlib library bundled with MySQL has been upgraded from version 1.2.3 to version 1.2.11. MySQL implements compression with the help of the zlib library.

  The zlib compressBound() function in zlib 1.2.11 returns a slightly higher estimate of the buffer size required to compress a given length of bytes than it did in zlib version 1.2.3. The compressBound() function is called by InnoDB functions that determine the maximum row size permitted when creating compressed InnoDB tables or inserting rows into compressed InnoDB tables. As a result, CREATE TABLE ... ROW_FORMAT=COMPRESSED or INSERT and UPDATE operations with row sizes very close to the maximum row size that were successful in earlier releases could now fail. For additional information, see Changes in MySQL 5.7. (WL #10551)

Pluggable Authentication

• Microsoft Windows: On Windows, MySQL Enterprise Edition distributions now bundle the Cyrus SASL library files libsasl.dll and saslSCRAM.dll so that the LDAP authentication plugins can use the SCRAM-SHA-1 authentication method. (WL #11927)

Security Notes

• MySQL Enterprise Edition now provides data masking and de-identification capabilities, implemented as a plugin library containing a plugin and a set of loadable functions. Data masking hides sensitive information by replacing real values with substitutes. MySQL Enterprise Data Masking and De-Identification functions enable masking existing data using several methods such as obfuscation (removing identifying characteristics), generation of formatted random data, and data replacement or substitution. For example:

  mysql> SET @ssn = gen_rnd_ssn();
  mysql> SET @masked_ssn1 = mask_ssn(@ssn);
  mysql> SET @masked_ssn2 = mask_outer(mask_inner (@ssn,4,5,'A'), 3,0,'B');
  mysql> SELECT @ssn, @masked_ssn1, @masked_ssn2;
  +-------------+--------------+--------------+
  | @ssn        | @masked_ssn1 | @masked_ssn2 |
  +-------------+--------------+--------------+
  | 980-31-2838 | XXX-XX-2838  | BBB-AA-2838  |
  +-------------+--------------+--------------+

  For more information, see MySQL Enterprise Data Masking and De-Identification. (WL #7722)

Functionality Added or Changed

• Replication: Use group_replication_exit_state_action determine how Group Replication behaves when a member leaves the group involuntarily, such as when it is expelled from the group due to an unstable network connection. When group_replication_exit_state_action is ABORT_SERVER, upon exiting the group unintentionally, the instance shuts MySQL down, and when it is READ_ONLY, the instance sets MySQL to super read-only mode instead, and its state to ERROR. (WL #12064)

• Previously, file I/O performed in the I/O cache in the mysys library was not instrumented, affecting in particular file I/O statistics reported by the Performance Schema about the binary log index file. Now, this I/O is instrumented and Performance Schema statistics are accurate. Thanks to Yura Sorokin for the contribution. (Bug #27788907, Bug #90264)

Bugs Fixed

• Important Change: Stored program definitions in mysqldump dump files sometimes included the NO_AUTO_CREATE_USER SQL mode. Because that mode has been removed in MySQL 8.0, loading such a dump file into a MySQL 8.0 server fails. mysqldump now removes NO_AUTO_CREATE_USER from the definition of dumped stored programs.

  Important

  MySQL 5.7 limitation: it remains stripped even when importing back into MySQL 5.7, which means that stored routines could behave differently after restoring a dump if they relied on that particular sql_mode.

  (Bug #27931181, Bug #90624)

• InnoDB: An ALTER TABLE operation that added a primary key produced a segmentation fault. (Bug #28395278)

  References: This issue is a regression of: Bug #27753193.

• InnoDB: A query that scanned the primary key of a table did not return the expected result. (Bug #28104394, Bug #91032)

• InnoDB: A query interruption during a lock wait caused an error. (Bug #28068293)

• InnoDB: An index record was not found when updating a secondary index defined on a generated column. (Bug #27968952)

• InnoDB: The update log applied as part of an online ALTER TABLE operation did not take into account the computed value of the generated column in the old row while updating the secondary index. (Bug #27921932)

• InnoDB: An unsupported DDL operation involving a foreign key constraint raised an assertion. (Bug #27912873)

• InnoDB: An attempted foreign key check on a discarded table caused a segmentation fault. (Bug #27804668)

• InnoDB: An assertion was raised during an OPTIMIZE TABLE operation. (Bug #27753193)

• InnoDB: A foreign key constraint name was duplicated during a rename table operation, causing a failure during later query execution. (Bug #27545888)

• InnoDB: In a function called before the execution of a statement in a stored procedure, a read and write operation on trx->lock.start_stmt was not protected by a mutex. (Bug #27325898)

• InnoDB: An error occurred during a DDL operation due to a mismatch in a REDUNDANT row format calculation that determines the length of the online log. (Bug #26375771)

• InnoDB: The location of the Innodb Merge Temp File that reported by the wait/io/file/innodb/innodb_temp_file Performance Schema instrument was incorrect. (Bug #21339079, Bug #77519)

• Partitioning: When a CREATE TABLE ... PARTITION BY ... statement failed due to an invalid partition definition, the server did not remove any partition files which might have been created prior to encountering the invalid PARTITION clause. (Bug #27798708)

  References: See also: Bug #88043, Bug #26945644.

• Partitioning: It was possible to perform FLUSH TABLES FOR EXPORT on a partitioned table created with innodb_file_per_table=1 after discarding its tablespace. Attempting to do so now raises ER_TABLESPACE_DISCARDED. (Bug #90545, Bug #27903881)

  References: See also: Bug #80669, Bug #22899690.

• Replication: When the binlog_group_commit_sync_delay system variable is set to a wait time to delay synchronization of transactions to disk, and the binlog_group_commit_sync_no_delay_count system variable is also set to a number of transactions, the MySQL server exits the wait procedure if the specified number of transactions is reached before the specified wait time is reached. The server manages this process by checking on the transaction count after a delta of one tenth of the time specified by binlog_group_commit_sync_delay has elapsed, then subtracting that interval from the remaining wait time.

  If rounding during calculation of the delta meant that the wait time was not a multiple of the delta, the final subtraction of the delta from the remaining wait time would cause the value to be negative, and therefore to wrap to the maximum wait time, making the commit hang. The data type for the remaining wait time has now been changed so that the value does not wrap in this situation, and the commit can proceed when the original wait time has elapsed. Thanks to Yan Huang for the contribution. (Bug #28091735, Bug #91055)

• Replication: An assertion was raised in debug builds because the MySQL server recorded a GTID consistency violation, but did not remove the record after the relevant statement failed to execute successfully. The handling of this situation has now been improved to ensure that the server checks at the end of a transaction whether a GTID consistency violation was produced by a failed statement, and if this is the case, restores the previous GTID consistency state. (Bug #27903831, Bug #90551)

• Replication: With GTIDs in use for replication, transactions including statements that caused a parsing error (ER_PARSE_ERROR) could not be skipped manually by the recommended method of injecting an empty or replacement transaction with the same GTID. This action should result in the slave identifying the GTID as already used, and therefore skipping the unwanted transaction that shared its GTID. However, in the case of a parsing error, because the statement was parsed before the GTID was checked to see if it needed to be skipped, the replication applier thread stopped due to the parsing error, even though the intention was for the transaction to be skipped anyway.

  With this fix, the replication applier thread now ignores parsing errors if the transaction concerned needs to be skipped because the GTID was already used. Note that this behavior change does not apply in the case of workloads consisting of binary log output produced by mysqlbinlog. In that situation, there would be a risk that a transaction with a parsing error that immediately follows a skipped transaction would also be silently skipped, when it ought to raise an error. (Bug #27638268)

• Replication: When a RESET SLAVE statement was issued on a replication slave with GTIDs in use, the existing relay log files were purged, but the replacement new relay log file was generated before the set of received GTIDs for the channel had been cleared. The former GTID set was therefore written to the new relay log file as the PREVIOUS_GTIDS event, causing a fatal error in replication stating that the slave had more GTIDs than the master, even though the gtid_executed set for both servers was empty. Now, when RESET SLAVE is issued, the set of received GTIDs is cleared before the new relay log file is generated, so that this situation does not occur. (Bug #27636289)

• Replication: The master's receiver thread for semisynchronous replication held a mutex while reading acknowledgements from slaves, but the same mutex was required to add or remove a semisynchronous slave, causing those operations to be delayed by the acknowledgement activity. The issue has now been fixed by not acquiring the mutex to read the acknowledgements from slaves. (Bug #27610678, Bug #89370)

• Replication: Automatic retrying of transactions on a replication slave, as specified by the slave_transaction_retries system variable, was taking place even if the transaction had a non-temporary error that would repeat on retrying or that indicated wider issues. Now, transactions are only automatically retried if there is either no error, or an error that is only temporary. (Bug #27373559, Bug #89143)

• Replication: Attempting to uninstall the plugin while START GROUP_REPLICATION executed could result in unexpected behavior. (Bug #25423650, Bug #91042, Bug #28088177)

• Replication: When FLUSH statements for specific log types (such as FLUSH SLOW LOGS) resulted in an error, the statements were still written to the binary log. This stopped replication because the error had occurred on the master, but did not occur on the slave. MySQL Server now checks on the outcome of these FLUSH statements, and if an error occurred, the statement is not written to the binary log. (Bug #24786290, Bug #83232)

• Replication: The PASSWORD() function, which produces a hash of the password, was deprecated in MySQL 5.7 and removed in MySQL 8.0. When a SET PASSWORD statement that used this function was replicated from a MySQL 5.6 master to a MySQL 5.7 slave, or from a MySQL 5.7 master with the log_builtin_as_identified_by_password system variable set to ON to a MySQL 5.7 slave, the password hash was itself also hashed before being stored on the slave. The issue has now been fixed and the replicated password hash is stored as originally passed to the slave. (Bug #24687073)

• Replication: If an ORDER BY clause was used in retrieving records from certain Performance Schema tables relating to replication, an empty set was returned. The issue has now been fixed. (Bug #22958077, Bug #80777)

• Replication: When replication channels are used on a slave for multi-source replication, a START SLAVE statement that does not specify an individual channel (so without the FOR CHANNEL clause) should start the I/O thread and the SQL thread for all of the channels on the replication slave. However, if a RESET SLAVE statement was used on such a slave, a subsequent START SLAVE statement did not start the non-default channels. Now, replication channels that are deinitialized as a result of a RESET SLAVE statement, rather than as a result of an error in the initialization process, are identified and are restarted by a START SLAVE statement that applies to all channels. (Bug #22809607)

• Replication: Issuing RESET SLAVE on a replication slave does not change any replication connection parameters such as master host, master port, master user, or master password, which are retained in memory. However, these connection parameters are reset if you issue RESET SLAVE ALL. Previously, if the slave mysqld was restarted immediately after issuing RESET SLAVE (including a server crash as well as a deliberate restart), the connection parameters were reset as if RESET SLAVE ALL had been used.

  Now, when master_info_repository=TABLE is set on the server (which is the default from MySQL 8.0), replication connection parameters are preserved in the crash-safe InnoDB table mysql.slave_master_info as part of the RESET SLAVE operation. They are also retained in memory. In the event of a server crash or deliberate restart after issuing RESET SLAVE but before issuing START SLAVE, the replication connection parameters are retrieved from the table and reused for the new connection.

  If master_info_repository=FILE is set on the server (which is the default in MySQL 5.7), replication connection parameters are only retained in memory, so the behavior remains the same as previously. If the slave mysqld is restarted due to a server crash or a deliberate restart immediately after issuing RESET SLAVE, the connection parameters are lost. In that case, you must issue a CHANGE MASTER TO statement after the server start to respecify the connection parameters before issuing START SLAVE.

  If you want to reset the connection parameters intentionally, you need to use RESET SLAVE ALL, which clears the connection parameters. In that case, you must issue a CHANGE MASTER TO statement after the server start to specify the new connection parameters. (Bug #20280946)

• Replication: Compilation warnings related to unused functions in xdr_utils have been reduced. Thanks to Zsolt Parragi for the patch. (Bug #91071, Bug #28099963)

• Replication: If the group_replication_recovery_retry_count variable was modified while the member was already making a reconnection attempt, the connection attempt could enter an infinite loop. (Bug #91057, Bug #28092714)

• Group Replication: Entries in the relay log info log for the group_replication_applier and group_replication_recovery channels were not cleared by RESET SLAVE or RESET SLAVE ALL. (Bug #27411175)

• Group Replication: When group_replication_group_seeds contained a DNS based entry which resolved to its own local address, Group Replication was unable to start. (Bug #90483, Bug #27882096, Bug #28074929)

• Microsoft Windows: On Windows, uninstallation of the MySQL Server MSI package through MySQL Installer produced a spurious popup window. (Bug #27463864)

• On the Fedora 29 platform, OpenSSL 1.0.x is used to build packages because OpenSSL 1.1.1 support is not ready. If you build MySQL from source, it is recommended that you build using the compat-openssl10-devel package. (Bug #28737143)

• On the Fedora 29 platform, upgrading from MariaDB to MySQL 8.0.13 failed due to missing obsoletes. (Bug #28727698)

• Address Sanitizer revealed SSL/Zlib link problems related to the audit_log plugin; these were corrected. (Bug #28525431, Bug #92082)

• Compilation failed for GCC 8 with MySQL configured to use some system libraries. (Bug #28471072, Bug #91914)

• Concurrent INSERT and SELECT statements on a MERGE table could result in a server exit. (Bug #28379285)

• For UPDATE and DELETE statements that produce an error due to sql_safe_updates being enabled, the error message was insufficiently informative. The message now includes the first diagnostic that was produced, to provide information about the reason for failure. For example, the message may indicate that the range_optimizer_max_mem_size value was exceeded or type conversion occurred, either of which can preclude use of an index.

  Additionally: (1) Using EXPLAIN for such statements does not produce an error, enabling users to see from EXPLAIN plus SHOW WARNINGS output why an index is not used. (2) For multiple-table deletes and updates, an error is produced with safe updates enabled only if any target table uses a table scan. (Bug #28145710, Bug #91080)

• MySQL Server and test RPM packages were missing perl-Data-Dumper as a dependency. (Bug #28144933, Bug #72926)

• For the mysql client, the -b short option was associated with two long options, --no-beep and --binary-as-hex. The -b option now is associated only with --no-beep. (Bug #28093271)

• The WITH_GMOCK CMake option did not handle Windows path names properly. (Bug #28061409, Bug #90964)

• Group lookups for LDAP authentication plugins could fail if the user had insufficient privileges. Now, group search operations bind again using root credentials if those are available. (Bug #28016008)

• Generated columns having indexes and that used a string function were not always populated correctly. (Bug #27973409)

• Very long table keys were handled incorrectly on replication slaves. (Bug #27930505)

• During server startup/shutdown, PID files could be mishandled. (Bug #27919254)

• If flushing the error log failed due to a file permission error, the flush operation did not complete. (Bug #27891472, Bug #90505)

  References: This issue is a regression of: Bug #26447825.

• For MEMORY tables, memory overflow errors could occur. (Bug #27799513)

• When converting from a BLOB (or TEXT) type to a smaller BLOB (or TEXT) type, no warning or error was reported informing about the truncation or data loss. Now an appropriate error is issued in strict SQL mode and a warning in nonstrict SQL mode. (Bug #27788685, Bug #90266)

• The severity of messages produced by the server about being unable to read key files has been escalated from INFORMATION to WARNING. (Bug #27737195)

• Failure to create a temporary table during a MyISAM query could cause a server exit. Thanks to Facebook for the patch. (Bug #27724519, Bug #90145)

• parser_max_mem_size was ineffective when parsing stored program definitions. (Bug #27714748)

• Some typos in server error messages were fixed. Thanks to Thomas Tsiakalakis for the contribution. (Bug #27688294, Bug #90048)

• Host name resolution errors could cause the audit_log plugin to fail. (Bug #27567003)

• Unsuccessful connection attempts were not being written to the error log when log_error_verbosity=3. (Bug #27539838)

• An earlier code cleanup caused FEDERATED storage engine failures. (Bug #27493633, Bug #89537)

  References: This issue is a regression of: Bug #25943754.

• An attempted read of an uncommitted transaction raised an assertion. (Bug #26876608)

• ALTER TABLE ... REORGANIZE PARTITION ... could result in incorrect behavior if any partition other than the last was missing the VALUES LESS THAN part of the syntax. (Bug #26791931)

• The audit_log plugin could deadlock the server. (Bug #24353553)

• Debug symbol packages are now included for all apt platforms (previously, they were only available on Debian 9). (Bug #24008883, Bug #27990381)

• For InnoDB tables, the storage engine API could return incorrect values for the maximum supported key-part length. (Bug #20629014, Bug #76096)

• Specifying the maximum possible value for a YEAR column failed when expressed as a real constant such as 2155.0E00 or 2.15E3. (Bug #91226, Bug #28172538)

• It was possible for a subquery that used a unique key on a column allowing NULL to return multiple rows. (Bug #88670, Bug #27182010)