MySQL Community Server 8.0.22 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.22, a new version of the popular Open Source
Database Management System, has been released. MySQL 8.0.22 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.22 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.22 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.22 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.22 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.21. It may also be viewed
online at

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

Enjoy!

Changes in MySQL 8.0.22 (2020-10-19, General Availability)

   For general information about upgrades, downgrades, platform
   support, etc., please visit
   https://dev.mysql.com/doc/relnotes/mysql/8.0/en/.

     * Account Management Notes

     * Audit Log Notes

     * C API Notes

     * Compilation Notes

     * Configuration Notes

     * Deprecation and Removal Notes

     * Keyring Notes

     * Optimizer Notes

     * Packaging Notes

     * Performance Schema Notes

     * Pluggable Authentication

     * SQL Syntax Notes

     * X Plugin Notes

     * Functionality Added or Changed

     * Bugs Fixed

Account Management Notes


     * Lock handling for statements involving the grant tables
       was improved. (Bug #31291237, Bug #31576185)

     * Modifying the mysql.infoschema and mysql.sys reserved
       accounts now requires the SYSTEM_USER privilege. (Bug
       #31255458)

     * For the CREATE USER, DROP USER, and RENAME USER
       account-management statements, the server now performs
       additional security checks designed to prevent operations
       that (perhaps inadvertently) cause stored objects to
       become orphaned or that cause adoption of stored objects
       that are currently orphaned. Such operations now fail
       with an error. If you have the SET_USER_ID privilege, it
       overrides the checks and those operations produce a
       warning rather than an error; this enables administrators
       to perform the operations when they are deliberately
       intended. See Orphan Stored Objects
(https://dev.mysql.com/doc/refman/8.0/en/stored-objects-security.html#stored-objects-security-orphan-objects).

Audit Log Notes


     * For JSON-format log files, MySQL Enterprise Audit
       supports log-reading operations using the
       audit_log_read() user-defined function. Previously,
       specifying the position at which to begin reading was
       possible only by passing to audit_log_read() an argument
       containing a bookmark indicating the exact timestamp and
       event ID of a particular event. For greater flexibility,
       the argument now can be a start specifier that names any
       timestamp, to read starting from the first event that
       occurs on or after that timestamp. See Reading Audit Log
       Files
       (https://dev.mysql.com/doc/refman/8.0/en/audit-log-file-reading.html).

C API Notes


     * The MySQL client library now includes a
       mysql_real_connect_dns_srv() C API function that is
       similar to mysql_real_connect() but uses a DNS SRV record
       to determine the candidate hosts for establishing a
       connection to a MySQL server, rather than explicit host,
       port, and socket arguments.
       Applications that use the C API can call the new function
       directly. In addition, the mysql client program is
       modified to use DNS SRV capability; it now supports a
       --dns-srv-name option that takes precedence over --host
       and causes the connection to be based on a DNS SRV
       record. See mysql_real_connect_dns_srv()
(https://dev.mysql.com/doc/c-api/8.0/en/mysql-real-connect-dns-srv.html).
       Connection establishment in other contexts is unaffected,
       including connections made by replicas, the FEDERATED
       storage engine, and client programs other than mysql.

Compilation Notes


     * Visual Studio 16.4 is now the minimum version for MySQL
       compilation. (Bug #31655401)

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

Configuration Notes


     * The new WITH_TCMALLOC CMake option indicates whether to
       link with -ltcmalloc. If enabled, built-in malloc(),
       calloc(), realloc(), and free() routines are disabled.
       The default is OFF. WITH_TCMALLOC and WITH_JEMALLOC are
       mutually exclusive. (Bug #31785166)

     * The new COMPRESS_DEBUG_SECTIONS CMake option indicates
       whether to compress the debug sections of binary
       executables (Linux only). Compressing executable debug
       sections saves space at the cost of extra CPU time during
       the build process. The default is OFF. If this option is
       not set explicitly but the COMPRESS_DEBUG_SECTIONS
       environment variable is set, the option takes its value
       from that variable. (Bug #31498296)

     * The WITH_DEFAULT_FEATURE_SET CMake option was removed.
       (Bug #31122507)

     * On platforms that implement network namespace support
       (such as Linux), MySQL now enables configuring the
       network namespace for TCP/IP connections from client
       programs to the MySQL server or X Plugin:

          + On the server side, the bind_address, admin_address,
            and mysqlx_bind_address system variables have
            extended syntax for specifying the network namespace
            to use for a given IP address or host name on which
            to listen for incoming connections.

          + For client connections, the mysql client and the
            mysqlxtest test suite client support a
            --network-namespace option for specifying the
            network namespace.

          + For replication connections from replica servers to
            source servers, the CHANGE MASTER TO statement
            supports a NETWORK_NAMESPACE option for specifying
            the network namespace.
       For replication monitoring purposes, the Performance
       Schema replication_connection_configuration table, the
       replica server connection metadata repository (see
       Replication Metadata Repositories
       (https://dev.mysql.com/doc/refman/8.0/en/replica-logs-status.html)),
       and the SHOW REPLICA | SLAVE STATUS statement
       have a new column that displays the applicable network
       namespace for connections.
       For more information, including the host system
       prerequisites that must be satisfied to use this feature,
       see Network Namespace Support
(https://dev.mysql.com/doc/refman/8.0/en/network-namespace-support.html).

Deprecation and Removal Notes


     * The InnoDB memcached plugin is deprecated and support for
       it will be removed in a future MySQL version.

     * The INFORMATION_SCHEMA.TABLESPACES table is unused. It is
       now deprecated and will be removed in a future MySQL
       version. Other INFORMATION_SCHEMA tables may provide
       related information, as described in The
       INFORMATION_SCHEMA TABLESPACES Table
(https://dev.mysql.com/doc/refman/8.0/en/information-schema-tablespaces-table.html).

Keyring Notes


     * MySQL Enterprise Edition now includes a keyring_oci
       plugin that uses Oracle Cloud Infrastructure Vault as a
       back end for keyring storage. No key information is
       permanently stored in MySQL server local storage. All
       keys are stored in Oracle Cloud Infrastructure Vault,
       making this plugin well suited for Oracle Cloud
       Infrastructure MySQL instances. For more information, see
       The MySQL Keyring
       (https://dev.mysql.com/doc/refman/8.0/en/keyring.html).

Optimizer Notes


     * Important Change: A prepared statement is now prepared
       only once, when executing PREPARE, rather than once each
       time it is executed. In addition, a statement inside a
       stored procedure is also now prepared only once, when the
       stored procedure is first executed. This change enhances
       performance of such statements, since it avoids the added
       cost of repeated preparation and rollback of preparation
       structures, the latter being the source of several bugs.
       As part of this work, the manner in which dynamic
       parameters used in prepared statements are resolved is
       changed, with the resulting changes in prepared statement
       use cases listed here:

          + For a prepared statement of the form SELECT expr1,
            expr2, ... FROM table ORDER BY ?, passing an integer
            value N for the parameter no longer causes ordering
            of the results by the N^th expression in the select
            list; the results are no longer ordered, as is
            expected with ORDER BY constant.

          + The window functions NTILE(NULL), NTH_VALUE(expr,
            NULL), LEAD(expr, nn), and LAG(expr, nn), where nn
            is a negative number, are now disallowed within
            prepared statements, to comply with the SQL
            standard.

          + A user variable that is read by a prepared statement
            now has its type determined when the statement is
            prepared; the type persists for each subsequent
            execution of the statement.

          + A user variable that is read by a statement within a
            stored procedure now has its type determined the
            first time the statement is executed; the type
            persists for all subsequent invocations of the
            containing stored procedure.

          + For parameters for which no contextual information
            is available to determine the parameter type, the
            server assumes the parameter is a character string
            with the default character set, not a binary string.
            Parameters for which this is incorrect may be placed
            within a CAST() expression.
       See PREPARE Statement
       (https://dev.mysql.com/doc/refman/8.0/en/prepare.html),
       for the rules governing how the effectiue data types of
       parameters and user variables used within prepared
       statements are determined.
       In addition, the rows (N) argument to the window
       functions LAG(), LEAD(), and NTILE() must now be an
       integer in the range 1 to 2^63, inclusive, in any of the
       following forms:

          + an unsigned integer constant literal

          + a positional parameter marker (?)

          + a user-defined variable

          + a local variable in a stored routine
       In addition, this argument no longer accepts NULL as a
       value. See the descriptions of the functions just
       referenced for more information. (Bug #48612, Bug #99601,
       Bug #100150, Bug #11756670, Bug #23599127, Bug #31119132,
       Bug #31365678, Bug #31393719, Bug #31592822, Bug
       #31810577)

     * The filesort algorithm now supports sorting a join on
       multiple tables, and not just a single table. (Bug
       #31310238, Bug #31559978, Bug #31563876)

     * When using a RIGHT JOIN, some internal objects, were not
       converted to those suitable for use with a LEFT JOIN as
       intended. These included some lists of tables built at
       parse time, but which did not have their order reversed.
       This required maintaining code to handle instances in
       which a LEFT JOIN was originally a RIGHT JOIN as special
       cases, and was the source of several bugs. Now the server
       performs any necessary reversals at parse time, so that
       after parsing, a RIGHT JOIN is in fact, in all respects,
       a LEFT JOIN. (Bug #30887665, Bug #30964002)
       References: See also: Bug #12567331, Bug #21350125.

     * Added support for periodic synchronization when writing
       to files with SELECT INTO DUMPFILE and SELECT INTO
       OUTFILE statements. This feature can be enabled by
       setting the select_into_disk_sync system variable to ON;
       the size of the write buffer cn be set using the server
       system variable select_into_buffer_size; the default
       buffer size is 131072 (2^17) bytes. An optional delay
       following synchronization to disk can also be set using
       the select_into_disk_sync_delay system variable; the
       default behaviour is not to allow any delay (that is, a
       delay time of 0 milliseconds).
       For more information, see the descriptions of the system
       variables referenced previously.
       Our thanks to Facebook for this contribution to MySQL
       8.0. (Bug #30284861)

     * MySQL now implements derived condition pushdown for
       eligible queries. What this means is that, for a query
       such as SELECT * FROM (SELECT i, j FROM t1) AS dt WHERE i
       > constant, it is now possible in many cases to push the
       outer WHERE condition down to the derived table, in this
       case resulting in SELECT * FROM (SELECT i, j FROM t1
       WHERE i > constant) AS dt. Previously, if the derived
       table was materialized and not merged, MySQL materialized
       the entire table---in this case t1---then qualified the
       rows with the WHERE condition.
       When the derived table cannot be merged into the outer
       query (for example, if the derived table uses
       aggregation), pushing the outer WHERE condition down to
       the derived table can reduce the number of rows that need
       to be processed, which should improve the query's
       performance.
       An outer WHERE condition can be pushed down directly to a
       materialized derived table when the derived table uses no
       aggregate or window functions. In addition, when the
       derived table has a GROUP BY and uses no window
       functions, the outer WHERE condition can be pushed down
       to the derived table as a HAVING condition. If the
       derived table uses a window function and the outer WHERE
       references columns used in the window function's
       PARTITION clause, the WHERE condition can also be pushed
       down.
       This optimization cannot be employed for a derived table
       that contains a UNION or LIMIT clause.
       To enable derived condition pushdown, the
       optimizer_switch system variable's
       derived_condition_pushdown flag (added in this release)
       must be set to on. This is the default setting. If this
       optimization is disabled by the optimizer switch setting,
       you can enable it for a specific query using the
       DERIVED_CONDITION_PUSHDOWN optimizer hint (also added in
       this release). Use the NO_DERIVED_CONDITION_PUSHDOWN
       optimizer hint to disable the optimization for a given
       query.
       For further information and examples, see Derived
       Condition Pushdown Optimization
(https://dev.mysql.com/doc/refman/8.0/en/derived-condition-pushdown-optimization.html).
       (Bug #59870, Bug #88381, Bug #11766303, Bug #27590273)

Packaging Notes


     * For RPM and Debian packages, client-side plugins were
       moved to their own client-plugins package. (Bug
       #31584093)

     * The VERSION file in MySQL source distributions is now
       named MYSQL_VERSION due to a naming conflict with Boost.
       (Bug #31466846)

     * For platforms on which systemd is used to run MySQL,
       packages no longer include legacy System V files: the
       mysqld_multi.server and mysql.server scripts, and the
       mysql.server.1, mysqld_multi.1, and mysqld_safe.1 man
       pages. (Bug #31450888)

Performance Schema Notes


     * The SHOW PROCESSLIST statement provides process
       information by collecting thread data from all active
       threads. However, because the implementation iterates
       across active threads from within the thread manager
       while holding a global mutex, it has negative performance
       consequences, particularly on busy systems.
       An alternative SHOW PROCESSLIST implementation is now
       available based on the new Performance Schema processlist
       table. This implementation queries active thread data
       from the Performance Schema rather than the thread
       manager and does not require a mutex:

          + To enable the alternative implementation, enable the
            performance_schema_show_processlist system variable.

          + The alternative implementation of SHOW PROCESSLIST
            also applies to the mysqladmin processlist command.

          + The alternative implementation does not apply to the
            INFORMATION_SCHEMA PROCESSLIST table or the
            COM_PROCESS_INFO command of the MySQL client/server
            protocol.

          + To ensure that the default and alternative
            implementations yield the same information, certain
            configuration requirements must be met; see The
            processlist Table
(https://dev.mysql.com/doc/refman/8.0/en/performance-schema-processlist-table.html).

     * An SQL interface to the most recent events written to the
       MySQL server error log is now available by means of
       queries on the new Performance Schema error_log table.
       This table has a fixed size, with old events
       automatically discarded as necessary to make room for new
       ones. The table is populated if error log configuration
       includes a log sink component that supports this
       capability (currently the traditional-format
       log_sink_internal and JSON-format log_sink_json sinks).
       Several new status variables provide information about
       error_log table operation. See The error_log Table
(https://dev.mysql.com/doc/refman/8.0/en/performance-schema-error-log-table.html).

Pluggable Authentication


     * These changes were made for the LDAP authentication
       plugins:

          + For the SASL LDAP authentication plugin, the
            SCRAM-SHA-1 authentication method is not supported
            on On SLES 12 and 15 and EL6 systems. The default
            method on those systems is now GSSAPI.

          + If the LDAP host is not set, the LDAP connection
            pool will not be initialized, which enables
            successful authentication plugin installation in
            cases when previously it would fail. (This might be
            the case when a site installs a plugin first, then
            configures it later.)

          + If an LDAP connection parameter is changed at
            runtime, the LDAP connection pool is reinitialized
            for the first subsequent authentication attempt.

          + If the LDAP server is restarted, existing
            connections in the connection pool become invalid.
            The LDAP authentication plugin detects this case and
            reinitializes the connection pool and (for the SASL
            LDAP plugin) the SASL challenge is resent.
       (Bug #31664270, Bug #31219323)

SQL Syntax Notes


     * The parser now supports parenthesized query expressions
       using this syntax:
( query_expression )
  [order_by_clause]
  [limit_clause]
  [into_clause]

       Other variations are possible; see Parenthesized Query
       Expressions
(https://dev.mysql.com/doc/refman/8.0/en/parenthesized-query-expressions.html)
       (Bug #30592703)

     * It is now possible to cast values of other types to YEAR,
       using either the CAST() function or the CONVERT()
       function. These functions now support YEAR values of one
       or two digits in the range 0-99, and four-digit values in
       the range 1901-2155. Integer 0 is converted to Year 0; a
       string consisting of one or more zeroes (following
       possible truncation) is converted to the year 2000.
       Casting adds 2000 to values in the range 1-69 inclusive,
       and 1900 to values in the range 70-99 inclusive.
       Strings beginning with one, two, or four digits followed
       by at least one non-digit character (and possibly other
       digit or non-digit characters) are truncated prior to
       conversion to YEAR; in such cases, the server emits a
       truncation warning. Floating-point values are rounded
       prior to conversion; CAST(1944.5 AS YEAR) returns 1945
       due to rounding, and CAST("1944.5" AS YEAR) returns 1944
       (with a warning) due to truncation.
       DATE, DATETIME, and TIMESTAMP are cast to the YEAR
       portion of the value. A TIME value is cast to the current
       year. Not specifying the value to be cast as a TIME value
       may yield a different result from what is expected;
       CAST("13:47" AS YEAR) returns 2013 due to truncation of
       the string value, and CAST("13:47" AS YEAR) returns 2020
       as of the year of this release.
       Casting of GEOMETRY values to YEAR is not supported. A
       cast of an incompatible type or an out-of-range or
       illegal value returns NULL.
       YEAR can also be used as the return type for the
       JSON_VALUE() function. This function supports four-digit
       years only, and otherwise follows the same rules as apply
       to CAST() and CONVERT() when performing casts to YEAR.
       For more information, see the description of the
       CONVERT() function.

     * When selecting a TIMESTAMP column value, it is now
       possible to convert it from the system time zone to a UTC
       DATETIME when retrieving it, using the AT TIME ZONE
       operator which is implemented for the CAST() function in
       this release.
       The syntax is CAST(value AT TIME ZONE specifier AS
       DATETIME[(precision)]), where the value is a TIMESTAMP,
       and the specifier is one of [INTERVAL] '+00:00' or 'UTC'.
       (INTERVAL is optional with the first form of the
       specifier, and cannot be used with 'UTC'.) The precision
       of the DATETIME value returned by the cast can optionally
       be specified up to 6 decimal places.
       Values that were inserted into the table using a timezone
       offset are also supported.
       AT TIME ZONE cannot be used with CONVERT(), or in any
       other context other than as part of a CAST() function
       call. The ARRAY keyword and creation of multi-valued
       indexes are also not supported when using AT TIME ZONE.
       A brief example is shown here:
mysql> SELECT @@system_time_zone;
+--------------------+
| @@system_time_zone |
+--------------------+
| EDT                |
+--------------------+
1 row in set (0.00 sec)

mysql> CREATE TABLE ex (ts TIMESTAMP);
Query OK, 0 rows affected (0.81 sec)

mysql> INSERT INTO ex VALUES
     >     ROW(CURRENT_TIMESTAMP),
     >     ROW('2020-07-31 21:44:30-08:00');
Query OK, 2 rows affected (0.09 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> TABLE ex;
+---------------------+
| ts                  |
+---------------------+
| 2020-07-28 21:39:31 |
| 2020-08-01 01:44:30 |
+---------------------+
2 rows in set (0.00 sec)

mysql> SELECT ts, CAST(ts AT TIME ZONE 'UTC' AS DATETIME) AS ut FROM e
x;
+---------------------+---------------------+
| ts                  | ut                  |
+---------------------+---------------------+
| 2020-07-28 21:39:31 | 2020-07-29 01:39:31 |
| 2020-08-01 01:44:30 | 2020-08-01 05:44:30 |
+---------------------+---------------------+
2 rows in set (0.00 sec)

       For more information and examples, see the description of
       the CAST() function in the MySQL Manual.

X Plugin Notes


     * In specific conditions, terminating an X Protocol
       connection could cause MySQL Server to stop unexpectedly.
       (Bug #31671503)

Functionality Added or Changed


     * Added the hypergraph_optimizer optimizer switch. This
       switch is off by default, and can be enabled in debug
       builds only.
       hypergraph_optimizer is experimental, and intended to be
       used only for MySQL internal testing; attempting to
       enable it in a standard MySQL release is rejected with an
       error. (Bug #31420895)

     * LOCK TABLES privilege checking for views was improved.
       (Bug #31304432)

     * You can use MySQL Server's new asynchronous connection
       failover mechanism to automatically establish an
       asynchronous (source to replica) replication connection
       to a new source after the existing connection from a
       replica to its source fails. The connection fails over if
       the replication I/O thread stops due to the source
       stopping or due to a network failure. The asynchronous
       connection failover mechanism can be used to keep a
       replica synchronized with multiple MySQL servers or
       groups of servers that share data, including asynchronous
       replication from servers where Group Replication is in
       use. To activate asynchronous connection failover for a
       replication channel set SOURCE_CONNECTION_AUTO_FAILOVER=1
       on the CHANGE MASTER TO statement for the channel, and
       set up a source list for the channel using the
       asynchronous_connection_failover_add_source and
       asynchronous_connection_failover_delete_source UDFs.

     * The new innodb_extend_and_initialize variable permits
       configuring how InnoDB allocates space to file-per-table
       and general tablespaces on Linux. By default, when an
       operation requires additional space in a tablespace,
       InnoDB allocates pages to the tablespace and physically
       writes NULLs to those pages. This behavior affects
       performance if new pages are allocated frequently. As of
       MySQL 8.0.22, you can disable
       innodb_extend_and_initialize on Linux systems to avoid
       physically writing NULLs to newly allocated tablespace
       pages. When innodb_extend_and_initialize is disabled,
       space is allocated using posix_fallocate() calls, which
       reserve space without physically writing NULLs.
       A posix_fallocate() operation is not atomic, which makes
       it possible for a failure to occur between allocating
       space to a tablespace file and updating the file
       metadata. Such a failure can leave newly allocated pages
       in an uninitialized state, resulting in a failure when
       InnoDB attempts to access those pages. To prevent this
       scenario, InnoDB writes a redo log record before
       allocating a new tablespace page. If a page allocation
       operation is interrupted, the operation is replayed from
       the redo log record during recovery.

     * To permit concurrent DML and DDL operations on MySQL
       grant tables, read operations that previously acquired
       row locks on MySQL grant tables are now executed as
       non-locking reads. The operations that are now performed
       as non-locking reads on MySQL grant tables include:

          + SELECT statements and other read-only statements
            that read data from grant tables through join lists
            and subqueries, including SELECT ... FOR SHARE
            statements, using any transaction isolation level.

          + DML operations that read data from grant tables
            (through join lists or subqueries) but do not modify
            them, using any transaction isolation level.
       Statements that no longer acquire row locks when reading
       data from grant tables report a warning if executed while
       using statement-based replication.
       When using -binlog_format=mixed, DML operations that read
       data from grant tables are now written to the binary log
       as row events to make the operations safe for mixed-mode
       replication.
       SELECT ... FOR SHARE statements that read data from grant
       tables now report a warning. With the FOR SHARE clause,
       read locks are not supported on grant tables.
       DML operations that read data from grant tables and are
       executed using the SERIALIZABLE isolation level now
       report a warning. Read locks that would normally be
       acquired when using the SERIALIZABLE isolation level are
       not supported on grant tables.

     * From MySQL 8.0.22, the group_replication_ip_whitelist
       system variable is deprecated, and the system variable
       group_replication_ip_allowlist has been added to replace
       it. The system variable works in the same way as before,
       only the terminology has changed.
       For both system variables, the default value is
       AUTOMATIC. If either one of the system variables has been
       set to a user-defined value and the other has not, the
       changed value is used. If both of the system variables
       have been set to a user-defined value, the value of
       group_replication_ip_allowlist is used.

     * From MySQL 8.0.22, the statements START SLAVE, STOP
       SLAVE, SHOW SLAVE STATUS, SHOW SLAVE HOSTS and RESET
       SLAVE are deprecated. The following aliases should be
       used instead:

          + Instead of START SLAVE use START REPLICA

          + Instead of STOP SLAVE use STOP REPLICA

          + Instead of SHOW SLAVE STATUS use SHOW REPLICA STATUS

          + Instead of SHOW SLAVE HOSTS use SHOW REPLICAS

          + Instead of RESET SLAVE use RESET REPLICA
       The statements work in the same way as before, only the
       terminology used for each statement and its output has
       changed.
       New status variables have been added as aliases for the
       related status variables. Both the old and new versions
       of the statements update both the old and new versions of
       these status variables:

          + Com_slave_start is equivalent to Com_replica_start

          + Com_slave_stop is equivalent to Com_replica_stop

          + Com_show_slave_status is equivalent to
            Com_show_replica_status

          + Com_show_slave_hosts is equivalent to
            Com_show_replicas

     * The ALTER DATABASE statement now supports a READ ONLY
       option that controls whether to permit modification of a
       database and objects within it. This option is useful for
       database migration because a database for which READ ONLY
       is enabled can be migrated to another MySQL instance
       without concern that the database might be changed during
       the operation. See ALTER DATABASE Statement
       (https://dev.mysql.com/doc/refman/8.0/en/alter-database.html).
       A new INFORMATION_SCHEMA table named SCHEMATA_EXTENSIONS
       displays database options. Currently, it displays READ
       ONLY=1 for read-only databases. See The
       INFORMATION_SCHEMA SCHEMATA_EXTENSIONS Table
(https://dev.mysql.com/doc/refman/8.0/en/information-schema-schemata-extensions-table.html).