MySQL Community Server 8.0.21 has been released (part 1/2)

[Bjørn Munch]

[ Due to size limitations, this post has been split in two. This is part 1. ]

Dear MySQL users,

MySQL Server 8.0.21, a new version of the popular Open Source
Database Management System, has been released. MySQL 8.0.21 is
recommended for use on production systems.

For an overview of what's new in MySQL 8.0, please see

http://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html

For information on installing MySQL 8.0.21 on new servers, please see
the MySQL installation documentation at

http://dev.mysql.com/doc/refman/8.0/en/installing.html

MySQL Server 8.0.21 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 8.0.21 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:

http://dev.mysql.com/downloads/installer/

along with .ZIP (no-install) packages for more advanced needs.

8.0.21 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.

Downgrade from MySQL 8.0 to MySQL 5.7, or from a MySQL 8.0 release to
a previous MySQL 8.0 release, is not supported. The only supported
alternative is to restore a backup taken before upgrading. It is
therefore imperative that you back up your data before starting the
upgrade process.

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 8.0 since
the release of MySQL 8.0.20. It may also be viewed
online at

http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-21.html

Enjoy!

==============================================================================

Changes in MySQL 8.0.21 (2020-07-13)

   In the documentation for MySQL 8.0.21, we have started
   changing the term "master" to "source", the term "slave" to
   "replica", the term "whitelist" to "allowlist", and the term
   "blacklist" to "blocklist". There are currently no changes to
   the product's syntax, so these terms are still present in the
   documentation where the current code requires their use. See
   the blog post MySQL Terminology Updates
   (https://mysqlhighavailability.com/mysql-terminology-updates/)
   for more information.

     * Account Management Notes

     * C API Notes

     * Compilation Notes

     * Configuration Notes

     * Connection Management Notes

     * Deprecation and Removal Notes

     * JSON Notes

     * Optimizer Notes

     * Packaging Notes

     * Pluggable Authentication

     * Security Notes

     * Test Suite Notes

     * X Plugin Notes

     * Functionality Added or Changed

     * Bugs Fixed

Account Management Notes


     * You can now set per-user comments and attributes when
       creating or updating MySQL user accounts. A user comment
       consists of arbitrary text passed as the argument to a
       COMMENT clause used with a CREATE USER or ALTER USER
       statement. A user attribute consists of data in the form
       of a JSON object passed as the argument to an ATTRIBUTE
       clause used with either of these two statements. The
       attribute can contain any valid key-value pairs in JSON
       object notation.
       For example, the first of the following two statements
       creates a user account bill@localhost with the comment
       text This is Bill's user account. The second statement
       adds a user attribute to this account, using the key
       email, with the value [e-mail].
CREATE USER 'bill'@'localhost' COMMENT 'This is Bill\'s user account';

ALTER USER 'mary'@'localhost'
    ATTRIBUTE '{"email":"[e-mail]"}';

       Only one of COMMENT or ATTRIBUTE can be used in the same
       CREATE USER or ALTER USER statement.
       User comments and user attributes are stored together
       internally as a JSON object, with the comment text as the
       value of an element with the key comment. You can
       information retrieve user comments and user attributes
       from the ATTRIBUTE column of the
       INFORMATION_SCHEMA.USER_ATTRIBUTES table; since this data
       is in JSON format, you can work with it using MySQL's
       JSON function and operators (see JSON Functions
       (https://dev.mysql.com/doc/refman/8.0/en/json-functions.html)).
       Changes to an existing user attribute are merged
       with its current value, as you had used
       JSON_MERGE_PATCH(); new key-value pairs are appended to
       the attribute, and new values for existing keys overwrite
       their previous values.
       To remove a given key-value pair from a user attribute,
       use ALTER USER user ATTRIBUTE '{"key":null}'.
       For more information and examples, see CREATE USER
       Statement
       (https://dev.mysql.com/doc/refman/8.0/en/create-user.html),
       ALTER USER Statement
       (https://dev.mysql.com/doc/refman/8.0/en/alter-user.html),
       and The INFORMATION_SCHEMA USER_ATTRIBUTES Table
(https://dev.mysql.com/doc/refman/8.0/en/information-schema-user-attributes-table.html).
       References: See also: Bug #31067575.

C API Notes


     * Per OpenSSL recommendation, x509_check_host() and
       X509_check_ip_asc() calls in the C client library were
       replaced, respectively, with
       X509_VERIFY_PARAM_set1_host() and
       X509_VERIFY_PARAM_set1_ip_asc() calls. (Bug #29684791)

     * The MySQL C API now supports compression for asynchronous
       functions. This means that the
       MYSQL_OPT_COMPRESSION_ALGORITHMS and
       MYSQL_OPT_ZSTD_COMPRESSION_LEVEL options for the
       mysql_options() function now affect asynchronous
       operations, not just synchronous operations. See
       mysql_options()
       (https://dev.mysql.com/doc/refman/8.0/en/mysql-options.html).

Compilation Notes


     * The minimum version of the Boost library for server
       builds is now 1.72.0. (Bug #30963985)

Configuration Notes


     * tcmalloc is no longer a permitted value for the
       mysqld_safe --malloc-lib option. (Bug #31372027)

Connection Management Notes


     * MySQL Server supports a "main" network interface for
       ordinary client connections, and optionally an
       administrative network interface for administrative
       client connections. Previously, the main and
       administrative interfaces used the same TLS
       configuration, such as the certificate and key files for
       encrypted connections. It is now possible to configure
       TLS material separately for the administrative interface:

          + There are new configuration parameters that apply
            specifically to the administrative interface.

          + The ALTER INSTANCE RELOAD TLS statement is extended
            with a FOR CHANNEL clause that enables specifying
            the channel (interface) for which to reload the TLS
            context.

          + The new Performance Schema tls_channel_status table
            exposes TLS context properties for the main and
            administrative interfaces.

          + For backward compatibility, the administrative
            interface uses the same TLS context as the main
            interface unless some nondefault TLS parameter value
            is configured for the administrative interface.
       For more information, see Administrative Interface
       Support for Encrypted Connections
(https://dev.mysql.com/doc/refman/8.0/en/administrative-connection-interface.html#administrative-interface-encrypted-connections),
       ALTER INSTANCE Statement
       (https://dev.mysql.com/doc/refman/8.0/en/alter-instance.html),
       and The tls_channel_status Table
(https://dev.mysql.com/doc/refman/8.0/en/performance-schema-tls-channel-status-table.html).

Deprecation and Removal Notes


     * Partitioning: Columns with index prefixes are not
       supported as part of a table's partitioning key;
       previously such columns were simply omitted by the server
       when referenced in creating, altering, or upgrading a
       table that was partitioned by key, with no indication
       that this omission had taken place, except when the
       proposed partitioning function used only columns with
       prefixes, in which case the statement failed with an
       error message that did not identify the actual source of
       the problem. This behavior is now deprecated, and subject
       to removal in a future release in which using any such
       columns in the proposed partitioning key will cause the
       CREATE TABLE or ALTER TABLE statement in which they occur
       to be rejected.
       When one or more columns using index prefixes are
       specified as part of the partitioning key, a warning is
       now generated for each such column. In addition, when a
       CREATE TABLE or ALTER TABLE statement is rejected because
       all columns specified in the proposed partitioning key
       employ index prefixes, the error message returned now
       makes clear the reason the statement did not succeed.
       This includes cases in which the columns proposed the
       partitioning function are defined implicitly as those in
       the table's primary key by employing an empty PARTITION
       BY KEY() clause.
       For more information and examples, see Column index
       prefixes not supported for key partitioning
(https://dev.mysql.com/doc/refman/8.0/en/partitioning-limitations.html#partitioning-limitations-prefixes),
       and KEY Partitioning
       (https://dev.mysql.com/doc/refman/8.0/en/partitioning-key.html).
       (Bug #29941932, Bug #29941959, Bug #31100205)
       References: See also: Bug #29942014.

JSON Notes


     * Added the JSON_VALUE() function, which simplifies
       creating indexes on JSON columns. A call to
       JSON_VALUE(json_doc, path RETURNING type) is equivalent
       to calling CAST( JSON_UNQUOTE( JSON_EXTRACT(json_doc,
       path) ) AS type), where json_doc is a JSON document, path
       is a JSON path expression pointing to a single value
       within the document, and type is a data type compatible
       with CAST(). RETURNING type is optional; if no return
       type is specified, JSON_VALUE() returns VARCHAR(512).
       JSON_VALUE() also supports ON EMPTY and ON ERROR clauses
       similar to those used with JSON_TABLE().
       You can create indexes on a JSON column using
       JSON_VALUE() as shown here:
CREATE TABLE inventory(
    items JSON,
    INDEX i1 ( (JSON_VALUE(items, '$.name' RETURNING VARCHAR(50))) ),
    INDEX i2 ( (JSON_VALUE(items, '$.price' RETURNING DECIMAL(5,2))) )
,
    INDEX i3 ( (JSON_VALUE(items, '$.quantity' RETURNING UNSIGNED)) )
);

       Assuming the items column contains values such as
       '{"name": "hat", "price": "22.95", "quantity": "17"}',
       you can issue queries, such as the following, that can
       use these indexes:
SELECT items->"$.price" FROM inventory
    WHERE JSON_VALUE(items, '$.name' RETURNING VARCHAR(50)) = "hat";

SELECT * FROM inventory
    WHERE JSON_VALUE(items, '$.price' RETURNING DECIMAL(5,2)) <= 100.0
1;

SELECT items->"$.name" AS item, items->"$.price" AS amount
    FROM inventory
    WHERE JSON_VALUE(items, '$.quantity' RETURNING UNSIGNED) > 500;

       For more information and examples, see the description of
       the JSON_VALUE() function.

Optimizer Notes


     * MySQL attempts to use an ordered index for any ORDER BY
       or GROUP BY query that has a LIMIT clause, overriding any
       other choices made by the optimizer, whenever it
       determines that this would result in faster execution.
       Because the algorithm for making this determination makes
       certain assumptions about data distribution and other
       conditions, it may not always be completely correct, and
       it is possible in some cases that choosing a different
       optimization for such queries can provide better
       performance. To handle such occurrences, it is now
       possible to disable this optimization by setting the
       optimizer_switch system variable's prefer_ordering_index
       flag to off.
       For more information about this flag and examples of its
       use, see Switchable Optimizations
(https://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html),
       and LIMIT Query Optimization
       (https://dev.mysql.com/doc/refman/8.0/en/limit-optimization.html).
       Our thanks to Jeremy Cole for the contribution. (Bug
       #97001, Bug #30348211)

     * A single-table UPDATE or DELETE statement that uses a
       subquery having a [NOT] IN or [NOT] EXISTS predicate can
       now in many cases make use of a semijoin transformation
       or subquery materialization. This can be done when the
       statement does not use LIMIT or ORDER BY, and when
       semijoin or subquery materialization is allowed by any
       optimizer hints used in the subquery, or by the value of
       the optimizer_switch server system variable.
       You can see when the semijoin optimization or subquery
       materialization is used for an eligible single-table
       DELETE or UPDATE due to the presence of a
       join_optimization object in the optimizer trace. You can
       also see that the conversion is performed by checking the
       output of EXPLAIN FORMAT=TREE; if the optimization is not
       performed, this shows <not executable by iterator
       executor>, while a multi-table statement reports a full
       plan.
       As part of this work, semi-consistent reads are now
       supported by multi-table UPDATE of InnoDB tables, when
       the transaction isolation level is weaker than REPEATABLE
       READ. (Bug #35794, Bug #96423, Bug #11748293, Bug
       #30139244)

     * Added the optimizer_switch flag subquery_to_derived. When
       this flag is set to on, the optimizer transforms eligible
       scalar subqueries into left outer joins (and in some
       cases, inner joins) on derived tables. This optimization
       can be applied to a subquery which meets the following
       conditions:

          + It uses one or more aggregate functions but no GROUP
            BY.

          + It is part of a SELECT, WHERE, JOIN, or HAVING
            clause.

          + It is not a correlated subquery.

          + It does not make use of any nondeterminstic
            functions.
       ANY and ALL subqueries which can be rewritten to use
       MIN() or MAX() are also not affected.
       With subquery_to_derived=on, the optimization can also be
       applied to a table subquery which is the argument to IN,
       NOT IN, EXISTS, or NOT EXISTS, and which does not contain
       a GROUP BY clause.
       The subquery_to_derived flag is set to off by default,
       since it generally does not improve performance, and its
       intended use for the most part is for testing purposes.
       For more information, see Switchable Optimizations
(https://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html),
       for more information and examples. See
       also Optimizing Derived Tables, View References, and
       Common Table Expressions with Merging or Materialization
(https://dev.mysql.com/doc/refman/8.0/en/derived-table-optimization.html),
       and LIMIT Query Optimization
       (https://dev.mysql.com/doc/refman/8.0/en/limit-optimization.html).

     * Building on work done in MySQL 8.0.18, the server now
       performs injection of casts into queries to avoid
       mismatches when comparing string data types with those of
       numeric or temporal types; as when comparing numeric and
       temporal types, the optimizer now adds casting operations
       in the item tree inside expressions and conditions in
       which the data type of the argument and the expected data
       type do not match. This makes queries in which string
       types are compared with numeric or temporal types
       equivalent to queries which are compliant with the SQL
       standard, while maintaining backwards compatibility with
       previous releases of MySQL. Such casts are now performed
       whenever string values are compared to numeric or
       temporal values using any of the standard numeric
       comparison operators (=, >=, >, <, <=, <>/!=, and <=>).
       Such implicit casts are now performed between a string
       type (CHAR, VARCHAR, BINARY, VARBINARY, BLOB, TEXT, ENUM,
       or SET) and a numeric type (SMALLINT, TINYINT, MEDIUMINT,
       INT/INTEGER, BIGINT; DECIMAL/NUMERIC; FLOAT, DOUBLE,
       REAL; and BIT) by casting the string value to DOUBLE; if
       the numeric value is not already of type DOUBLE, FLOAT,
       or REAL, it is also cast to DOUBLE. A YEAR value is also
       cast to DOUBLE when compared with a string value (as is
       the string value). For such comparisons between string
       types and TIMESTAMP or DATETIME values, the arguments are
       cast as DATETIME; when a string type is compared with a
       DATE value, the string is cast to DATE.
       For example, a query such as SELECT * FROM t1 JOIN t2 ON
       t1.char_col = t2.int_col is rewritten and executed as
       SELECT * FROM t1 JOIN t2 ON CAST(t1.char_col AS DOUBLE) =
       CAST(t2.int_col AS DOUBLE), and SELECT * FROM t1 JOIN t2
       ON t1.varchar_col = t2.timestamp_col is transformed to
       SELECT * FROM t1 JOIN t2 ON CAST(t1.varchar_col AS
       DATETIME) = CAST(t2.timestamp_col AS DATETIME) prior to
       execution.
       You can see when casts are injected into a given query by
       viewing the output of EXPLAIN ANALYZE, EXPLAIN
       FORMAT=JSON, or EXPLAIN FORMAT=TREE. EXPLAIN
       [FORMAT=TRADITIONAL] can also be used, but in this case
       it is necessary, following execution of the EXPLAIN
       statement, to issue SHOW WARNINGS to view the rewritten
       query.
       This change is not expected to cause any difference in
       query results or performance.

Packaging Notes


     * For RPM and Debian packages, client-side plugins were
       moved from the server package to the client package.
       Additionally, debug versions of client-side plugins were
       moved to the test package. (Bug #31123564, Bug #31336340)

     * MSI packages for Windows no longer include the legacy
       server data component. (Bug #31060177)

     * The libevent library bundled with MySQL was upgraded to
       version 2.1.11. (Bug #30926742)

     * The ICU (International Components for Unicode) library
       bundled with MySQL has been upgraded to version 65.1.

Pluggable Authentication


     * The MySQL Enterprise Edition authentication_ldap_sasl
       plugin that implements SASL LDAP authentication supports
       multiple authentication methods, but depending on host
       system configuration, they might not all be available.
       The new Authentication_ldap_sasl_supported_methods status
       variable provides discoverability for the supported
       methods. Its value is a string consisting of supported
       method names separated by spaces. Example: "SCRAM-SHA1
       GSSAPI"

Security Notes


     * For platforms on which OpenSSL libraries are bundled, the
       linked OpenSSL library for MySQL Server has been updated
       to version 1.1.1g. Issues fixed in the new OpenSSL
       version are described at
       https://www.openssl.org/news/cl111.txt and
       https://www.openssl.org/news/vulnerabilities.html. (Bug
       #31296697)

     * Previously, LOCAL data loading capability for the LOAD
       DATA statement could be controlled on the client side
       only by enabling it for all files accessible to the
       client, or by disabling it altogether. The new
       MYSQL_OPT_LOAD_DATA_LOCAL_DIR option for the
       mysql_options() C API function enables clients to
       restrict LOCAL data loading to files located in a
       designated directory. See Security Considerations for
       LOAD DATA LOCAL
       (https://dev.mysql.com/doc/refman/8.0/en/load-data-local-security.html).

Test Suite Notes


     * mysql-test-run.pl no longer accepts unique prefixes of
       command options. Complete option names must be given.
       (Bug #31390127)

     * MySQL tests were updated to use googletest 1.10.0. (Bug
       #31364750)

     * mysql-test-run.pl now supports an --mtr-port-exclude
       option for specifying the range of ports to exclude when
       searching for available port ranges to use. The
       MTR_PORT_EXCLUDE environment variable may also be set to
       achieve the same effect. Thanks to Facebook for the
       contribution. (Bug #30809607)

     * In addition to aborting on receipt of CTRL+C (SIGINT),
       mysql-test-run.pl now also displays a list of test cases
       that failed up to that point. (Bug #30407014)

X Plugin Notes


     * Where a dollar sign ($) was used to reference an entire
       document, X Plugin handled the reference differently
       depending on the context in which it was used. This has
       now been standardized. (Bug #31374713)

     * With certain settings for the global SQL mode, X Plugin's
       authentication process failed to accept a correct user
       password. The authentication process now operates
       independently from the global SQL mode's setting to
       ensure consistency. (Bug #31086109)

Functionality Added or Changed


     * Important Change: By default, a replication source server
       writes a checksum for each event in the binary log, as
       specified by the system variable binlog_checksum, which
       defaults to the setting CRC32. Previously, Group
       Replication did not support the presence of checksums in
       the binary log, so binlog_checksum had to be set to NONE
       when configuring a server instance that would become a
       group member. This requirement is now removed, and the
       default can be used. The setting for binlog_checksum does
       not have to be the same for all members of a group.
       Note that Group Replication does not use checksums to
       verify incoming events on the group_replication_applier
       channel, because events are written to that relay log
       from multiple sources and before they are actually
       written to the originating server's binary log, which is
       when a checksum is generated. Checksums are used to
       verify the integrity of events on the
       group_replication_recovery channel and on any other
       replication channels on group members.

     * Performance: Improved the implementation of the UNHEX()
       function by introducing a lookup table for mapping a
       hexadecimal digit string to its binary representation.
       This change speeds up execution of the function by a
       factor of 8 or more in testing. (Bug #31173103)

     * InnoDB: Redo logging can now be enabled and disabled
       using ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG
       syntax. This functionality is intended for loading data
       into a new MySQL instance. Disabling redo logging helps
       speed up data loading by avoiding redo log writes.
       The new INNODB_REDO_LOG_ENABLE privilege permits enabling
       and disabling redo logging.
       The new Innodb_redo_log_enabled status variable permits
       monitoring redo logging status.

     * InnoDB: Truncating an undo tablespace on a busy system
       could affect performance due to associated flushing
       operations that remove old undo tablespace pages from the
       buffer pool and flush the initial pages of the new undo
       tablespace to disk. To address this issue, the flushing
       operations were removed.
       Old undo tablespace pages are now released passively as
       they become least recently used, or are removed at the
       next full checkpoint. The initial pages of the new undo
       tablespace are now redo logged instead of being flushed
       to disk during the truncate operation, which also
       improves durability of the undo tablespace truncate
       operation.
       To prevent potential issues caused by an excessive number
       of undo tablespace truncate operations, truncate
       operations on the same undo tablespace between
       checkpoints are now limited to 64. If the limit is
       exceeded, an undo tablespace can still be made inactive,
       but it is not truncated until after the next checkpoint.
       INNODB_METRICS counters associated with defunct undo
       truncate flushing operations were removed. Removed
       counters include: undo_truncate_sweep_count,
       undo_truncate_sweep_usec, undo_truncate_flush_count, and
       undo_truncate_flush_usec.
       See Undo Tablespaces
       (https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html).

     * InnoDB: At startup, InnoDB validates the paths of known
       tablespace files against tablespace file paths stored in
       the data dictionary in case tablespace files have been
       moved to a different location. The new
       innodb_validate_tablespace_paths variable permits
       disabling tablespace path validation. This feature is
       intended for environments where tablespaces files are not
       moved. Disabling tablespace path validation improves
       startup time on systems with a large number of tablespace
       files.

     * InnoDB: Table and partition data files created outside of
       the data directory using the DATA DIRECTORY clause are
       now restricted to directories that are known to InnoDB.
       This change permits database administrators to control
       where tablespace data files are created and ensures that
       the data files can be found during recovery.
       General and file-per-table tablespaces data files (.ibd
       files) can no longer be created in the undo tablespace
       directory (innodb_undo_directory) unless that directly is
       known to InnoDB.
       Known directories are those defined by the datadir,
       innodb_data_home_dir, and innodb_directories variables.

     * InnoDB: To improve concurrency for operations that
       require access to lock queues for table and row
       resources, the lock system mutex (lock_sys->mutex) was
       replaced by sharded latches, and lock queues were grouped
       into table and page lock queue shards, with each shard
       protected by a dedicated mutex. Previously, the single
       lock system mutex protected all lock queues, which was a
       point of contention on high-concurrency systems. The new
       sharded implementation permits more granular access to
       lock queues.
       The lock system mutex (lock_sys->mutex) was replaced by
       the following sharded latches:

          + A global latch (lock_sys->latches.global_latch)
            consisting of 64 read-write lock objects
            (rw_lock_t). Access to an individual lock queue
            requires a shared global latch and a latch on the
            lock queue shard. Operations that require access to
            all lock queues take an exclusive global latch,
            which latches all table and page lock queue shards.

          + Table shard latches
            (lock_sys->latches.table_shards.mutexes),
            implemented as an array of 512 mutexes, with each
            mutex dedicated to one of 512 table lock queue
            shards.

          + Page shard latches
            (lock_sys->latches.page_shards.mutexes), implemented
            as an array of 512 mutexes, with each mutex
            dedicated to one of 512 page lock queue shards.
       The Performance Schema wait/synch/mutex/innodb/lock_mutex
       instrument for monitoring the single lock system mutex
       was replaced by instruments for monitoring the new
       global, table shard, and page shard latches:

          + wait/synch/sxlock/innodb/lock_sys_global_rw_lock

          + wait/synch/mutex/innodb/lock_sys_table_mutex

          + wait/synch/mutex/innodb/lock_sys_page_mutex

     * Previously, the --disabled-storage-engines option did not
       ignore spaces around storage engines listed in the option
       value. Spaces around engine names are now ignored. (Bug
       #31373361, Bug #99632)

     * The new HANDLE_FATAL_SIGNALS CMake option enables
       configuring whether Address Sanitizer and Undefined
       Behavior Sanitizer builds use the sanitizer runtime
       library to handle fatal signals rather than a
       MySQL-internal function. The option default is ON for
       non-sanitizer builds, OFF for sanitizer builds. If the
       option is OFF, the default action is used for SIGBUS,
       SIGILL and SIGSEGV, rather than the internal function.
       (Bug #31068443)

     * Using a column that is repeated twice or more in GROUP BY
       (through an alias), combined with ROLLUP, had behavior
       differing from MySQL 5.7. Example:
SELECT a, b AS a, COUNT(*) FROM t1 GROUP BY a, b WITH ROLLUP;

       Behavior of such queries has been changed to better match
       MySQL 5.7. They should be avoided, however, because
       behavior may change again in the future or such queries
       may become illegal. (Bug #30921780, Bug #98663)

     * EXPLAIN ANALYZE now supports the FORMAT option.
       Currently, TREE is the only supported format. (Bug
       #30315224)

     * ALTER INSTANCE ROTATE INNODB MASTER KEY is no longer
       permitted when read_only or super_read_only are enabled.
       (Bug #30274240)

     * LOAD XML now supports CDATA sections in the XML file to
       be imported. (Bug #98199, Bug #30753708)

     * X Plugin's mysqlx_bind_address system variable now
       accepts multiple IP addresses like MySQL Server's
       bind_address system variable does, enabling X Plugin to
       listen for TCP/IP connections on multiple network
       sockets.
       An important difference in behavior is that for MySQL
       Server, any error in the list of addresses prevents the
       server from starting, but X Plugin (which is not a
       mandatory plugin) does not do this. With X Plugin, if one
       of the listed addresses cannot be parsed or if X Plugin
       cannot bind to it, the address is skipped, an error
       message is logged, and X Plugin attempts to bind to each
       of the remaining addresses. X Plugin's Mysqlx_address
       status variable displays only those addresses from the
       list for which the bind succeeded. If none of the listed
       addresses results in a successful bind, X Plugin logs an
       error message stating that X Protocol cannot be used.

     * On storage engines that support atomic DDL, the CREATE
       TABLE ... SELECT statement is now executed as an atomic
       operation by the replica applier thread in row-based
       replication. Previously, in row-based replication, the
       CREATE TABLE ... SELECT statement was written to the
       binary log as two transactions.

     * ENGINE_ATTRIBUTE and SECONDARY_ENGINE_ATTRIBUTE options
       were added to CREATE TABLE, ALTER TABLE, and CREATE INDEX
       syntax. The ENGINE_ATTRIBUTE option was also added to
       CREATE TABLESPACE and ALTER TABLESPACE syntax. The new
       options, which permit defining storage engine attributes
       for tables, columns, indexes, and tablespaces, are
       reserved for future use.
       The following INFORMATION_SCHEMA tables were added for
       querying storage engine attributes for tables, columns,
       indexes, and tablespaces. Values are stored in the data
       dictionary. The tables are reserved for future use.

          + INFORMATION_SCHEMA.TABLES_EXTENSIONS

          + INFORMATION_SCHEMA.COLUMNS_EXTENSIONS

          + INFORMATION_SCHEMA.TABLE_CONSTRAINTS_EXTENSIONS

          + INFORMATION_SCHEMA.TABLESPACES_EXTENSIONS

     * Group Replication group members can now advertise a list
       of IP addresses that joining members can use to make
       connections to them for state transfer during distributed
       recovery. Previously, the existing member's standard SQL
       client connection was used for this purpose as well as
       for client traffic. Advertising distributed recovery
       endpoints instead gives you improved control of
       distributed recovery traffic (comprising remote cloning
       operations and state transfer from the binary log) in
       your network infrastructure. The list of distributed
       recovery endpoints for a member is specified using the
       new group_replication_advertise_recovery_endpoints system
       variable, and the same SSL requirements are applied that
       would be in place if the SQL client connection was used
       for distributed recovery.

     * The default logging level for MySQL Server omits
       informational log messages, which previously included
       some significant lifecycle events for Group Replication
       that were non-error situations, such as a group
       membership change. Messages about significant events for
       a replication group have now been reclassified as system
       messages, so they always appear in the server's error log
       regardless of the server logging level. Operators can
       therefore review a complete history of the server's
       membership in a replication group. Also, socket bind
       errors on the group communication layer have been
       reclassified from information to error messages.

     * You can now specify user credentials for distributed
       recovery on the START GROUP_REPLICATION statement using
       the USER, PASSWORD, and DEFAULT_AUTH options. These
       credentials are used for distributed recovery on the
       group_replication_recovery channel. When you specify user
       credentials on START GROUP_REPLICATION, the credentials
       are saved in memory only, and are removed by a STOP
       GROUP_REPLICATION statement or server shutdown. These
       credentials can replace user credentials set using a
       CHANGE MASTER TO statement, which are stored in the
       replication metadata repositories, and can therefore help
       to secure the Group Replication servers against
       unauthorized access.
       The new method of providing user credentials is not
       compatible with starting Group Replication automatically
       on server start. If user credentials have previously been
       set using a CHANGE MASTER TO statement, credentials that
       you specify on START GROUP_REPLICATION take precedence
       over these. However, the credentials from the replication
       metadata repositories are used if START GROUP_REPLICATION
       is specified without user credentials, which happens on
       automatic starts if the group_replication_start_on_boot
       system variable is set to ON (including after a remote
       cloning operation for distributed recovery). To gain the
       security benefits of specifying user credentials on START
       GROUP_REPLICATION, ensure that
       group_replication_start_on_boot is set to OFF (the
       default is ON), and use a CHANGE MASTER TO statement to
       clear any user credentials previously set for the
       group_replication_recovery channel.

     * The minimum setting for the maximum size for the XCom
       message cache in Group Replication, specified by the
       group_replication_message_cache_size system variable, has
       been reduced from approximately 1 GB to 134217728 bytes,
       or approximately 128 MB. Note that this size limit
       applies only to the data stored in the cache, and the
       cache structures require an additional 50 MB of memory.
       The same cache size limit should be set on all group
       members. The default XCom message cache size of 1 GB,
       which was formerly also the minimum setting, is
       unchanged.
       The smaller message cache size is provided to enable
       deployment on a host that has a restricted amount of
       available memory and good network connectivity. Having a
       very low group_replication_message_cache_size setting is
       not recommended if the host is on an unstable network,
       because a smaller message cache makes it harder for group
       members to reconnect after a transient loss of
       connectivity. If some messages that were exchanged during
       a member's temporary absence have been deleted from the
       other members' XCom message caches because their maximum
       size limit was reached, the member cannot reconnect using
       the message cache. It must leave the group and rejoin in
       order to retrieve the transactions through distributed
       recovery, which is a slower process than using the
       message cache, although the member still can rejoin in
       this way without operator intervention.
       Note that from MySQL 8.0.21, by default an expel timeout
       of 5 seconds is added before a member is expelled from
       the group (specified by the
       group_replication_member_expel_timeout system variable).
       With this default setting the XCom message cache
       therefore now needs to store the messages exchanged by
       the group in a 10-second period (the expel timeout plus
       the initial 5-second detection period), rather than in a
       5-second period as previously (the initial 5-second
       detection period only).

     * group_replication_member_expel_timeout specifies the
       period of time in seconds that a Group Replication group
       member waits after creating a suspicion, before expelling
       from the group the member suspected of having failed. The
       initial 5-second detection period before a suspicion is
       created does not count as part of this time.
       Previously, the waiting period specified by
       group_replication_member_expel_timeout defaulted to 0,
       meaning that a suspected member was liable for expulsion
       immediately after the 5-second detection period ended.
       Following user feedback, the waiting period now defaults
       to 5 seconds, giving a member that loses touch with the
       group 10 seconds in total to reconnect itself to the
       group. If the member does reconnect in this time, it can
       recover missed messages from the XCom message cache and
       return to ONLINE state automatically, rather than being
       expelled from the group and needing the auto-rejoin
       procedure or manual operator intervention to rejoin.
       If you previously tuned the size of the XCom message
       cache with reference to the expected volume of messages
       in the previous default time before a member was expelled
       (the 5-second detection period only), increase your
       group_replication_message_cache_size setting to account
       for the new expel timeout, which doubles the default time
       to 10 seconds. With the new default expel timeout you
       might start to see warning messages from GCS on active
       group members, stating that a message that is likely to
       be needed for recovery by a member that is currently
       unreachable has been removed from the message cache. This
       message shows that a member has had a need to use the
       message cache to reconnect, and that the cache size might
       not be sufficient to support the current waiting period
       before a member is expelled.

     * Group Replication's auto-rejoin feature is now activated
       by default. The group_replication_autorejoin_tries system
       variable, which is available from MySQL 8.0.16, makes a
       member that has been expelled or reached its unreachable
       majority timeout try to rejoin the group automatically.
       This system variable, which originally defaulted to 0 so
       auto-rejoin was not activated, now defaults to 3, meaning
       that a member makes three attempts to rejoin the group in
       the event of its expulsion or unreachable majority
       timeout. Between each attempt the member waits for 5
       minutes. If the specified number of tries is exhausted
       without the member rejoining or being stopped, the member
       proceeds to the action specified by the
       group_replication_exit_state_action system variable.
       The auto-rejoin feature minimizes the need for manual
       intervention to bring a member back into the group,
       especially where transient network issues are fairly
       common. During and between auto-rejoin attempts, a member
       remains in super read only mode and does not accept
       writes. However, reads can still be made on the member,
       with an increasing likelihood of stale reads over time.
       If you want to intervene to take the member offline, the
       member can be stopped manually at any time by using a
       STOP GROUP_REPLICATION statement or shutting down the
       server. If you cannot tolerate the possibility of stale
       reads for any period of time, set the
       group_replication_autorejoin_tries system variable to 0,
       in which case operator intervention is required whenever
       a member is expelled from the group or reaches its
       unreachable majority timeout.

     * MySQL Server Docker containers now support server restart
       within a client session (which happens, for example, when
       the RESTART
       (https://dev.mysql.com/doc/refman/8.0/en/restart.html)
       statement is executed by a client or during the
       configuration of an InnoDB cluster instance
(https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-working-with-cluster.html#configuring-local-instances)).
       To enable this important feature, containers should
       be started with the docker run option --restart set to
       the value on-failure. See Starting a MySQL Server
       Instance
(https://dev.mysql.com/doc/refman/8.0/en/docker-mysql-getting-started.html#docker-starting-mysql-server)
       for details. (Bug #30750730)