Changes in MySQL 5.7.27:
Keyring Notes
The keyring_aws plugin has been updated to use the latest AWS SDK and so that it works with OpenSSL 1.1.
Packaging Notes
Binary packages that include curl rather than linking to the system curl library now use curl 7.64.0.
X Plugin Notes
On Windows, X Plugin logged some messages that were unnecessary or insufficiently informative. The messages have been removed or improved as appropriate.
Functionality Added or Changed
Microsoft Windows: A new warning message now reminds DBAs that connections made using the MySQL named pipe on Windows has limited the permissions a connector can request on the named pipe.
Previously, the named_pipe_full_access_group system variable was set to a value that maps to the built-in Windows Everyone group (SID S-1-1-0) by default. However, this group is not ideal and should be replaced with a group that restricts its membership for connectors that are unable to request fewer permissions on the MySQL named pipe.
The new warning is written to the error log at startup if the string value assigned to named_pipe_full_access_group is '*everyone*' (or the Windows System Language equivalent) and named pipes are enabled. In addition, the warning is written to the error log and raised to the client if the system variable is reset to the Everyone group at runtime.
Bugs Fixed
InnoDB: Insufficient memory barriers in the rw-lock implementation caused deadlocks on ARM.
Thanks to Yibo Cai from Arm Technology for the contribution.
InnoDB: Manually changing the system time while the MySQL server was running caused page cleaner thread delays.
InnoDB: During log application, after an OPTIMIZE TABLE operation, InnoDB did not populate virtual columns before checking for virtual column index updates.
InnoDB: An INSERT operation involving a generated virtual BLOB column resulted a secondary index being updated with an incorrect value.
InnoDB: A full-text cache lock taken when data is synchronized was not released if the full-text cache size exceeded the full-text cache size limit.
InnoDB: Client sessions using different auto_increment_increment values while performing concurrent insert operations could cause a duplicate key error.
Partitioning: ALTER TABLE ... EXCHANGE PARTITION failed with the error Non matching attribute 'ROW_FORMAT' between partition and table when the partitioned table had partitions using different row formats, even when the partition to be exchanged used the same row format as the non-partitioned table.
Replication: The error message that is issued for a discrepancy between the number of group members and the auto-increment interval incorrectly referred to the group_replication_auto_increment_increment system variable, instead of the auto_increment_increment system variable. The value of auto_increment_increment is changed to the value specified by group_replication_auto_increment_increment when Group Replication starts, but only if auto_increment_increment and auto_increment_offset have their default values, and from MySQL 8.0, only in multi-primary mode. The value of auto_increment_increment was always the value that was checked for the error message, and it has now been corrected to give the accurate system variable name.
Replication: When events generated by one MySQL server instance were written to the binary log of another instance, the second server implicitly assumed that the first server supported the same number of binary log event types as itself. Where this was not the case, the event header was handled incorrectly. The issue has now been fixed. Thanks to Facebook for the contribution.
Replication: In Group Replication, joining members could wrongly identify themselves as incompatible with an existing replication group even if there were members at the same version already in the group, because they checked against all other members, including the member at the highest version. Joining members also included their own version in the compatibility check. Now, joining members only compare themselves with the existing group member at the lowest version, and do not count their own version.
Replication: If a FLUSH LOGS statement was issued before the binary log file was initialized, the statement attempted to write a binary log rotation event to the uninitialized file. The server now checks first that a binary log file is available.
Replication: When a MEMORY table is implicitly deleted on a master following a server restart, the master writes a DELETE statement to the binary log so that slaves also empty the table. This generated event now includes a comment in the binary log so that the reason for the DELETE statement is easy to identify. Thanks to Daniël van Eeden for the contribution.
Replication: With statement-based replication in use, if super_read_only was set to ON for a server at the point when a no-op transaction was between its UPDATE and COMMIT operations, the transaction was written to the binary log and assigned a GTID. The transaction is now blocked in this situation. From MySQL 8.0, the value of super_read_only cannot be changed while a transaction is in progress.
Replication: The group communication engine for Group Replication (XCom, a Paxos variant) did not handle out of memory errors in an appropriate way. If memory could not be allocated to make a copy of the payload for a message, an error was logged but the message was still sent, with a null payload. The Group Communication System (GCS) on the receiving member discarded the message as empty, and the XCom instance on the receiving member accepted this action and did not retry, resulting in the message effectively being skipped. This caused the GTID set on the receiving member to diverge from the group, leading to replication errors. XCom now terminates gracefully if it experiences an out of memory error, so that this situation cannot occur.
Replication: In query log events in the binary log, the thread ID used for the execution of DROP TABLE and DELETE statements was identified incorrectly or not at all. On a multi-threaded replication slave, where temporary tables were involved (which require the correct thread ID as they are session specific), this omission resulted in errors when using mysqlbinlog to replay the binary log for point-in-time recovery. The thread ID is now set correctly.
Replication: When a slave server logs master status and connection information to a table (master_info_repository=TABLE), which is the default in MySQL 8.0, the mysql.slave_master_info table was not being updated on shutdown if the server was in super read only mode (super_read_only=ON). No error was written to the error log at this time, but replication failed after server startup because the master log file and master log position information was out of date. The thread that updates the master info log at shutdown is now excluded from read-only checks like other replication threads are, so it can update the table even if the server is in super read only mode. Error handling for a slave that is shutting down has also been improved so that any failure to write to the slave status logs results in an error in the error log.
An overly strict assertion could be raised during sorting of stored program local objects.
Installing from RPM packages could result in an error log with incorrect permissions.
Enabling audit log encryption could cause a server exit.
On Debian and Ubuntu, MySQL packages did not enable mysql.service after upgrades from native MySQL packages.
The server did not properly close shared-memory connections when an error occurred, which could result in unexpected server behavior.
MySQL Installer did not install OpenSSL DLL dependencies if the Development component was not selected.
The parser could leak memory for certain multiple-statement queries.
CREATE USER and ALTER USER did not check the validity of a hashed authentication string when used with IDENTIFIED WITH auth_plugin AS 'hash_string' syntax.
For InnoDB tables that contained an index on a VARCHAR column and were created prior to MySQL 5.7.23, some simple ALTER TABLE statements that should have been done in place were performed with a table rebuild after an upgrade to MySQL 5.7.23 or higher.
HANDLER statements did not always work correctly with tables having generated columns.
Session-tracking information in the client/server protocol could be mishandled.
With the PAD_CHAR_TO_FULL_LENGTH SQL mode enabled, password changes failed, with no warning or error reported.
The audit_log plugin did not log UNINSTALL PLUGIN audit_log statements.
audit_log filtering operations could leak memory.
An index defined on a virtual generated column could fail to be updated if the column had a base column in a foreign key relationship.
Privileges for dropping some Performance Schema tables were checked incorrectly.
A query that employed a derived table which included an ORDER BY was not always handled correctly.
Base columns were not excluded from index-only access by a generated column.
A thread pool group could be blocked when a thread process tick time exceeded the maximum permitted value. The tick time now uses a larger data type to permit larger values.
MySQL does not support OpenSSL session tickets, but did not set the SSL_OP_NO_TICKET flag to inform OpenSSL of that. The flag is now set.
The audit_null plugin did not properly check for a null event record.
UpdateXML() did not always free memory properly in certain cases.
Empty values in the name column of the mysql.plugin system table caused the server to exit during startup.
With the thread_pool plugin enabled, the Performance Schema status_by_thread table contained no data.
If an INSTALL PLUGIN statement contained invalid UTF-8 characters in the shared library name, it caused the server to hang (or to raise an assertion in debug builds).
Inner tables of different semijoin nests were interleaved during materialization, which could lead to a different result for the same query when it used a different query plan. To keep this from occurring, a check is added to prevent such interleaving.
A query involving GROUP BY on a TIMESTAMP column resulted in a duplicate entry for key (ER_DUP_ENTRY) error. This problem arose when TIMESTAMP values were inserted into a table using a given setting for the time zone and these values were later fetched after the time zone setting had been changed, such that at least some of the inserted TIMESTAMP values occurred during the hour that the time changed from standard to daylight time (DST) in the new time zone, during which time the same TIMESTAMP value can exist twice. Now, when the server would otherwise return the error DUPLICATE ENTRY FOR KEY 'group_key', if the grouping involves a TIMESTAMP column, it instead raises the error Grouping on temporal is non-deterministic for time zones having DST. Please consider switching to UTC for this query.
In addition, it is suggested to set explicit_defaults_for_timestamp to ON as well as one or more of MODE_NO_ZERO_IN_DATE, MODE_NO_ZERO_DATE, or MODE_INVALID_DATES as part of the server SQL mode to help avoid this issue.
db5b8d2e9b