MySQL Community Server 5.7.24 has been released
Posted by: Gipson Pulla
Date: October 22, 2018 09:32AM
Date: October 22, 2018 09:32AM
Dear MySQL users, MySQL Server 5.7.24, a new version of the popular Open Source Database Management System, has been released. MySQL 5.7.24 is recommended for use on production systems. For an overview of what's new in MySQL 5.7, please see http://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html For information on installing MySQL 5.7.24 on new servers, please see the MySQL installation documentation at http://dev.mysql.com/doc/refman/5.7/en/installing.html MySQL Server 5.7.24 is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/mysql/ MySQL Server 5.7.24 is also available from our repository for Linux platforms, go here for details: http://dev.mysql.com/downloads/repo/ Windows packages are available via the Installer for Windows or .ZIP (no-install) packages for more advanced needs. The point and click configuration wizards and all MySQL products are available in the unified Installer for Windows: http://dev.mysql.com/downloads/installer/ 5.7.24 also comes with a web installer as an alternative to the full installer. The web installer doesn't come bundled with any actual products and instead relies on download-on-demand to fetch only the products you choose to install. This makes the initial download much smaller but increases install time as the individual products will need to be downloaded. We welcome and appreciate your feedback, bug reports, bug fixes, patches, etc.: http://bugs.mysql.com/report.php The following link lists the changes in the MySQL 5.7 since the release of MySQL 5.7.23. It may also be viewed online at http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-24.html Enjoy! Changes in MySQL 5.7.24 (2018-10-22, General Availability) Deprecation and Removal Notes * InnoDB; Partitioning: Support for placing table partitions in shared tablespaces is deprecated and will be removed in a future version of MySQL. 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 http://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html * 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. 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) Security Notes * 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. * MySQL Enterprise Edition now provides data masking and de-identification capabilities, implemented as a plugin library containing a plugin and a set of user-defined 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 http://dev.mysql.com/doc/refman/8.0/en/data-masking.html Functionality Added or Changed * 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) * The zlib library version bundled with MySQL was raised 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 operations with row sizes very close to the maximum row size that were successful in earlier releases could now fail. Bugs Fixed * 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 #95045, Bug #27903881) References: See also: Bug #80669, Bug #22899690. * 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 #28092714) * 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: Entries in the relay log info log (the slave_relay_log_info table) for the Group Replication-specific channels group_replication_applier and group_replication_recovery were not being cleared by a RESET SLAVE or RESET SLAVE ALL command. (Bug #27411175) * 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: When group_replication_group_seeds contained a DNS based entry which resolved to its own local address, Group Replication could not 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 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) * 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 failed. mysqldump now removes NO_AUTO_CREATE_USER from the definition of dumped stored programs. (Bug #27931181, Bug #90624) * 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) * 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 Debian9). (Bug #24008883, Bug #27990381) * 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) On Behalf of MySQL/ORACLE RE Team Gipson Pulla
Subject
Views
Written By
Posted
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.