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

[Bjørn Munch]

[Due to size limitation, this announcement is split in two. This is part 1]

Dear MySQL users,

MySQL Server 8.0.14, a new version of the popular Open Source
Database Management System, has been released. MySQL 8.0.14 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.14 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.14 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.14 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.14 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.

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.13. It may also be viewed
online at

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

Enjoy!

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

Changes in MySQL 8.0.14 (2019-01-21, General Availability)


     * Account Management Notes

     * Audit Log Notes

     * Compilation Notes

     * Component Notes

     * Configuration Notes

     * Deprecation and Removal Notes

     * Function Notes

     * Logging Notes

     * Optimizer Notes

     * Packaging Notes

     * Performance Schema Notes

     * Pluggable Authentication

     * Security Notes

     * Spatial Data Support

     * SQL Syntax Notes

     * Thread Pool Notes

     * X Plugin Notes

     * Functionality Added or Changed

     * Bugs Fixed

Account Management Notes


     * Previously, each MySQL user account was permitted to have
       a single password. MySQL now permits an account to have
       dual passwords, designated as primary and secondary
       passwords. This capability enables phased password
       changes to be performed seamlessly in complex
       multiple-server systems, without downtime. To support
       dual-password capability, the ALTER USER and SET PASSWORD
       statements now have a RETAIN CURRENT PASSWORD clause that
       saves the current password as the secondary password when
       you assign an account a new primary password. ALTER USER
       also has a DISCARD OLD PASSWORD clause to discard a
       secondary password that is no longer needed. See Password
       Management
       (http://dev.mysql.com/doc/refman/8.0/en/password-management.html).
       Important
       The implementation of dual-password capability involves a
       change to the structure of the mysql.user system table.
       If you upgrade to this MySQL release from an earlier
       version, you must run mysql_upgrade (and restart the
       server) to incorporate this system database change. Until
       this is done, password changes are not possible.

Audit Log Notes


     * The audit API now enables applications to add their own
       message events to the audit log using the new
       audit_api_message_emit component, which includes an
       audit_api_message_emit_udf() user-defined function. See
       The Audit Message Component
       (http://dev.mysql.com/doc/refman/8.0/en/audit-api-message-emit.html).

Compilation Notes


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

Component Notes


     * A new host_application_signal component service is
       available to enable server components to deliver signals
       to the host application. For example, the service enables
       replication components to send a shutdown signal to the
       server.

Configuration Notes


     * The content of the .gitignore file has been cleaned up.
       Much of this file was inherited from its .bzrignore
       predecessor and was not relevant. One implication of this
       cleanup is that in-source builds are disallowed. (Bug
       #28341794, Bug #91626)

     * MySQL Server now permits a TCP/IP port to be configured
       specifically for administrative connections. This
       provides an alternative to the single administrative
       connection that is permitted on the network interfaces
       used for ordinary connections even when max_connections
       connections are already established. The administrative
       network interface has these characteristics:

          + The interface is available only if the admin_address
            system variable is set at startup to indicate the IP
            address for the administrative interface.

          + The admin_port system variable specifies the
            interface TCP/IP port number (default 33062).

          + There is no limit on the number of administrative
            connections.

          + Connections are permitted only by users who have the
            SERVICE_CONNECTION_ADMIN privilege.
       The create_admin_listener_thread enables DBAs to choose
       whether the administrative interface is implemented using
       the listener thread used for ordinary connections (this
       is the default), or has its own separate thread.

       Thanks to Facebook for suggesting the idea (and for
       contributing code, although it was not used). (Bug #27847672,
       Bug #90395)

Deprecation and Removal Notes


     * The deprecated resolveip and resolve_stack_dump utilities
       have been removed and are no longer included in MySQL
       distributions. nslookup, host, or dig can be used instead
       of resolveip. Stack traces from official MySQL builds are
       always symbolized, so there is no need to use
       resolve_stack_dump.

Function Notes


     * The JSON_ARRAYAGG() and JSON_OBJECTAGG() aggregate
       functions now can be used as window functions, if an OVER
       clause is present. See Aggregate (GROUP BY) Function
       Descriptions
       (http://dev.mysql.com/doc/refman/8.0/en/group-by-functions.html).

Logging Notes


     * A new system variable, log_slow_extra, if enabled, causes
       the server to write additional fields to slow query log
       lines that provide information about slow statements. In
       addition, SET lines written to the log to indicate
       statement timestamps now use the time from the beginning
       of statement execution, rather than the time at the end
       of execution. See The Slow Query Log
       (http://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html).
       Thanks to Facebook for the contribution on which
       this feature is based. (Bug #27535580, Bug #89637)

     * Server logging behavior has changed with respect to error
       log messages generated prior to processing startup
       options that specify logging configuration. Previously,
       the server generated messages with the default timestamp,
       format, and verbosity level; buffered them; and then
       flushed them after the error log configuration became
       known. Because these early messages used the default
       logging configuration, they could differ from what is
       specified by the startup options.
       Now, the server buffers log events rather than formatted
       log messages. This enables it to retroactively apply
       configuration settings to those events after the settings
       are known, with the result that flushed messages use the
       configured settings, not the defaults. For more
       information, see Error Log Message Format
       (http://dev.mysql.com/doc/refman/8.0/en/error-log-format.html).

Optimizer Notes


     * Previously, derived tables and common table expressions
       could not contain outer references. Outer references are
       now permitted.

Packaging Notes


     * Ubuntu 18.10 and Fedora 29 install OpenSSL 1.1.1 by
       default, but OpenSSL 1.1.1 is not fully supported by
       MySQL. To install MySQL, the OpenSSL 1.0.2 compatibility
       package must be installed. (Bug #28981868)

Performance Schema Notes


     * The Performance Schema statement event tables
       (events_statements_current, events_statements_history,
       and events_statements_history_long) now have a
       STATEMENT_ID column that indicates the query ID
       maintained by the server at the SQL level. Column values
       are unique for the server instance because they are
       generated using a global counter that is incremented
       atomically.

Pluggable Authentication


     * If the LDAP port number is configured as 636 or 3269, the
       plugin now uses LDAPS (LDAP over SSL) instead of LDAP.
       The port number is settable using the
       authentication_ldap_sasl_server_port or
       authentication_ldap_simple_server_port system variable.
       (LDAPS differs from startTLS.) (Bug #28743563)

     * Previously, for LDAP authentication with proxying, LDAP
       authentication plugins used the first group name returned
       by the LDAP server as the MySQL proxy user account name.
       The authentication string for a MySQL account now can
       specify a list of groups to match, in preference order,
       and can optionally map the matching group name to a
       specified MySQL proxy user name. See LDAP Pluggable
       Authentication
(http://dev.mysql.com/doc/refman/8.0/en/ldap-pluggable-authentication.html).

Security Notes


     * The OpenSSL libraries bundled with MySQL on some
       platforms (Windows, macOS, and Generic Linux) have been
       upgraded to version 1.0.2q. On all other platforms, MySQL
       uses the system installed OpenSSL. Issues fixed in the
       new OpenSSL version are described at
       http://www.openssl.org/news/vulnerabilities.html. (Bug
       #28988091)

     * To affect subsequent server restarts, the SET PERSIST and
       SET PERSIST_ONLY statements enable system variables to be
       persisted to the mysqld-auto.cnf option file in the data
       directory. However, some system variables cannot be
       persisted (for example, because they involve sensitive
       data). Consequently, they cannot be set at runtime from
       within a session conducted by a remote administrator, and
       thus require the administrator to log into the server
       host and directly modify a my.cnf option file.
       MySQL now permits users to perform runtime administration
       of many previously nonpersistible system variables, so
       that they can be persisted under certain restrictive
       conditions. To enable this capability, designate an SSL
       certificate X.509 Subject value that signifies the
       ability to persist these restricted system variables, and
       set the new persist_only_admin_x509_subject system
       variable to that Subject value. Users who connect to the
       server using an encrypted connection and supply an SSL
       certificate with the designated Subject value then can
       use SET PERSIST_ONLY to persist persist-restricted system
       variables. For more information, see Nonpersistible and
       Persist-Restricted System Variables
(http://dev.mysql.com/doc/refman/8.0/en/nonpersistible-system-variables.html).

     * For most system variables, setting the session value
       requires no special privileges and can be done by any
       user to affect the current session. For some system
       variables, setting the session value can have effects
       outside the current session and thus is a restricted
       operation that can be done only by users who have a
       special privilege. Previously, either
       SYSTEM_VARIABLES_ADMIN or SUPER qualified as such a
       privilege, but both privileges also permit operations
       other than setting session variables. The new
       SESSION_VARIABLES_ADMIN privilege makes it possible to
       grant users only the ability to set restricted session
       variables without also enabling other operations.
       Any operation permitted by SESSION_VARIABLES_ADMIN is
       also permitted by SYSTEM_VARIABLES_ADMIN or SUPER, so any
       user who already has one of the latter privileges
       effectively has SESSION_VARIABLES_ADMIN by implication
       and need not be granted SESSION_VARIABLES_ADMIN
       explicitly. However, if a user has been granted
       SYSTEM_VARIABLES_ADMIN or SUPER only for the purpose of
       enabling that user to modify restricted session system
       variables, an administrator can reduce the user's
       privilege footprint by revoking SYSTEM_VARIABLES_ADMIN
       and SUPER, and granting SESSION_VARIABLES_ADMIN instead.
       For instructions, see System Variable Privileges
       (http://dev.mysql.com/doc/refman/8.0/en/system-variable-privileges.html).
       These previously restricted session variables required
       SYSTEM_VARIABLES_ADMIN or SUPER but now can also be set
       with SESSION_VARIABLES_ADMIN:
binlog_format
binlog_row_image
binlog_row_value_options
binlog_rows_query_log_events
debug
debug_sync
default_collation_for_utf8mb4
explicit_defaults_for_timestamp
gtid_next
histogram_generation_max_mem_size
original_commit_timestamp
sql_log_bin
sql_log_off
sql_require_primary_key

       These previously unrestricted session variables now are
       restricted and setting them requires at least
       SESSION_VARIABLES_ADMIN (they can also be set by users
       who have SYSTEM_VARIABLES_ADMIN or SUPER):
auto_increment_increment
auto_increment_offset
binlog_direct_non_transactional_updates
bulk_insert_buffer_size
character_set_filesystem
character_set_database
collation_database
pseudo_slave_mode
pseudo_thread_id
rbr_exec_mode
transaction_write_set_extraction

Spatial Data Support


     * The ST_Distance() function now takes an optional third
       argument enabling the unit for the return value to be
       specified. Permitted units are those listed in the new
       INFORMATION_SCHEMA ST_UNITS_OF_MEASURE table. See Spatial
       Relation Functions That Use Object Shapes
(http://dev.mysql.com/doc/refman/8.0/en/spatial-relation-functions-object-shapes.html),
       and The INFORMATION_SCHEMA ST_UNITS_OF_MEASURE Table
       (http://dev.mysql.com/doc/refman/8.0/en/st-units-of-measure-table.html).

SQL Syntax Notes


     * A derived table now may be preceded by the LATERAL
       keyword to specify that it is permitted to refer to
       (depend on) columns of preceding tables in the same FROM
       clause. A derived table specified with LATERAL can occur
       only in a FROM clause, either in a list of tables
       separated with commas or in a join specification (JOIN,
       INNER JOIN, CROSS JOIN, LEFT [OUTER] JOIN, or RIGHT
       [OUTER] JOIN). Lateral derived tables make possible
       certain SQL operations that cannot be done with
       nonlateral derived tables or that require less-efficient
       workarounds. See Lateral Derived Tables
       (http://dev.mysql.com/doc/refman/8.0/en/lateral-derived-tables.html).
       Note
       LATERAL now is a reserved word and cannot be used as an
       identifier without identifier quoting.

Thread Pool Notes


     * The INFORMATION_SCHEMA tables that accompany the thread
       pool plugin have been migrated to be available as
       Performance Schema tables. The INFORMATION_SCHEMA tables
       now are deprecated and will be removed in a future MySQL
       version. Applications should transition away from the old
       tables to the new tables. For example, if an application
       uses this query:
SELECT * FROM INFORMATION_SCHEMA.TP_THREAD_STATE;

       The application should use this query instead:
SELECT * FROM performance_schema.tp_thread_state;

       For more information, see Performance Schema Thread Pool
       Tables
(http://dev.mysql.com/doc/refman/8.0/en/performance-schema-thread-pool-tables.html).

X Plugin Notes


     * X Plugin now includes the 5-digit SQLSTATE error code in
       its error handling class. Previously, the SQLSTATE error
       code was returned to clients for SQL errors, but only the
       MySQL-specific error number was exposed. (Bug #28735058)

     * When querying collections of documents, if boolean values
       were used as arguments for a placeholder in an SQL query,
       unexpected results were returned. A new translation
       specialization has now been added for boolean values so
       that they are handled correctly in this situation. (Bug
       #28227037)

     * X Protocol now always converts retrieved data to the
       utf8mb4 character set (using the utf8mb4_general_ci
       collation) before returning it. (Bug #28180155)

     * X Protocol now supports SQL prepare functionality.

Functionality Added or Changed


     * InnoDB: To reduce the size of core files, the
       innodb_buffer_pool_in_core_file variable can be disabled
       to prevent InnoDB buffer pool pages from being written to
       core files.
       Thanks to Facebook for the contribution. (Bug #27724476,
       Bug #90144)

     * InnoDB: By default, undo logs reside in two undo
       tablespaces that are created when the MySQL instance is
       initialized.
       Additional undo tablespaces can be created in a chosen
       location at runtime using CREATE UNDO TABLESPACE syntax.
CREATE UNDO TABLESPACE tablespace_name ADD DATAFILE 'file_name.ibu';

       Undo tablespaces created using CREATE UNDO TABLESPACE
       syntax can be dropped at runtime using DROP UNDO
       TABLESPACE syntax.
DROP UNDO TABLESPACE tablespace_name;

       ALTER UNDO TABLESPACE syntax can be used to mark an undo
       tablespace as active or inactive.
ALTER UNDO TABLESPACE tablespace_name SET {ACTIVE|INACTIVE};

       A STATE column that shows the state of a tablespace was
       added to the INFORMATION_SCHEMA.INNODB_TABLESPACES table.
       An undo tablespace must be in an empty state before it
       can be dropped.
       The previously deprecated innodb_undo_tablespaces
       variable is no longer configurable and will be removed in
       a future release.
       For more information, see Undo Tablespaces
       (http://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html).

     * InnoDB: InnoDB now supports parallel clustered index reads,
       which can improve CHECK TABLE performance. This feature does
       not apply to secondary index scans.  The
       innodb_parallel_read_threads session variable must be set to a
       value greater than 1 for parallel clustered index reads to
       occur. The default value is 4. The actual number of threads
       used to perform a parallel clustered index read is determined
       by the innodb_parallel_read_threads setting or the number of
       index subtrees to scan, whichever is smaller.

     * InnoDB: The ADD DATAFILE clause of the CREATE TABLESPACE
       statement is now optional, which permits users without
       the FILE privilege to create tablespaces. A CREATE
       TABLESPACE statement executed without an ADD DATAFILE
       clause implicitly creates a tablespace data file with a
       unique file name.

     * InnoDB: When the innodb_dedicated_server variable is
       enabled, the size and number of log files are now
       configured according to the automatically configured
       buffer pool size. Previously, log file size was
       configured according to the amount of memory detected on
       the server, and the number of log files was not
       configured automatically.

     * Replication: When running a group in single-primary mode,
       in the event of a new primary being elected while there
       were transactions held in the backlog to be applied,
       there was a chance that a read operation against the new
       primary could return a stale value. Now, you can use the
       group_replication_consistency variable to control how a
       group behaves in this situation. When
       group_replication_consistency is set to EVENTUAL, a new
       primary responds to read requests even when there is a
       backlog which has not yet been applied, which matches the
       previous behavior and comes with the risk that a client
       could read old values while any backlog is being applied.
       Writes to the new primary fail during this period because
       it is has super_read_only mode enabled. When
       group_replication_consistency is set to
       BEFORE_ON_PRIMARY_FAILOVER, any new read or write queries
       against a newly elected primary that is applying backlog
       from the old primary are held until the backlog is
       applied. This ensures that clients always read the newest
       value which they have written, but also means that
       clients might have to wait until the backlog has been
       applied before they can read from the new primary.
       References: See also: Bug #26004894.

     * Microsoft Windows: The access control granted to clients
       on the named pipe created by the MySQL server now is set
       to the minimum necessary for successful communication on
       Windows. Newer MySQL client software can open named pipe
       connections without any additional configuration. If
       older client software cannot be upgraded immediately, the
       new named_pipe_full_access_group server system variable
       can be used to give a Windows group the necessary
       permissions to open a named pipe connection. Membership
       in the full-access group should be restricted and
       temporary.

     * The minimal server RPM is mostly used for Docker images.
       For better Docker compatibility, the log-error line has
       been removed from the rpm-docker configuration file. This
       way, logging goes to stdout/stderr, enabling use of
       Docker's own interface. (Bug #28692675)

     * Error messages relating to creating and dropping foreign
       keys were improved to be more specific and informative.
       (Bug #28526309, Bug #92087)

     * The error message for ALTER TABLE statements that
       attempted character set conversion but failed was
       improved to indicate which column produced the error.
       (Bug #27546306, Bug #88738)

     * Previously, for command options that take a numeric
       value, the value could be given with a suffix of K, M, or
       G to indicate a multiplier of 1024, 1024^2 or 1024^3. Now
       a suffix can also be T, P, and E to indicate a multiplier
       of 1024^4, 1024^5 or 1024^6. Thanks to Daniel Black for
       the patch. (Bug #27306931, Bug #89017)

     * Resource group locking was revised to improve scalability
       and performance. (Bug #27148580)

     * The Group Communication System (GCS) and group
       communication engine (XCom, a Paxos variant) for Group
       Replication now provide full support for IPv6, so
       replication group members can use IPv6 addresses as an
       alternative to IPv4 addresses for internal group
       communications. The localhost address for IPv6, and the
       private subnetwork addresses for IPv6 (unique-local
       addresses and link-local unicast addresses), are added to
       the automatic whitelist for Group Replication for use if
       no manual whitelist is specified.
       If all members of a replication group are at a MySQL
       server version that supports the use of IPv6 addresses
       for Group Replication, the group can contain a mix of
       members using IPv6 addresses and members using IPv4
       addresses. Joining members must provide whitelisted IP
       addresses or host names that match the protocols offered
       by the seed members for connection, but the joining
       member's main identifying address or host name
       (group_replication_local_address) can use either
       protocol. If a member uses a host name that resolves to
       both an IPv4 and an IPv6 address, the IPv4 address is
       always used for Group Replication connections.
       If any or all existing members of a replication group are
       using an older MySQL Server version without support for
       the use of IPv6 addresses for Group Replication, joining
       members must present an IPv4 address for group
       communications in the group_replication_local_address
       option. When every group member has been upgraded, the
       group can be migrated to IPv6 addresses. (Bug #26088469,
       Bug #27757729, Bug #90217)

     * MySQL Group Replication can now communicate using a
       dedicated input channel as an alternative to using a TCP
       socket. The new input channel uses shared memory for
       communication between the Group Replication logic and the
       local instance of the underlying group communication
       engine (XCom, a Paxos variant).
       Previously, communication with the local XCom instance
       always took place using a TCP socket, namely the network
       address that is specified by the
       group_replication_local_address system variable for each
       group member. This incurred overheads that were
       unnecessary for local communication, such as memory
       copying through the network protocol stack and data
       serialization. A TCP socket
       (group_replication_local_address) is still required for
       each group member to communicate with remote XCom
       instances. The Group Communication System (GCS) component
       of Group Replication now selects the most appropriate
       communication method for each Group Replication task,
       either the input channel or TCP. For example, the process
       of joining a group requires communication with a remote
       XCom instance, so TCP must be used. However, the process
       of removing a member from a group only requires
       communication with the local XCom instance, so the input
       channel is used. The input channel is selected wherever
       possible to minimize the overheads associated with
       communication using networking mechanisms.

     * Two new session system variables have been added for
       internal use by replication. original_server_version and
       immediate_server_version support cross-version
       replication by transmitting the MySQL server release
       numbers associated with a transaction through the
       replication topology. original_server_version holds the
       MySQL Server release number of the server where a
       transaction was originally committed (for example, 80014
       for a MySQL 8.0.14 server instance).
       immediate_server_version holds the MySQL Server release
       number of the server that is the immediate master in a
       replication topology. If either of those servers, or
       another intervening server in the replication topology,
       is at an older release that does not support these
       session system variables, their values are set to 0.
       With this information the slave can correctly process
       data originating from a master at an older release, by
       recognizing where syntax changes or semantic changes have
       occurred between the releases involved and handling these
       appropriately. The information can also be used in a
       Group Replication environment where one or more members
       of the replication group is at a newer release than the
       others. The value of the variable can be viewed in the
       binary log for each transaction (as part of the
       Gtid_log_event, or Anonymous_gtid_log_event if GTIDs are
       not in use on the server), and could be helpful in
       debugging cross-version replication issues.

     * The startup option --binlog-row-event-max-size now has a
       corresponding system variable binlog_row_event_max_size.
       The startup option and system variable set a soft limit
       on the maximum size of a row-based binary log event, with
       a default setting of 8192 bytes. Where possible, rows
       stored in the binary log are grouped into events with a
       size not exceeding the value of this setting. If an event
       cannot be split, the maximum size can be exceeded.
       The binlog_row_event_max_size global system variable is
       read-only and can be set only at server startup. Its
       value can therefore only be modified by using the
       PERSIST_ONLY keyword or the @@persist_only qualifier with
       the SET statement. The addition of a system variable
       means that this setting can be viewed using the
       Performance Schema tables or a SHOW VARIABLES or SELECT
       statement.

     * Binary log files and relay log files can now be
       encrypted, helping to protect these files and the
       potentially sensitive data contained in them from being
       misused by outside attackers, and also from unauthorized
       viewing by users of the operating system where they are
       stored.
       You enable encryption on a MySQL server by setting the
       new binlog_encryption system variable to ON. OFF is the
       default. The system variable sets encryption on for
       binary log files and relay log files. When you first
       start the server with encryption enabled, a new binary
       log encryption key is generated before the binary log and
       relay logs are initialized. This key is used to encrypt a
       file password for each binary log file (if the server has
       binary logging enabled) and relay log file (if the server
       has replication channels), and further keys generated
       from the file passwords are used to encrypt the data in
       the files.
       If you activate encryption while the server is running, a
       new binary log encryption key is generated at that time,
       and the binary log files and relay log files are rotated
       so that the new and subsequent files are encrypted. If
       you deactivate encryption by changing the
       binlog_encryption system variable to OFF, the binary log
       file and relay log files are rotated immediately and all
       subsequent logging is unencrypted. Previously encrypted
       files are not automatically decrypted, but the server is
       still able to read them. (The SHOW BINARY LOGS statement
       now shows whether each binary log file is encrypted or
       unencrypted.) SUPER privileges or the new
       BINLOG_ENCRYPTION_ADMIN privilege are required to
       activate or deactivate encryption while the server is
       running.
       The encryption algorithm used for the files, the AES
       (Advanced Encryption Standard) cipher algorithm, is built
       in to MySQL Server and cannot be configured. The binary
       log encryption keys used to encrypt the file passwords
       for the log files are 256-bit keys that are generated
       specifically for each MySQL server instance using MySQL
       Server's built-in keyring service. The binary log
       encryption key that is currently in use on the server is
       called the binary log master key.
       The new binlog_rotate_encryption_master_key_at_startup
       system variable controls whether the binary log master
       key is automatically rotated when the server is
       restarted. If this system variable is set to ON, a new
       binary log encryption key is generated and used as the
       new binary log master key whenever the server is
       restarted. If it is set to OFF, which is the default, the
       existing binary log master key is used again after the
       restart.
       Note that when encryption is active for a MySQL server
       instance, only the data at rest that is written to the
       binary log files and relay log files is encrypted. The
       data in motion in the replication event stream, which is
       sent to MySQL clients including mysqlbinlog, is always in
       unencrypted format, so it must be protected in transit by
       the use of connection encryption. The data in use that is
       held in the binary log transaction and statement caches
       during a transaction, and any data that exceeds the space
       available in those caches and is therefore stored in a
       temporary file on disk, is also in unencrypted format.
       The temporary files and caches are deleted when the
       thread that handles the transaction ends.

     * ALTER TABLE now can be used to change a column character
       set in place (without a table rebuild), when these
       conditions apply:

          + The column data type is CHAR, VARCHAR, a TEXT type,
            or ENUM.

          + The character set change is from utf8mb3 to utf8mb4,
            or any character set to binary.

          + There is no index on the column.

     * The new -DFORCE_INSOURCE_BUILD CMake option defines
       whether to force an in-source build. Out-of-source builds
       are recommended, as they permit multiple builds from the
       same source, and cleanup can be performed quickly by
       removing the build directory. To force an in-source
       build, invoke CMake with -DFORCE_INSOURCE_BUILD=ON.