[prev in list] [next in list] [prev in thread] [next in thread]
List: mysql-announce
Subject: MySQL Community Server 5.7.24 has been released
From: Gipson Pulla <gipson.pulla () oracle ! com>
Date: 2018-10-22 15:26:11
Message-ID: 2d66920d-691f-4f0b-b181-6d95623b1e6b () default
[Download RAW message or body]
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
--
MySQL Announce Mailing List
For list archives: http://lists.mysql.com/announce
To unsubscribe: http://lists.mysql.com/announce
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic