Important Change: The implementation of the max_join_size system variable, although documented as a maximum number of rows or disk seeks, did not check the number of rows or disk seeks directly, but instead treated max_join_size as the maximum estimated cost to permit. While cost and row count are correlated, they are not the same, and this could lead to unexpected results when some large queries were allowed to proceed.

In this release, we change how max_join_size is used, so that it now actually limits the maximum number of row accesses in base tables. If the estimate indicates that a greater number of rows must be read from the base tables, an error is raised. This makes the actual behavior better reflect what is documented. (Bug #83885, Bug #25118903)

InnoDB: Undetectable problems after upgrade from 8.0.28, crash and corruption.

Any new row inserted after upgrade will have all columns added with ALGORITHM=INSTANT materialized and have version=0.

In the new implementation, a column added with ALGORITHM=INSTANT will fail if the maximum possible size of a row exceeds the row size limit. So new rows with materialized ALGORITHM=INSTANT columns will always be within row size limit. (Bug #34558510)

InnoDB: No more garbled UTF characters in SHOW ENGINE INNODB STATUS

Thank you Iiwo Panowicz for reporting this bug. (Bug #34486877, Bug #108111)

InnoDB: After a column added with ALGORITHM=INSTANT, an online rebuild DDL no longer crashes.

Thank you Qingda Hu for reporting this bug. (Bug #33788578, Bug #106279)

InnoDB: Several adaptive hash index (AHI) code optimizations and improvements were implemented, addressing various issues including potential race conditions. (Bug #33601434)

Replication: When SOURCE_HEARTBEAT_PERIOD was set to a very small value (such as 1 microsecond) on the server using CHANGE REPLICATION SOURCE TO, and the mysqlbinlog client program was started with --read-from-remote-server and --stop-never=1, it was possible for the binary log dump thread to send an EOF packet to the client before all events had been sent. (Bug #34860923)

Replication: Removed an assert from sql/rpl_group_replication.cc which triggered a false error in testing. (Bug #34619134)

Replication: After MySQL was started with --server-id=0, trying to change the server ID by using SET PERSIST server_id=N (where N is an integer greater than zero) and restarting the server had the following results:

    SELECT @@server_id returned N.

    Any replication SQL statement such as START REPLICA was rejected with ER_SLAVE_CONFIGURATION.

To fix this problem, we now ensure that such checks use the value of the server variable rather than the value passed to the startup option. (Bug #34412816)

Replication: When replicating compressed binary log events generated by the NDB binary log injector, relay log positions were not updated in the multithreaded applier, thus causing replication to hang. (Bug #33889030)

References: See also: Bug #33784241.

Replication: Issuing STOP REPLICA SQL_THREAD while the SQL thread was handling a transaction caused replication to stop immediately, instead of waiting 60 seconds for the event group to complete before shutting down the SQL thread as expected.

The root cause of this issue was due to the internal variable storing the last event start time not being reset after the SQL thread was restarted.

We fix this by resetting the variable holding the last event start time whenever the SQL thread is started. (Bug #33646899)

Replication: While their wording might imply otherwise, the log messages Setting super_read_only=ON (ER_GRP_RPL_SUPER_READ_ON) and Setting super_read_only=OFF (ER_GRP_RPL_SUPER_READ_OFF) were written only after the operations were attempted, and not beforehand, or while the operations were ongoing. This sometimes led to confusion when setting the variable was rejected, and this was logged prior to the set attempt itself being logged. To keep this from happening, these messages are now logged just prior to attempting the operation. (Bug #108843, Bug #34728079)

Replication: The relay_log_space_limit system variable is a 64-bit value, but its valid maximum was specified internally as that of a 32-bit value. (Bug #106323, Bug #33799840)

Replication: Eliminated an unnecessary update of the gtid_executed table which was performed when rotating the binary logs. (Bug #106116, Bug #33759477)

Group Replication: The WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE column of the MySQL Performance Schema's replication_group_communication_information table reflects the runtime value of a Paxos Single Leader setup in a group, letting users know what the value of group_replication_paxos_single_leader must be on joining members.

A group that was bootstrapped with single-leader enabled but with its protocol version downgraded to one that did not support it reported WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE equal to 0, as expected, but attempting to join an instance to the group using group_replication_paxos_single_leader = 0 was not possible.

To solve this problem, we change the behaviour and make the value of group_replication_paxos_single_leader consistent with the communication version that the group is running. Since this variable was introduced in MySQL 8.0.27, it is not known or used in any previous version, and so we now enforce the following rules:

    When a node tries to join a group that is running MySQL 8.0.26 or earlier and we are version 8.0.27 or later, we reject the attempt with an error stating that group_replication_paxos_single_leader must be OFF before joining the group

    When we try to use group_replication_set_communication_protocol() to set a version less than 8.0.27 and we are of version 8.0.27 or later, we reject the function call if group_replication_paxos_single_leader is not OFF.

In addition, we also change the value checked to determine whether changing the group leader is allowed after running group_replication_set_communication_protocol(). Previously, this was the runtime value of group_replication_paxos_single_leader, which takes effect only after a group reboot. Instead, when we run group_replication_set_communication_protocol(), we now use the value shown by the replication_group_communication_information table's WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE column, described previously. (Bug #34555045, Bug #34828311)