Changes in MySQL 5.7.29:
Audit Log Notes
ANALYZE TABLE statements now produce read audit events.
Packaging Notes
Binary packages that include curl rather than linking to the system curl library have been upgraded to use curl 7.66.0.
Bugs Fixed
InnoDB: os_file_get_parent_dir warnings were encountered when compiling MySQL with GCC 9.2.0.
InnoDB: An internal function (btr_push_update_extern_fields()) used to fetch newly added externally stored fields and update them during a pessimistic update or when going back to a previous version of a record was no longer required. Newly added externally stored fields are updated by a different function. Also, the method used to determine the number of externally stored fields was corrected.
InnoDB: A comparison function found two records to be equal when attempting to merge non-leaf pages of a spatial index. The function was unable to handle this unexpected condition, which resulted in a long semaphore wait and an eventual assertion failure.
InnoDB: A tablespace import operation that failed due to the source and destination tables being defined with different DATA DIRECTORY clauses reported an insufficiently descriptive schema mismatch error. Moreover, if a .cfg file was not present, the same operation would raise an assertion failure. A more informative error message is now reported in both cases before the import operation is terminated due to the data directory mismatch.
InnoDB: Criteria used by the btr_cur_will_modify_tree() function, which detects whether a modifying record needs a modifying tree structure, was insufficient.
InnoDB: An ALTER TABLE ... DISCARD TABLESPACE operation caused a hang condition.
InnoDB: A code regression was addressed by prohibiting unnecessary implicit to explicit secondary index lock conversions for session temporary tables.
InnoDB: A tablespace import operation raised an assertion when the cursor was positioned on a corrupted page while purging delete-marked records. Instead of asserting when encountering a corrupted page, the import operation is now terminated and an error is reported.
Replication: When a member is joining or rejoining a replication group, if Group Replication detects an error in the distributed recovery process (during which the joining member receives state transfer from an existing online member), it automatically switches over to a new donor, and retries the state transfer. The number of times the joining member retries before giving up is set by the group_replication_recovery_retry_count system variable. The Performance Schema table replication_applier_status_by_worker displays the error that caused the last retry. Previously, this error was only shown if the group member was configured with parallel replication applier threads (as set by the slave_parallel_workers system variable). If the group member was configured with a single applier thread, the error was cleared after each retry by an internal RESET SLAVE operation, so it could not be viewed. This was also the case for the output of the SHOW SLAVE STATUS command whether there were single or multiple applier threads. The RESET SLAVE operation is now no longer carried out after retrying distributed recovery, so the error that caused the last retry can always be viewed.
Replication: A memory leak could occur when a failed replication group member tried to rejoin a minority group and was disallowed from doing so.
Replication: If a replication slave was set up using a CHANGE MASTER TO statement that did not specify the master log file name and master log position, then shut down before START SLAVE was issued, then restarted with the option --relay-log-recovery set, replication did not start. This happened because the receiver thread had not been started before relay log recovery was attempted, so no log rotation event was available in the relay log to provide the master log file name and master log position. In this situation, the slave now skips relay log recovery and logs a warning, then proceeds to start replication.
Replication: When GTIDs are enabled on a replication master and slave, and the slave connects to the master with the MASTER_AUTO_POSITION=1 option set, the master must send the slave all the transactions that the slave has not already received, committed, or both. If any of the transactions that should be sent by the master have been already purged from the master's binary log, the master sends the error ER_MASTER_HAS_PURGED_REQUIRED_GTIDS (1789) to the slave, and replication does not start.
The message provided for the error ER_MASTER_HAS_PURGED_REQUIRED_GTIDS has been changed to provide advice on the correct action in this situation, which is for the slave to replicate the missing transactions from another source, or for the slave to be replaced by a new slave created from a more recent backup. The message advises that the master's binary log expiration period can be revised to avoid the situation in future. In addition, the master now identifies the GTIDs of the purged transactions and supplies them in its error log in the warning message ER_FOUND_MISSING_GTIDS (11809), so that you do not need to calculate the missing GTIDs manually.
macOS: On macOS, configuring MySQL with -DWITH_SSL=system caused mysql_config output to incorrectly include internal CMake names for the static SSL libraries.
There could be a mismatch between the version of OpenSSL used to build the server and the version used for other parts of MySQL such as libraries or plugins. This could cause certain features not to work, such as the LDAP authentication plugins. Now the same version of OpenSSL is used for building everything.
Docker packages were missing the LDAP authentication plugins.
The original table name for a field in a derived table was not always displayed correctly.
MySQL Installer was unable to uninstall MySQL 5.7 on Windows Server 2012.
With multiple sessions executing concurrent INSERT ... ON DUPLICATE KEY UPDATE statements into a table with an AUTO_INCREMENT column but not specifying the AUTO_INCREMENT value, inserts could fail with a unique index violation.
With lower_case_table_names=2, SHOW TABLES could fail to display tables with uppercase names.
With keyring_encrypted_file_password set on the command line at server startup, the password value could be visible to system utilities.
With a LOCK TABLES statement in effect, a metadata change for the locked table could cause Performance Schema or SHOW queries for session variables to hang in the opening_tables state.
A SELECT using a WHERE condition of the form A AND (B OR C [OR ...]) resulting in an impossible range led to an unplanned exit of the server.
For JSON-format audit logging, the id field now may contain values larger than 65535. Previously, with heaving logging activity, more than 65536 queries per second could be executed, exceeding the 16 bits permitted for id values.
An incomplete connection packet could cause clients not to properly initialize the authentication plugin name.
Client programs that used the libmysqlclient C client library could exit upon receipt of an OK packet containing malformed session-tracking information.
Under certain conditions, enabling the read_only or super_read_only system variable did not block concurrent DDL statements executed by users without the SUPER privilege.
mysqlpump exits rather than dumping databases that contain an invalid view, by design, but it also failed if an invalid view existed but was not in any of the databases to be dumped.
a51c51fa61