MySQL Forums
Forum List  »  Announcements

MySQL Community Server 5.7.24 has been released
Posted by: Gipson Pulla
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

Options: ReplyQuote


Subject
Views
Written By
Posted
MySQL Community Server 5.7.24 has been released
6935
October 22, 2018 09:32AM


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.